avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Roebuck <stuart.roeb...@adolos.co.uk>
Subject Re: JUnit AvalonTestCase
Date Thu, 09 Aug 2001 12:54:17 GMT
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....


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 Roebuck                                  stuart.roebuck@adolos.com
Lead Developer                               Java, XML, MacOS X, XP, etc.
ADOLOS                                           <http://www.adolos.com/>

To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org

View raw message