At 08:12 PM 6/12/2001 +0100, Vincent Massol wrote:
>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)
Ah, I see. That is the part that I had not understood before. Yes, I think
that there is an easy way to do this; ISTM that by implementing one class
which extends WebResponse, you would get all of its HTML parsing
capabilities. You would then simply include httpunit.jar and tidy.jar in
your distribution.
> Bringing [in-container and mock-object] 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 ... :)
I see. I rather agree with you; the path to integration is not obvious to me.
> 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 ... ?
I have not tried to explain all of the libraries I use to businessfolk;
their eyes tend to glaze over. A greater concern might be learning curves
for developers, but I figure that most developers use whatever tools will
help them. Making each tool easier seems to me more promising than trying
to make a one-size-fits-one MIcrosoft Office-style library.
