RE: Using cactus with junit tests and ant on existing and runningcontainer.

[Erez Nahir <en...@cisco.com>]

Hi Simon,

Thanks for your suggestions. Unfortunately, I can't use war and get cause
our product is installed with installshild exe which run some registration
and other C code stuff.

I will try to create a servlet of my own that will invoke ant's targets.

Thanks,
Erez.

> -----Original Message-----
> From: Simon Gibbs [mailto:enquiries@simongibbs.co.uk] 
> Sent: Saturday, January 17, 2004 10:38 PM
> To: Cactus Users List
> Subject: RE: Using cactus with junit tests and ant on 
> existing and runningcontainer.
> 
> Hi Erez, I have been following this thread as I have had 
> similar issues, so I will see if I can make some useful suggestions.
> 
> On Thu, 2004-01-15 at 16:05, Erez Nahir wrote:
> > > Oh ok. I thought you wanted to automate the whole process. 
> 
> > I do want very much but it's a very complicated project 
> developed over 
> > 6 remote sites and its 3rd release so we cant get it all in 
> one, for 
> > now I can only try to automate the test itself :-(.
> 
> I'm surprised this is relevant. Are you not using CVS? You 
> should be able to build and run from anywhere with equal 
> ease. Also you should really have a dev server for your 
> project and not be constrained by using a shared server 
> instance. I'm guessing you have encountered office politics :-)
> 
> > > Simply use the <junit> task as you've done.
> > But than it doesn't started in the Tomcat VM but in my VM isn't it?
> 
> That is entirely true. The point is that many of your tests 
> may not need to run inside the Tomcat JVM. Cactus is not 
> needed for that type of test.
> 
> > The NCDFE is really not relevant here IMHO.
> 
> I agree it looks like the NCDFE is caused by the tests 
> running outside the Tomcat JVM when you need them to be on 
> the inside. I got this too.
> 
> > The process as it is done today is as follows:
> > 1. Build generate the project image;
> > 2. Build generate project-test image;
> > 3. Developers install the project.
> > 4. Developers install the project-test (now all the Cactus specific 
> > stuff is added but we can live with it because we run also external 
> > tests on project image without project-test install);
> 
> This is fine, but you can automate 3 and 4. I ended up using 
> the <get> task to call the Tomcat manager and trigger the 
> reloading of my wars.
> BTW I would try to use a WAR, the unpacked-war format is a 
> tomcat feature - not part of the standard.
> 
> The app manager documentation is here:
> http://jakarta.apache.org/tomcat/tomcat-4.0-doc/manager-howto.
html I'm not sure if its available on 3.0 though  <shrug>.

> 5. Developers open a browser and use index.html with the links.
> 6. Upon clicking on specific link, the relevant test case is started 
> and generate the known junit report (but only for this test).
> 
> Now, what I'm looking for is to improve steps number 5 and 6 (in 
> addition I can add stuff to step 4), such that I'll be able to run 
> either a single url call that will generate the xmls (and than I'll 
> generate the report with <junitreport> ant's task), or do ant call 
> with cactus to run all the test cases as if they are on the real VM.
> 

There are a couple of ways to improve this. First would be to simply use
<get> to trigger all the tests from the build file and download the results
as you want them. Alternatively you can bundle the tests together into a
TestSuite which can then be invoked in one step either from the browser or
Ant.

Good luck

--
Simon Gibbs <en...@simongibbs.co.uk> http://www.simongibbs.co.uk
07866 741 461 / 33 / BA15 1TB


---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-user-help@jakarta.apache.org