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).
ok, it seems we indeed have some clarification to do here. I mixed up terminology in my last mail. Heres my next try:
ASU has only one "redirector", namely a session bean (TestRunnerSession). TRS is essentially called from the TestRunnerClient with the following parameters (semantics as usual):
- test case class name - test case method name (optional)
TRS then instantiates the test case and invokes it, using the standard JUnit machinery (with the exception of some hacky extensions that make the test result serializable). The test result is passed back to the calling client.
To invoke the TRS, there are 2 clients available (which I call invokers), both of which are automatically packaged with the ear by the ant task:
- an application client invoker - a web application (servlet) invoker.
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 a session bean is a better choice for the redirector, as it gives you (me) the option of using the application client as an invoker, which makes a direct remote call to the TRS.
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... ;-)
if you have a test case that makes remote calls to server side components, you can execute it "in front of" the TRS (the TRS is not used). This makes mostly sense if you use the application client invoker
The magic is that ServletTestCase provides container objects to the test itself (HttpSerlvetRequest, HttpServletResponse, HttpSession, etc).
It is really server-side testing :-)
ok, understood. ASU does not do that, obviously.
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.
ok, so I may have to look at cargo sometime
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.
I hope we are getting closer.
regards, christian
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
