avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <j...@socialchange.net.au>
Subject Re: JUnit AvalonTestCase
Date Thu, 09 Aug 2001 12:13:34 GMT
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. 

[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.

> 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?


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

View raw message