AppServerUnit and Cactus

[Vincent Massol <vm...@pivolis.com>]

Hi everyone,

I've just come across a new framework for unit testing J2EE components:
AppServerUnit (https://appserverunit.dev.java.net/). I was of course
extremely curious about the differences from Cactus. I've read the user
guide and I'm positing my first impressions below.

My goal here is *not* to start a framework war in order to decide which
framework is best. My goal is to see whether there's something we can both
learn from each other. I have to admit that my secret wish would be to join
forces in some manner... :-)

Some thoughts:

* ASU and Cactus are both providing in-container testing

* They both work using a redirector (a servlet for ASU and a
servlet/jsp/filter for Cactus)

* ASU focuses on unit testing EJBs. Cactus supports all J2EE components
(servlets, jsps, filters, ejbs)

* ASU provides Ant tasks to create an EAR containing the redirector, the
test classes and deployment descriptors created for the test (so that the
servlet can access the EJBs to be tested). Cactus takes a slightly different
approach: we take as input a WAR/EAR and we "cactify" it, i.e. adding the
redirector, modifying the deployment descriptors, adding the test cases,
etc. The goal is to cactify the same archive that the user is going to put
in production. Note: We currently have only a cactifywar Ant task. The
cactifyear one is pending (but we do have this feature in the Maven plugin).

* Cactus provides Ant tasks to start/stop/configure/deploy archives which
makes it a little bit easier for users to get started with I believe. ASU
could add this very quickly by harnessing Cargo (http://cargo.codehaus.org)
as Cargo is mainly the extraction of all these features from Cactus :-)

* Cactus supports several containers (see feature list on
http://jakarta.apache.org/cactus/features.html).

* ASU supports a web execution of tests. So does Cactus using the
ServletTestRunner (see
http://jakarta.apache.org/cactus/integration/index.html).

* Cactus may appear heavyweight but I don't think it is. It's more complex
in the sense that it provides a full solution for testing all types of J2EE
components. We are working to make it leaner (for example by extracting all
the Container manipulation into Cargo).

My conclusion so far is that ASU is very very close to Cactus. We're
following almost exactly the same ideas (use of a redirector for example)
and we're solving the same issues (getting back the test result and stack
trace from the server-side to the client side, etc).

I would love to work with Christian Sell (ASU's author) to better identify
shortcomings of Cactus (and to share issues we've faced over the long
history of Cactus) and/or ASU. Christian, you'll find us very open to ideas.
Please shoot and correct me on the list of ASU's features above (I'm sure
I've missed a lot!).

One last point: Cactus is deceptive. At first look, it seems that everything
is done and covered for. But in practice there are so many things
outstanding that remains to be done... Including an idea of "Cactus 2" which
I have put on hold for the time being (see
http://blogs.codehaus.org/people/vmassol/archives/000520_cactus_v2_architect
ure_proposal.html for some details).

Thanks
-Vincent