[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [ajdt-dev] Running JUnit tests
|
Let me put in my own recommendation for using virtual mock objects that use AspectJ to change the behavior of collaborating objects without requiring refactoring to plug in mocks and wrapper.
There's a recent presentation on the topic at http://www.newaspects.com/presentations
Ron
Ron Bodkin
Chief Technology Officer
New Aspects of Security
m: (415) 509-2895
> ------------Original Message-------------
> From: Nick Brett <nb271@xxxxxxxxx>
> To: ajdt-dev@xxxxxxxxxxxxxxx
> Date: Wed, Oct-1-2003 11:35 PM
> Subject: Re: [ajdt-dev] Running JUnit tests
>
> Hi Andy,
>
> > Hmmm. AJDT is kind of a thin Eclipse veneer that links the aspectj
> > compiler into Eclipse. I'm not quite sure what AJDT would become if
> > the workbench was mocked out ??
>
> I think there are two approaches here. The first is to look at unit
> tests at simply a class level, that is you are testing the
> functionality provided by a small unit of code, a single method or
> collection of methods.
>
> So for example in the NewAspectWizard class in the makeAspect method
> there is code to alter the "public class" string into "public aspect"
> and a number of comments about how that bit of code could be improved.
> This single method could be tested very effectively by mocking up an
> ICompilationUnit class.
>
> Mocking up objects doesn't just provide us with a facility for ensuring
> that our classes do what they're supposed to do under perfect
> circumstances but also a very effective way of testing error conditions
> which would be difficult to replicate if we were using a real workspace.
>
> The second group of testing which I think is what you're referring to
> is a more function based approach and with a larger granularity. These
> would require a real workspace but could still be automated again using
> the PDE JUnit support, of course these would essentially be functional
> tests I believe as they would test quite a large chunk of functionality.
>
> For the unit tests a nice approach might be to create a separate unit
> tests source tree that mirrors the current src tree and contains test
> classes with the same name as the classes that they are testing. This
> would also help keep dependencies separate if the unit tests required
> additional support that wasn't in a default Eclipse build and would
> make it easy to identify a production classes unit test.
>
> For the more functional tests I'm not so sure, a separate tree
> structure which had folders for each functional area which the tests
> covered?
>
> Let me know how feasible you think this sort of thing would be.
>
> Cheers,
> Nick.
>
> On Wednesday, October 1, 2003, at 02:25 pm, Andrew Clement wrote:
>
> >
> > Hi Nick,
> >
> >> OS: MacOS X 10.2.8
> >> Java: 1.4.1
> >> Eclipse: 3.0M3
> >> AJDT: Latest CVS
> >
> > Now that is on the bleeding edge. We haven't fully tested AJDT with
> > Eclipse 3.0 - and I don't know of anyone else doing AJDT development
> > on the Mac. Of course, it should work, its just that you may hit a
> > few issues we haven't...
> >
> > First thing I should say is you might as well ignore the unit tests,
> > AJDT came to life before we 'saw the light' with the Test Driven
> > Development approach. We have a work item to go back and add some
> > relevant ones ... but we just haven't managed it yet.
> >
> > The approach we *would* take if we had some tests is using the PDE
> > JUnit framework that is specifically for testing plugin projects,
> > rather than the basic JUnit stuff. Not sure if its built into
> > Eclipse 3.0 or not. The URL is:
> >
> > http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/jdt-ui-home/
> > plugins/org.eclipse.jdt.junit/index.html
> >
> > With this PDE JUnit setup, we define a special kind of Junit runtime
> > configuration which launches a new workbench, runs the junit tests
> > then shuts it down.
> >
> >> Also has anybody thought about using mock objects -
> >> www.mockobjects.com
> >> - to allow the unit tests to be run without this tight integration
> >> with
> >> the workbench?
> >
> > Hmmm. AJDT is kind of a thin Eclipse veneer that links the aspectj
> > compiler into Eclipse. I'm not quite sure what AJDT would become if
> > the workbench was mocked out ??
> >
> > So basically, ignore the existing unit tests and probably all the
> > framework. If you want to write some to the PDE Junit structure
> > and contribute them - that would be excellent ;)
> >
> > Andy.
> >
> >
> >
> > _______________________________________________
> > ajdt-dev mailing list
> > ajdt-dev@xxxxxxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/ajdt-dev
>
> _______________________________________________
> ajdt-dev mailing list
> ajdt-dev@xxxxxxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/ajdt-dev
>
>