jakarta-cactus-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Massol" <vmas...@octo.com>
Subject RE: Acceptance (Functional) Testing - Cactus or HTTPUnit?
Date Thu, 15 Aug 2002 14:31:39 GMT
Hi Michael,

> -----Original Message-----
> From: michael [mailto:michael@idtect.com]
> Sent: 14 August 2002 10:05
> To: cactus-user@jakarta.apache.org
> Subject: Acceptance (Functional) Testing - Cactus or HTTPUnit?
> I'm working on a testing strategy for a new web application project.
> haven't even finished requirements yet so it's the perfect time.  I
> a couple choices for acceptance testing:
> 0) Use HTTPUnit
>   - Pros : closest to the end user
>   - Cons : small changes in GUI require test changes, becoming a
> maintenance problem.  Duplicates test logic in the tests for the
> classes.
> 1) Use Cactus (testing the Struts Action classes), skipping the
> layer.
>   - Pros : small GUI changes do not affect tests
>   - Cons : does not test HTML/JSP interface.  This could be done
> manually and with a really good Cactus test of the Struts Action
> classes, there would be small risk for the HTML.
> Basically there is some overlap between testing the Action classes and
> the HTML pages.  HTML changes will be more frequent than Java code
> changes, requiring a lot of maintenance to keep Gui tests in sync. We
> have a small project with a small staff so maintaining test cases is a
> very important issue.  We don't have the luxury of having a customer
> will write the acceptance tests (does anyone?), nor do we have the
> luxury of having a full time person responsible for tests.  So it will
> be developers who will write and maintain the test cases.
> I'm curious if any Cactus and/or HTTPUnit users have opinions one way
> the other.

HttpUnit is about functional testing (end to end). Cactus is about unit
testing (white box, at the level of the method). There is always
redundance between both kind of tests but they are both needed.
Functional tests ensure that your application works from a customer
point of view. However, it only tests some paths of the application and
not the full code. In addition, when something breaks you usually don't
know where and you need to spend time debugging. Smalle, focused unit
tests, on the other hand let you pinpoint exactly the problem and give a
good confidence that application does what you think it does ... :-)
Both are needed.

I believe Cactus is exactly what you want as:
- you don't have customers writing your functional tests 
- Cactus integrates HttpUnit (see the web site for the doc), which means
you can still test *some* results of the call to a page like cookies,
and content. You do not need to test that such table is located at
exactly this location, etc, but you can verify that the page returned is
the one asked and that it contains a table named XXX for example.
- although you have 2 tools, they are integrated all in one which makes
it  much simpler (actually you don't even need to know that Cactus is
using HttpUnit, apart from the package names ... What I mean is that you
can consider Cactus as an extension of HttpUnit if you wish and only
work with Cactus, i.e. all your tests are Cactus tests.


> Michael
> --
> To unsubscribe, e-mail:   <mailto:cactus-user-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:cactus-user-
> help@jakarta.apache.org>

To unsubscribe, e-mail:   <mailto:cactus-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:cactus-user-help@jakarta.apache.org>

View raw message