On Thursday, August 9, 2001, at 01:13 pm, Jeff Turner wrote:
On Thu, Aug 09, 2001 at 10:15:24AM +0100, Stuart Roebuck wrote:Funnily enough I spent Tuesday working out a solution for this kind of issue for a Cocoon Action I'm working on at the moment.
I went for a 'mock' object approach [see <http://mockobjects.sourceforge.net/endotesting.html>],
Is there some mailing list I'm not on where cool stuff like this gets announced? ;) I think this mock object approach could simplify many Avalon unit tests.
Cool mailing list? ... your already on it! :-)
[snip C2 Action example]
My personal feeling is that setting up specialized TestCases for testing,
whilst it may simplify the code of tests for people familiar with the code,
removes transparency and adds a level of complexity into the test cases
that could make them harder to maintain. e.g. you need to look at the
definition of the new TestCase in order to determine what the pre-set
state is and then learn the new methods for altering it. With plain Mock
classes you have to explicitly setup everything in the TestCase which may
require more lines of code (but then you can easily do a copy and paste
job from a previous test case), however, you end up with a test case that
is self contained and self documenting. The only new methods you need to
learn are additional methods in the mock classes that provide setup or
validation functionality.
I don't quite see how using Mock objects replaces Giacomo's solution. It seems to me that the Mock object technique is only applicable when you have a sausage-machine setup; feed an object it, crank the handle, get it out and examine what's happened to it. I can't see that this situation occurs much in your average Component's lifecycle. There's no point in a MockConfiguration or MockContext, as they're not returnable.
I'm not familiar enough with Avalon to answer this specifically, but in general cases...
* If an existing class can easily be instantiated for the purposes of a test then there's no need to create a mock object unless you want to check afterwards to confirm that interactions with that object were performed as expected, and the existing class does not provide the methods to do this.
* If a component requires one or more objects as input in order to process successfully, and these objects are hard to instantiate in a test case, then it may be easier to create a mock object which behaves in the way expected by the component without actually doing the work. Whilst this object may never be returned, it has provided a suitable environment for performing the test. e.g. a component that obtains input data from a JDBC database link may require a suitable database to be created in a suitable state before a test can be carried out. (- which is a lot of hassle!) A very simple mock object could be 'pre-programmed' to return the correct responses in order to test the rest of the code (though it clearly won't test the JDBC connection!)
The mock io objects on the mockobjects site are all output related (if I remember correctly) and are quite sophisticated in that they check the order of execution of calls to methods. In my early ventures into mock objects I've found that ridiculously simple mock objects have often sufficed and can be input related too. To be honest, I didn't use any of the mockobjects library at all, I just benefitted from their inspiration!
Stuart.
PS. I'm intending feeding back the mock objects to Cocoon if folk are interested.
Hmm.. perhaps an org.apache.mock.* hierarchy, maintained in the sourceforge mockobjects-java package?
For my tests I used the parallel test hierarchy and appended "Mock" to the class names, e.g....
src/org/apache/cocoon/environment/Session.java test/org/apache/cocoon/environment/SessionMock.java
This puts the tests and the mock classes in the same package scope and keeps the mock classes as close to the originals as possible to encourage them to be updated with the classes they mock. But it still makes it easy to distribute the compiled versions with or without the test code.
Stuart.
------------------------------------------------------------------------- Stuart Roebuck [EMAIL PROTECTED] Lead Developer Java, XML, MacOS X, XP, etc. ADOLOS <http://www.adolos.com/>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
