----- 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?
>
Wow wow wow .... We're going a bit fast here ... :)
Here are some facts that represent the current status of Cactus :
1 - Cactus is for the moment an in-container unit testing tool that provides
a middle ground between very fine-grained mock object style unit testing and
very coarse grain functional test (like what HttpUnit does)
2 - Cactus is dedicated to push to the limit the in-container approach (see
http://jakarta.apache.org/commons/cactus/goals.html)
3 - In order to provide additional useful features for Cactus users, I have
brought up several subjects :
a - adding functional tests API to Cactus. The idea is simply to provide
some API so that output streams can be checked in more powerful method that
just checking against the string representation of the result. These API
would be used in endXXX() test case methods. This proposal seemed to be well
accepted as I have received only positive feedbacks. (Note: This is where I
asked Russell Gold if he would be willing to help and integrate HttpUnit
into Cactus instead of Cactus reinventing the wheel ... He has very rightly
said that he has to look more into Cactus before committing an answer)
b - think about the interest of bringing Mock Object testing style into
Cactus (when I say "Mock Objects", I refer to the definition described in
http://www.sidewize.com/company/mockobjects.pdf). After reading this paper
and meeting with the authors (Xtc club in London, www.xpdeveloper.com), I
found that they indeed had a very interesting approach that was
complementary in most cases. There are pros and cons of each approach (see
http://jakarta.apache.org/commons/cactus/mockobjects.html for a comparison
of both approaches). Bringing the 2 together might solve the cons of each
... *However*, I am not sure it is either possible nor desirable. This is
why I have opened the debate, which is still open, about how we could
integrate mock objects into Cactus in a seamless manner as possible ...
Nothing has been committed on that point. It is completely unchartered
territory and fresh ground ... :)
The goals of a) and b) above are to prevent the user from having to use
several frameworks as much as possible. It is already difficult to convince
Business persons that writing test cases is necessary (except for Acceptance
tests which are easily accepted). Now if you have to explain to them that
the developers have to use 3 frameworks (Mock objects, Cactus, HttpUnit),
that they have to install them and be trained in how to use them, deploy
them, .... then it is harder to justify. But maybe this is the right way to
do it ... ?
Cactus will continue to progress. If it has any meaning, the ultimate goal
could be to be the tool of choice for testing server side java code ...
(this is my dream at least ... :) ).
Thanks
Vincent.
