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?
