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]
