Seems to work fine for running unit/integration/system within the same
build.
We have separate goals for each of the test run types. Each goal sets the
appropriate run type property. The goals are run in sequence and the
results are consolidated into target/test-results. The site goal is then
executed as the final goal so that we get reports for each test.
cheers,
Justin
Aaron Smuts
<[EMAIL PROTECTED]
> To
Maven Users List
21/06/2005 09:53 <[email protected]>
AM 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>
This doesn't allow you to run unit and integration in
the same build. I run maven via anthill and generate
teh site docs for a variety of projects periodiclally.
I want all the tests present for the coverage report.
For now I just run them all together all the time. .
. .
Can you plug a variable into the include?
If so then you you can name your tests according to
some convention and use something similar.
The default could be **/*UnitTest.java
If you wanted them all then **/*Test.java would get
you everything.
**/*IntegrationTest.java could get you just
integration tests.
Can you do something like this:
<include>**/*${test.prefix}.java</include>
I'll try tomorrow.
Aaron
--- [EMAIL PROTECTED] wrote:
> 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
>
=== message truncated ===
---------------------------------------------------------------------
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]
