* ASU and Cactus are both providing in-container testing
yes
* 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).
yes.
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.
regards, Christian
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
