Thats fine with me.  So we are talking about having the test:iutest be a
second test goal pointing to a different source directory, classes
directory, reports directory, etc?  This goal would not run on every build
like test:test.  Cactus based tests would be invoked via a different
goal/plugin, but you could bring them into a common goal in your own
maven.xml if you desired.  Same with a customer/acceptance test thing if you
had them all in one project.  Am I following this correctly?

=================================================================
Jeffrey D. Brekke                                   Quad/Graphics
[EMAIL PROTECTED]                              http://www.qg.com


> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Friday, September 27, 2002 10:25 AM
> To: [EMAIL PROTECTED]
> Subject: RE: How to run Integration Unit Tests
> 
> 
> Based on my looking at Turbine-2's project.xml file, IU tests 
> end up in
> src/rttest.  I like this idea just becasue some of my IU type 
> tests are
> dependent on many external things like running DBUnit code to reset my
> database, running an ant based Webtest ant script, and then 
> running various
> checks at the end of the entire process.  Plus all the extra 
> files required
> for Cactus tests.
> 
> That way you can easily sperate the two:
> src/test  -> fast tests
> src/rttest -> slow tests
> 
> 
> Eric
> 
> -----Original Message-----
> From: Brekke, Jeff [mailto:[EMAIL PROTECTED]]
> Sent: Friday, September 27, 2002 11:18 AM
> To: 'Turbine Maven Users List'
> Subject: RE: How to run Integration Unit Tests
> 
> 
> Up to beta-4 Maven used to have an integration unit test target to run
> cactus based programmer integration tests.  Post beta-4 a 
> plugin for cactus
> is needed and I don't believe any work has been done on this. 
>  I don't have
> a solution but here's the breakdown we have, these are 
> currently all junit
> tests:
> 
> programmer tests ( fast "unit" type tests ),
> programmer integration tests ( slow "unit" type tests that 
> may depend on
> external systems like a database )
> customer tests ( acceptance/funtional, black box type tests, 
> think httpunit,
> requires installed application )
> 
> The programmer tests most likely are the plain unit tests 
> that maven runs
> during the build.  It would be interesting if there could be another
> include/exclude for the iu tests.  I don't think they need to 
> be separated
> from the unit test code/class directory, just selected from 
> the pool of
> tests to run?
> 
> =================================================================
> Jeffrey D. Brekke                                   Quad/Graphics
> [EMAIL PROTECTED]                              http://www.qg.com
> 
> 
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, September 27, 2002 10:01 AM
> > To: [EMAIL PROTECTED]
> > Subject: How to run Integration Unit Tests
> > 
> > 
> > I solved my logging issues, it turns out I needed in a 
> > basetestcase to init
> > the log4j system.  ARgh..  Now I am trying to figure out how best to
> > structure my Integration Unit Tests.
> > 
> > Does the maven test target run IU tests?  I checked out 
> > Turbine 2 from CVS
> > and ran the target test, then the site target.  However, the 
> > various IU
> > tests are not listed, in fact apparently there are no Unit 
> > tests at all!  
> > 
> > So how should I run my IU tests?  I don't want to run them 
> constantly
> > because some can take up to 5 minutes of processing to do.
> > 
> > Eric
> > 
> > --
> > To unsubscribe, e-mail:   
> > <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail: 
> > <mailto:[EMAIL PROTECTED]>
> > 
> 
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
> 
> --
> To unsubscribe, e-mail:   
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: 
> <mailto:[EMAIL PROTECTED]>
> 

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to