> -----Original Message----- > From: Christian Sell [mailto:[EMAIL PROTECTED] > Sent: vendredi 7 janvier 2005 13:31 > To: Vincent Massol > Cc: 'Cactus Users List'; [EMAIL PROTECTED] > Subject: Re: AppServerUnit and Cactus > > 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 > > 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.
Please have a look at http://jakarta.apache.org/cactus/how_it_works.html. The redirector is the server side interceptor that starts the unit tests on the server side. For example, imagine that you have a test that tests a local session bean. As you cannot access it from the client side you need what I call a redirector (aka interceptor) located on the server side. This is independent of the test is started (whether from Ant, Maven, a web page, etc). > > The redirectors interact with a server side session bean, which does the > actual instantiation and invocation of the test class. Yep, exactly. What I was just saying is that Cactus has several redirectors (servlet, jsp, filters) which all offer entry points into the server. I think you imagine that cactus is doing HTTP testing but it's not, see below. > > There is also an option to execute tests in "client mode", i.e. in the > context of the redirector/invoker. Not sure I get this one... ;-) > > > * 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. Cactus is interested in doing server-side testing, not client side. When we test some code that uses the Servlet API for example, we do not test what the Servlet or JSP returns (although we can do it). What we do test is at the level of the method. Here's an example: public class MyTest extends ServletTestCase { public void testSomeMethod() { // test setup MyServlet servlet = new MyServlet(); // test execution Object result = servlet.someMethod(request); // Asserts assertEquals(....); } } The magic is that ServletTestCase provides container objects to the test itself (HttpSerlvetRequest, HttpServletResponse, HttpSession, etc). It is really server-side testing :-) Now, we do also provide the ability to test what's returned from the server side using a special endXXX method, and we do integrate with HttpUnit. But all this is peripheral to Cactus' first goal which is to perform unit testing (i.e. at the java method level) of all J2EE components. > > > * 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. Excellent. So ASU and Cactus are getting even closer... :-) > > > * 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. It's some big work. Initially we didn't have them either. But then people were finding it complex to use as they had to do a lot of work before being able to have their test executing. So, over the years we've built some Ant tasks and Java code to help with those container-related tasks. And we're now moving them all in Cargo. > > > * 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. Yep. > > > * 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). You're right, we do have the cactifywar task but we're missing the cactifyear one. ATM users have to do a cactifywar first and then package it into an EAR themselves (unless they use the Maven plugin which does all this for them - Except adding the ejb references to the web.xml). That would be something awesome to add to Cactus... > > > 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. Cool. Let's continue getting a good understanding of how each framework works and then when we feel we have a good grasp we'll be able to decide if there's anything we can share. Thanks -Vincent --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
