Hi Simon, > -----Original Message----- > From: Simon Gibbs [mailto:[EMAIL PROTECTED] > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
