Quoting Jeff Turner <[EMAIL PROTECTED]>: > 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.
You are right MockConfiguration as well as MockContext doesn't make much sense as they are read-only to the component becaus your test case can instantiate and initialize them how ever you like. But sometimes a MockComponentManager might be good enough compared to a full fledged ExcalibuCM. BTW: Right now I have a TestCase based on an early version of a ExcaliburTestCase running with a method which takes two InputSources (roles file and config file) and a context to sets up a logger and a CM for use in the test methods. I've made this just to see how it works. The config file and the test cases will be quite heavy (and not really a unit test) as the component to test is a BusinessObjectManager which make use of other components (access layer, transport layer, xml serializers, etc., etc.) to finally connect to a IBM host retrieving DB2 data through a CICS connection from an ORB which a Cocoon 2 connects to to satisfy SOAP requests originated from that BusinessObjectManager. Its very funny :)) Giacomo > > > 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? > > --Jeff > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
