maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Massol" <vmas...@pivolis.com>
Subject RE: Maven and Integration Test
Date Thu, 20 May 2004 20:40:15 GMT
Yes, this is also what I've been advocating :-)

Some references:
http://www.pivolis.com/pdf/Enterprise_Builds_V1.0.pdf
http://www.pivolis.com/pdf/J2EE_projects_Maven_V1.1.pdf

The only variation I have from what Michal and Jeff describe below is
that this other project is not a test project for me. It's the
application or container project, i.e. the project that creates the
application (EAR for example) or the one that create the container
configuration. The reason is that integration tests, in the same fashion
as the functional tests, need the application to be running (or at least
a part of it). The application or container project is the place where
the application can be run.

If you check slide 26 of the "Enterprise Builds" presentation you'll see
the description of what test to run in which build project.

Thanks
-Vincent

> -----Original Message-----
> From: Jeffrey D. Brekke [mailto:jbrekke@wi.rr.com]
> Sent: 20 May 2004 20:10
> To: Maven Users List
> Subject: Re: Maven and Integration Test
> 
> 
> The most elagent solution I've seen to date is simply another project
> as Michal has suggested.  By the OP's definition, these tests span
> multiple aritfacts/projects and require deployment.  Why tie them
> artifically to a single project and introduce the dependecy problems
> that come along with that?  We have done that in our legacy ant build
and
> it's like quicksand trying to get out of it now.  Our build is brittle
> and slow.  A large reason why is we have done just what you propose,
keep
> our integration tests in the same project as our unit tests and
> production code.
> 
> I'd really give the separate project, just for integration/customer
> tests, some consideration.
> 
> >>>>> On Wed, 19 May 2004 09:45:51 -0500, Ryan Sonnek
> <rsonnek@DigitalRiver.com> said:
> 
> > I was REALLY hoping to hear another solution to this problem.  I'm
> > running into the same thing, and would like to contain my project
> > code (tests and all).  I remember the cactus plugin introducing the
> > concept of src/test-cactus for it's integration test code.  Two
> > options would be to reuse the current test plugin and change the
> > source directory dynamically, or create another "test" plugin for
> > integration tests that looks to something like src/test-integration.
> > I think that creating a new test plugin might make the most sence in
> > order to plug easier into project reports.  How plausible is this?
> 
> > Ryan
> 
> >> -----Original Message----- From: Maczka Michal
> >> [mailto:michal.maczka@imtf.ch] Sent: Wednesday, May 19, 2004 9:31
> >> AM To: 'Maven Users List' Subject: RE: Maven and Integration Test
> >>
> >>
> >>
> >>
> >> > -----Original Message----- > From: Amato Massimiliano (TLAB) >
> >> [mailto:Massimiliano.Amato@tradinglab.unicredit.it] > Sent:
> >> Wednesday, May 19, 2004 4:17 PM > To: Maven Users List > Subject:
> >> Maven and Integration Test
> >> >
> >> >
> >> > Hello,
> >> >
> >> > I've a problem with my integration tests.
> >> >
> >> > In my system we have both unit and integration test, the > first
> >> type is perfectly handled by maven that execute them, > and
> >> generates a report and a clover coverage too.
> >> >
> >> > Now I also have integration that are test to cover not the >
> >> single class but a package and functional tests that must be > run
> >> on the deployed system that are junit tests aswell.
> >> >
> >> > All that comes to my mind is to write and additional goal > that
> >> must override the test source directory that must be > lauched when
> >> functional tests wants to be executed, while for > integration i
> >> think using them as unit test is the best > approach even if they
> >> are not accounted in the clover report
> >> >
> >> > Anyone else ever had a problem like that? What's the solution >
> >> you implemented?
> >> >
> >> Just put them to another project.
> >>
> >> Michal
> >>
> >>
---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org For
> >> additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
> 
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org For
> > additional commands, e-mail: users-help@maven.apache.org
> 
> --
> =====================================================================
> Jeffrey D. Brekke                                   jbrekke@wi.rr.com
> Wisconsin,  USA                                     brekke@apache.org
>                                                     ekkerbj@yahoo.com
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message