Hi Russell,
I was rereading your message and just wanted to say that cactus's goal was
not initially to do in-container testing but just to provide a framework to
test server-side java code in the easiest possible way. It happened that I
favored the in-container strategy for the implementation ... In the meantime
I have also learnt better the Mock Object philosophy and found that it could
offer interesting benefits for unit testing code on the server that Cactus
could not offer in the same way (this not to say one is better than the
other : they are complementary).
But the goals of Cactus is still the same : "To be the preferred framework
for unit testing server-side java code". This goal is independent of the
implementation. If it takes a mix of both in-container and mock objects to
achieve the result then so be it ! :)
Cheers,
Vincent.
----- Original Message -----
From: "Russell Gold" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, June 12, 2001 4:53 PM
Subject: RE: Mock Objects for servlets (was Re: Roadmap for Cactus 1.1)
> At 11:12 AM 6/12/2001 -0400, Steve Salkin wrote:
> > > I have a feeling that I am missing the point here, but it
> > > feels almost as though you have found a hammer you really
> > > like and now wish it could turn screws as well.
> >
> >LOL. But this amusing characterization somewhat dodges the point,
> >which is that Cactus is pretty good at one kind of testing, and
> >would be an even better tool if it could do another kind of
> >testing.
> >
> >As the apparent author explains on the mock objects vs. in container
> >testing page
>
>(<http://jakarta.apache.org/commons/cactus/mockobjects.html>http://jakarta.
apache.org/commons/cactus/mockobjects.html)
> >
> >he is not averse to moving Cactus towards the mock objects strategy
> >precisely because it offers a more comprehensive approach and because
> >it tends to reinforce good design and implementation habits.
> >
> >I personally would like to see both choices available from within
> >one tool, for several reasons:
> >
> >(1) it will increase the userbase and thus the level of improvements
> > made available for this tool;
> >(2) it is more likely to satisfy the disparate needs of developers
> >(3) each mode helps to highlight problems in the other. For example,
> > an in-container test that suceeds while a mock test fails may
> > point out an error in a container-level mock object.
> >
> >I am sure that more reasons can be adduced in favor of this. Against it
> >is the argument of simplicity over complexity and the "one tool for one
> >job" philosophy.
> >
> >I am interested in an amplification of your thoughts about this.
>
> OK, I have in fact implemented something like this in HttpUnit, in an
> alternate package (servletunit) which uses a lot of common code. What I
> found is that the testing strategies of the two approaches (black-box test
> via HTTP and white-box test via mock-objects) seem to be very different.
I
> see some synergy in that where the test involves the examination of the
> resultant HTML, I often want to check the same things, but it seems with
> the limited number of mock-object tests that I have done, that there is
not
> a lot of overlap.
>
> In general I remember the lesson that many engineers learn: the more
> missions a single tool is expected to perform, the harder it is to make it
> good at any one mission. It is only because the two are supported in
> different packages that I feel comfortable even having them in HttpUnit,
> which at least has the unifying philosophy that all tests should be run
> from the command line and involve interpretation of HTML.
>
> Cactus seems to take an entirely different approach, placing its tests in
> the container itself. Now, this leads to a particular approach to testing
> which may not work well in other contexts. While I certainly understand
> and agree with the desire to be able to perform multiple types of testing,
> I don't see why it is important to have them all supported by a single
tool.
>
> It seems to me that users of Cactus are better served by improving its
> in-container abilities to address more kinds of in-container tests than to
> make it do something entirely foreign to its nature. Possibly I am wrong
> about its underlying philosophy?
>
>
