jakarta-cactus-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Massol" <vmas...@pivolis.com>
Subject RE: Running tests configured server instance using Ant
Date Mon, 29 Dec 2003 16:43:32 GMT
Hi Simon,

> -----Original Message-----
> From: Simon Gibbs [mailto:Simon.Gibbs@Virginmobile.com]
> Sent: 29 December 2003 17:12
> To: Cactus Users List
> Subject: Running tests configured server instance using Ant
> 
> 
> I have a build process to install my cactified web app into a Tomcat
> instance running as an NT service on my local machine. I use the
cactify
> ant
> task to do the "cactification", and <get> to communicate with the
Tomcat
> manager.
> 
> The goal is to test code which relies of resources obtained through
JNDI,
> and I have set up the JNDI resources in the Tomcat admin panel.

ok

> 
> I can run the tests using a browser and get a set of sensible results,
but
> using the <cactus> ant task I always end up with missing driver errors
and
> various other horrible things in my test output that simply suggest
the
> cactus task is running its own server and not using the properly
> configured
> Tomcat service.

Cactus is made of 2 parts:
- the core framework
- cactus runners (aka front ends), which allows to run Cactus tests
using different means/tool integration. The browser is one of the
runner. The <cactus> Ant task is another.

These different front ends provide different ways of running Cactus and
you need to understand how the front end you're using works so that you
can customize it for your need.

> 
> My last gasp solution is to do this:
> 
> 		<sequential>
> 			<echo >Waiting (max 15s)...</echo>
> 			<waitfor checkevery="3" checkeveryunit="second"
> maxwait="15000" >
> 				<http
>
url="http://localhost:8080/reportingapp/ServletRedirector?Cactus_Service
=R
> UN
> _TEST" />
> 			</waitfor>
> 			<get
>
src="http://localhost:8080/reportingapp/ServletTestRunner?suite=com.virg
in
> mo
> bile.reportingapp.junit.CoreTests"
> 	  			dest="${basedir}/CoreTests.xml" />
>   		</sequential>

Are you running this using the <runservertests> task (see
http://jakarta.apache.org/cactus/integration/ant/task_runservertests.htm
l) or directly in your own Ant script? If it's the later it means you're
using the manual front end (another word for saying you're not using any
Cactus-provided front end :-)).

> 
> I'm undecided whether this is any easier/better than running tests in
a
> browser, but since this works and is quite simple, I am posting it
here
> for
> the benefit of the equally desparate. I'm no expert (just a confused
> cactus
> n00b) but I'm guessing it should work on any server. 

It does. BTW, this is what the <cactus> is doing under the hood.

What you need to understand is that the <cactus> Ant task does a lot of
things (see
http://jakarta.apache.org/cactus/integration/ant/task_cactus.html). One
of them is to set up a container configuration from the ground up. By
default, the <cactus> task packages default configuration files for
several containers (including Tomcat 3.x, 4.x and 5.x). If you need to
modify these files (for example to set up some objects in JNDI or
whatever else), you'll need to provide some of these files yourself and
pass them in the <cactus> call. For example, for Tomcat, there is a
serverxml attribute that allows you to pass a customized server.xml file
(again, see
http://jakarta.apache.org/cactus/integration/ant/task_cactus.html for
the details).

If there's something no clear in the doc, please point us to that place
so that we can improve it.

> In the meantime, I
> have
> the following list of "nice to haves" which can be taken as a question
or
> else as feedback into the documentation team.
> 
> - I'd like a method of deploying and redeploying the cactified WAR in
a
> few
> neat Ant declarations.

Yes, this is a todo item. It needs to be supported for the different
containers. However, it's not currently high on my todo list. If you do
have patch for your container, please provide it and I'll commit it.

> - Running the cactus tests in a persistent server instance, in a few
neat
> Ant declarations.

This is already supported. If the server is already running before the
<cactus> task is called, Cactus will not try to start the container (I
think this is missing from the documentation - it was there a long time
ago but I couldn't find it again... hmmm...), nor will it try to stop
the container. It will redeploy the war though (by simply copying it
over the previous war).

> - A decent solution to setting up JNDI resources from within the build
> file,
> or linked files.

This is too specific to your use case and not generic enough for Cactus
to provide directly this feature. Your favorite container should provide
you with the tools for doing this, not Cactus.

> - For the future, a way of letting Ant know whether to continue with a
> build
> depending on the test results (which are now just a file).

Already supported. <cactus> extends <junit>. Thus you can set the
haltonerror, haltonfailure, errorproperty or failureproperty attributes
(see http://ant.apache.org/manual/OptionalTasks/junit.html).

> 
> These are all things I've spent days researching and querying, to no
> avail.
> This "solution" represents my final frustrating defeat by this vital,
but
> difficult tool. 

Yes, it is still difficult but we've been improving the usability a lot
in the last 1.5 release. However, testing J2EE component is difficult
(whatever solution you use, mockobjects or not).

Another option is to use Maven. There is a Cactus plugin which works out
of the box. You only need to set one property for it to work (the
location of your container).

> I have no intention of moving away from my hack in the
> short
> term, but later would like to make my build.xml into something more
> recognisable - if only for the benefit of my successors.
> 
> Simon Gibbs

I'm happy to see that almost all your problems already have answers! :-)

One problem with the current documentation is that the getting started
page needs to be rewritten to tie everything together. We haven't
updated it since a long time ago.

Thanks
-Vincent


Mime
View raw message