jakarta-cactus-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Sell <...@dynabean.de>
Subject Re: AppServerUnit and Cactus
Date Fri, 07 Jan 2005 12:31:20 GMT
heres my comments as the author of AppserverUnit. Most of what I say is 
concerned with ASUs side of the equation - I do not consider myself to 
be an expert in Cactus usage and internals (which I may be less than I 
should be).

> * 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)

not exactly. ASU offers 2 redirectors (I call them invokers): a simple 
servlet-based web interface and a J2EE application client. The latter is 
convenient for integration into Ant scripts, which in fact was the first 
incentive for implementing ASU.

The redirectors interact with a server side session bean, which does the 
actual instantiation and invocation of the test class.

There is also an option to execute tests in "client mode", i.e. in the 
context of the redirector/invoker.

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

true. However, I see testing of EJBs as something entirely different 
from testng a web app anyway. in fact, I would call the latter "client 
side testing", as the test would normally emulate a client (e.g., 
through HttpUnit) and not be deployed on the server.

> * 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).

not true anymore. In cvs head, there is now an option for using a 
complete EAR as input to the ASU ant task, which will then create a copy 
  with the necessary modifications/additions.

> * 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 :-)

the build file that comes with ASU contains a full (yet simple) 
example/demo, which also does the deployment by invoking the command 
line client for the Sun appserver. The same should be possible for other 
sevrers as well. I did not see the need for adding explicit support for 
this as part of ASU proper.

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

ASU has only been tested on Sun 8 appserver. However, there are no real 
dependencies in the core implementation. We add Sun8 deployment 
descriptors to the resulting ear, but these are not 
generated/manipulated in any way. If other servers require 
server-specific deployment descriptors, adding those should be very easy.
Of course, as we rely on the server tools for deployment and for the 
application client invoker, the user has to do appropriate adaptations 
for his/her specific environment when writing the ant script.

> * 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).

I have again had a look at the Cactus home page, and got a confirmation 
of what put me off (the "Cactus Ecosystem") when I first went looking 
for a tool for server-side testing. It may be that because I did not 
look closer (and listened to a colleague that had a similar perception), 
I missed out on those Cactus features that I could have benefitted from. 
For example, I did not realize that Cactus does the ear "cactification" 
stuff (erm, does it? or is it restricted to wars?) - that was one of my 
prime requirements, and the first thing I implemented (although only for 
ejb-jar files at first).

> 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!).

there you go.
I am of course open for any type of cooperation/discussion. We should 
all be able to benefit greatly.


View raw message