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 15:10:14 GMT
>>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.

>>>could add this very quickly by harnessing Cargo
>>>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.


View raw message