[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ajdt-dev] Running JUnit tests
|
Although I can see that method is a candidate, I suspect it takes more
than mocking up a single class, what about the superclass NewElementWizard
that might need to be mocked up to ensure I can construct an instance of
the NewAspectWizard. There is obviously a decision to be made about
whether the unit test is worth the investment in building the mock
framework.
OK. I see your point, this could prove to be too expensive to be worth it. I'll have a look at the mockobjects framework and at Ron's presentation and try to create a test for the NewAspectWizard and see how painful it is and get back to you on this.
This is the approach we take with plugins for which we *do* have
tests. Each plugin contains a src tree and a testsrc tree with junit
tests in. If I look at AspectJ itself, it has this layout and captures
the 'larger' tests in a separate module, that execute in a non-junit
framework.
Aah, sorry, I didn't realise that you had some sort of setup with AspectJ itself. I will have a look at that to see how it works.
Cheers,
Nick.
On Thursday, October 2, 2003, at 07:56 pm, Andrew Clement wrote:
> 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.
Although I can see that method is a candidate, I suspect it takes more
than mocking up a single class, what about the superclass NewElementWizard
that might need to be mocked up to ensure I can construct an instance of
the NewAspectWizard. There is obviously a decision to be made about
whether the unit test is worth the investment in building the mock
framework.
> 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.
Agreed - in my previous life as a developer on transaction processing
systems, how often I wanted to see how my code would cope with unusual
failures like OutOfMemory exceptions, IO exceptions, socket exceptions.
> 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.
Yes, it is nice to automate the testing of typical interactions a user
might have with the IDE - and these are more than simple unit tests.
> 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?
This is the approach we take with plugins for which we *do* have
tests. Each plugin contains a src tree and a testsrc tree with junit
tests in. If I look at AspectJ itself, it has this layout and captures
the 'larger' tests in a separate module, that execute in a non-junit
framework.
> Let me know how feasible you think this sort of thing would be.
It is all feasible and reasonable :) Just wish we had the time! We
are trying to move to a test driven development approach for new
bits of AJDT, but finding a gap in the schedule to go back and catch
up with unit tests for the base is hard. We need to get into the
AspectJ mindset, where part of fixing a bug is to ensure there is a
testcase for the problem included in the regression testsuite.
Andy.
