Now why didn't I think of that?  Brilliant.
 

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 
Sent: Sunday, June 19, 2005 7:27 PM
To: Maven Users List
Subject: Re: How to split unit and acceptance tests apart (both use
Junit framework)

here's our project dir structure:

src/
test/
  +- unit/
  +- integration/
  +- system/

with the following project.xml entry:

<unitTestSourceDirectory>test/${test.run.type}</unitTestSourceDirectory>

then it's just a matter of setting the appropriate run type (default is
unit) prior to executing the test goal.

cheers,
Justin




 

             dan tran

             <[EMAIL PROTECTED]

             m>
To 
                                       Maven Users List

             18/06/2005 02:52          <[email protected]>

             PM
cc 
 

 
Subject 
             Please respond to         Re: How to split unit and

               "Maven Users            acceptance tests apart (both use

                   List"               Junit framework)

             <[EMAIL PROTECTED]

                  he.org>

 

 

 

 





correct, in order to get test:single to work with integration as the
main artifact one needs to fool test:single that it has test to run
(that is why I say prepare to dig into test:single source to understand
its requirements )

perhaps you can submit your plugin into plugin's sandbox so we can use
it?

-D

On 6/17/05, David Jackman <[EMAIL PROTECTED]> wrote:
> I actually did create such a plugin because I wanted my integration 
> tests
as part of the same project as the code it was testing.  I also didn't
want my "integration test" project to be included by the multiproject
(and didn't want to hard-code an exclude for it, either).  This sort of
thing comes up a lot, and I think it's a vaild scenario.
>
> I didn't want to have to create a whole new plugin to run the other 
> set
of tests, but was forced to because the test plugin doesn't allow for
overriding the test source directory--it pulls it directly from the pom,
no questions asked.  It would be better if the test plugin used a
property for the test source dir, which defaulted to the directory
mentioned in the pom; then a goal could override it.
>
> ..David..
>
>
>
> -----Original Message-----
> From: dan tran [mailto:[EMAIL PROTECTED]
> Sent: Fri 6/17/2005 9:06 PM
> To: Maven Users List
> Subject: Re: How to split unit and acceptance tests apart (both use 
> Junit
framework)
>
> src/main/java is the maven recommend directory structure.  This way I 
> can so have src/main/resources, both indicating they are belonging to 
> the
main
> artifact.  It is more organized that way
>
> <unitTestSourceDirectory> can only understand by maven-test-plugin the

> real unit test. So if you point it to your main src, your tests will
be
> automatically invoked after compilation.  and you dont want that.
>
> Last, if you put your integration test cases as the main artifact, 
> then
you can
> use test:single in maven-test-plugin to invoke your integration.  Be
prepare
> to dig into maven-test-plugin to understand test:single requirement.
> (hmm, perhaps we should start thinking about
maven-integration-junit-plugin ;-)
>
> -Dan
>
>
> On 6/17/05, Craig McDaniel <[EMAIL PROTECTED]> wrote:
> > What is the reasoning for the extra "main" level? Why not src/java.
> >
> > Also, couldn't you just set the <unitTestSourceDirectory> to 
> > src/main/java and point <sourceDirectory> someplace empty? I am 
> > going to be going through this same process soon. Please share what 
> > you consider to be the best practice here (and why - it really helps

> > to understand).
> >
> >
> > On 6/17/05, dan tran <[EMAIL PROTECTED]> wrote:
> > > Guy,
> > >
> > > Move your integration/acception test to a separate maven project.
> > > Treat it like an application so that you can invoke it on demain.
> > > (ie all your test source goto src/main/java....)
> > >
> > > You many need to write some goal wrapper to invoke the test.
> > >
> > > -D
> > >
> > > On 6/17/05, Guy Davis <[EMAIL PROTECTED]> wrote:
> > > > Hello,
> > > >
> > > > I'm currently using Maven 1 for running our regular unit tests.
However
> > > > I'm in the process of adding larger acceptance/integration tests
that
> > > > cover wide areas of functionality.  I am still using the JUnit
framework
> > > > for these acceptance tests, but I was wondering if there was a 
> > > > way
to
> > > > separate out these two test types.
> > > >
> > > > The reason being is the time involved.  The standard unit tests 
> > > > run
in
> > > > no more than a couple of minutes. However the new acceptance 
> > > > tests require nearly an hour.
> > > >
> > > > Ideally, running these acceptance tests would be a different
goal
> > > > (target).   I'm hoping to configure CruiseControl to run our
unit
tests
> > > > on each build, but only acceptance tests on builds greater than 
> > > > 3
or 4
> > > > hours apart.
> > > >
> > > > Is this possible with Maven?  Perhaps with version 2?  Or does 
> > > > this require a custom plugin (based on the current unit test
plugin)?
> > > >
> > > > Thanks much,
> > > > Guy
> > > >
> > > >
> > > >
---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > >
> > >
> > > ------------------------------------------------------------------
> > > --- To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> >
> > --
> > Craig McDaniel
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
>

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




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


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

Reply via email to