Originally posted by Lasse Koskela:
Is it really the correct place? Is this dummy object an essential part of your Controller's responsibility? If so, then why is it a separate object?
Yes it is. The Controller is a general part which is deploeyd in many places across the system. The XSLT are "business rules" that define the behaviour the Controller exhibits when supplied with a particular message. The idea of this decoupling is to allow business analysts (who can't code Java) to define the behaviour of the system. Personally I don't agree with this approach, but there you go.
The Controller uses reflection to instantiate an object and call a method defined in the Plugin interface. Once this method has returned the Controller disposes of the object (by forgetting its references to the object). So outside of the Controller, you have no access to the created Plugin.
Now thanks to everyone's advice so far I can see how I can test Plugin objects with JUnit, since they have defined inputs and outputs (as defined by the interface). I can also test my Controller classes, since the Controller reacts to an i/p and I (in my test case) can know and define the business rules.
However my original question (which probably wasn't very clear) is how do I test the whole system from within JUnit? For example let us assume that the Controller and associated Plugin objects are working correctly and are being tested. The business analyst comes along and supplies me with the XSL transform and input(s) for the Controller. From JUnit how do I test this? As far as I can see, I am no longer testing units, but a system. My lack of ability to test is because without anlayzing the business rules, I don't know what's going on and hence can't write the test code. Even without testing the business analyst's particular test, provided I have tested my Plugins are tested my Controller, the only untested part is the XSL transforms. And surely there are tools out there to check XSL?
I guess though that it is the chaining together of the functionality that I would also be missing. For example, suppose the business rule is do a transform, call Plugin 1, do another transform, call Plugin 2, etc. This is the sort of test that needs to be done, but a test that can only be defined by knowing what is being tested!
Originally posted by Lasse Koskela:
Whether you code your test methods into a single TestCase class or multiple makes no difference with regards to whether JUnit executes them in parallel. I'd definitely recommend organizing your test methods in such a way that is optimal from a maintainability point of view. I tend to recommend placing tests that operate on a common test fixture (the object hierarchy being tested and its state) into a single TestCase class.
OK. I tend to follow the same approach as you - putting tests on a single or group of objects in the same TestCase, provided the state is something that is not something that needs a great deal of setup between tests. So if I was testing the Foo class, I would put all the tests in one TestCase, unless my setUp() method varied considerably, dependant on the tests in the TestCase.
BTW Thanks to everyone's responses so far. They have really helped me to focus and understand EXACTLY what it is I am trying to do and test.
David