You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jason van Zyl <ja...@maven.org> on 2006/12/11 19:08:29 UTC
Integration Testing
Hi,
This is in response to John's email about integration testing, some
notes that I've taken while trying to clean up the integration
testing, and some suggestions about where we go from here with
respect to integration testing. You will see from the list below that
there are many problems with the ITs ranging from integration tests
for specific plugins being in there to using production dependencies,
to having tons of duplicated for doing ITs.
So, in response to John's email: I think we need to settle on what
we're going to use and stop writing new tools. We have several
invokers, several verifiers, several IT plugins, and the plugin
harness. It is simply out of control. We have different methods being
used in different plugins, nothing is standard and it's going to kill
us. The most prevalent tool, as defective as it might be is what is
being used in the ITs themselves. Stephane managed to use this
successfully in some of his plugins. Then after that we have an array
of usages. What should happen before we start writing more stuff is
to figure out something we can use now, and how to merge what we have
together instead of writing more tools.
This is just to get the discussion started. I will take a first pass
at enumerating the collection of tools we have and where they are
used. But here are my notes from the main core ITs. Thus far as some
of the ideas pertain to ITs in general like not polluting the local
repo when testing ..
Jason.
---
- [-] Goals
- [ ] An IT should be completely self-contained so that the problem
can be understood by looking in one place, in one Maven
project.
- [ ] We should be able to create an Archetype so that users can
easily create ITs for us
- [+] The ITs should be in a project of their own so that we can
reuse them across versions of Maven. We could actually run
new versions of integration tests against old versions of
Maven. Solution: the ITs are now in a separate build and it
is possible to run them
- [ ] We should be able to easily integrate the IT into a larger
run where we can use forked or embedded execution.
- [ ] We should create Archetypes for all categories of problems so
that anyone can generate tests cases for us. Then there is so
much that we can do in terms of automating this process of
checking tests for quality along with the patches.
- [ ] automate the testing of ITs submitted by users
- [ ] Each IT should have its own repository if it needs resources
from repository. We can't mess with a users repository when
testing.
- [ ] We need to have a file system based remote repository for
testing
- [ ] We need to standardize on integration testing in general. We
have people going all over the place and it's a disaster.
- [ ] We have too many IT plugins (3)
- [ ] We have too many invokers (5)
- [ ] We have too many verifiers (3)
- [ ] The ITs should run nicely from an IDE. Solution: this does
work but requires that you run mvn clean
resources:testResources first as the IDE doesn't know how to
set that up. Needs to be fully fixed. But it is much nicer
running this stuff in your IDE.
- [-] Problems with ITs
- [+] Verifier jar required by the bootstrap requires a special
verifier.jar there is no released version of this tool.
Solution: the bootstrap now uses Ant and we've gotten rid of
a lot of the complexity.
- [+] The maven-core-it plugin needs to be decoupled into its
separate purposes because there are currently 12 different
things going on in the plugin and it would be really
confusing for a new user to figure out what's going on in the
plugin and how it applies to the integration testing.
Solution: these have now been broken down into plugins that
correspond to their function in the ITs.
- [ ] it0006 is an integration test for the verifier plugin.
- [ ] it0014 uses the compiler plugin to test plugin configuration.
- [ ] it0016 is an integration test for the WAR plugin.
- [ ] it0017 is an integration test for the EJB plugin.
- [ ] it0018 uses real dependencies to test artifact resolution.
- [ ] it0020 tests beanshell mojo support.
- [ ] it0024 uses the compiler plugin to test mojo configuration.
- [ ] it0028 uses the compiler plugin to test mojo configuration.
- [ ] it0029 uses the compiler plugin to test for pluginManagement
injection of plugin configuration.
- [ ] it0033 is an integration test for the EAR plugin.
- [ ] it0043 uses the help plugin to look at the state of the final
POM, we should have this built into Maven for testing.
- [ ] it0047 uses plexus-container-default for testing.
- [ ] it0048 uses the surefire plugin to test default value
population for mojo parameters.
- [ ] it0050 is an integration test for the surefire plugin.
- [ ] it0051 is an integration test for the release plugin.
- [ ] it0052 is an integration test for the release plugin.
- [ ] it0054 is an integration test for the resources plugin.
- [ ] it0055 is an integration test for the compiler plugin.
- [ ] it0056 uses the compiler plugin to test multiple executions.
- [ ] it0060 uses the compiler plugin to test aggregation of list
configuration items when using 'combine.children=append'
attribute.
- [ ] it0063 tests JDK 1.4.2 specifics.
- [ ] it0068 uses the modello plugin to test repository
accumulation (i'm not sure what that means, John?)
- [ ] it0069 uses classworlds dependency to test offline mode.
- [ ] it0070 is an integration test for the RAR plugin.
- [ ] it0074 uses the compiler plugin to test mojo configuration.
- [ ] it0076 uses the WAR plugin to test pluginManagement.
- [ ] it0078 uses the compiler plugin to test pluginManagement.
- [ ] it0079 uses the source plugin to test that attached artifacts
have the same build number as the primary artifact.
- [ ] it0080 uses the WAR plugin to test an artifact handler that
specifies no contribution to transitive dependencies. if the
behavior of this handler changed the test would break.
- [ ] it0081 uses production dependency of wagon as a dependency
- [ ] it0083 uses the WAR plugin to test an artifact handler that
the WAR artifact handler currently behaves like
- [ ] it0086 uses production dependency of bsh to test classloading
- [ ] it0087 uses prodcution dependency of commons-logging to test
classloading
- [ ] it0089 is an integration test for the checkstyle plugin
- [ ] it0094 has a test that attempts to access a protected field
in a ClassRealm
- [ ] it0095 uses the help and verifier plugins to test URL
calculation
- [ ] it0100 uses the antrun plugin to make sure
${parent.artifactId} resolves correctly
- [ ] it0102 uses the help and antrun plugins to test profile
activation
- [ ] it0104 uses the surefire plugin to test interpolation
- [ ] it0105 is an integration test for the resources plugin
- [ ] artifactIds should be aligned with directories
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Integration Testing
Posted by Jason van Zyl <ja...@maven.org>.
On 18 Dec 06, at 9:18 AM 18 Dec 06, David Whitehurst wrote:
> Jason:
>
> Here! here!
>
> I recently joined the AppFuse bunch and being more the builder,
> packager,
> deployer-type, I'm working on AppFuse2 and the use of the
> archetype. Since,
> I've been on a large state project for Massachusetts, we have not used
> Maven, so my knowledge of Maven has been some small use of Maven1.
> I'm am
> so disappointed in my inability to just further or push the work on
> the
> AppFuse archetype. It's bad for me personally because I'm a senior
> level
> type but I can't just make good progress because I'm always having
> some
> trouble determining *what* I'm supposed to do to get things to work.
> AppFuse is difficult but Maven's even more difficult because I
> don't know
> where the knowledge home is for every plugin, mojo, etc. I don't
> know *how*
> I'm supposed to do things.
>
> It seems that Maven and the Plugin World needs a roadmap and some
> throttling
> of what gets created and what becomes public domain.
>
> Thanks Jason for your work behind a great development tool and your
> work in
> trying to slow things down.
>
I try my best.
http://www.amazon.com/Praise-Slowness-Worldwide-Movement-Challenging/
dp/006054578X
Jason.
> David
>
> On 12/11/06, Jason van Zyl <ja...@maven.org> wrote:
>>
>> Hi,
>>
>> This is in response to John's email about integration testing, some
>> notes that I've taken while trying to clean up the integration
>> testing, and some suggestions about where we go from here with
>> respect to integration testing. You will see from the list below that
>> there are many problems with the ITs ranging from integration tests
>> for specific plugins being in there to using production dependencies,
>> to having tons of duplicated for doing ITs.
>>
>> So, in response to John's email: I think we need to settle on what
>> we're going to use and stop writing new tools. We have several
>> invokers, several verifiers, several IT plugins, and the plugin
>> harness. It is simply out of control. We have different methods being
>> used in different plugins, nothing is standard and it's going to kill
>> us. The most prevalent tool, as defective as it might be is what is
>> being used in the ITs themselves. Stephane managed to use this
>> successfully in some of his plugins. Then after that we have an array
>> of usages. What should happen before we start writing more stuff is
>> to figure out something we can use now, and how to merge what we have
>> together instead of writing more tools.
>>
>> This is just to get the discussion started. I will take a first pass
>> at enumerating the collection of tools we have and where they are
>> used. But here are my notes from the main core ITs. Thus far as some
>> of the ideas pertain to ITs in general like not polluting the local
>> repo when testing ..
>>
>> Jason.
>>
>> ---
>>
>> - [-] Goals
>> - [ ] An IT should be completely self-contained so that the
>> problem
>> can be understood by looking in one place, in one Maven
>> project.
>> - [ ] We should be able to create an Archetype so that users can
>> easily create ITs for us
>> - [+] The ITs should be in a project of their own so that we can
>> reuse them across versions of Maven. We could actually run
>> new versions of integration tests against old versions of
>> Maven. Solution: the ITs are now in a separate build
>> and it
>> is possible to run them
>> - [ ] We should be able to easily integrate the IT into a larger
>> run where we can use forked or embedded execution.
>> - [ ] We should create Archetypes for all categories of
>> problems so
>> that anyone can generate tests cases for us. Then there
>> is so
>> much that we can do in terms of automating this process of
>> checking tests for quality along with the patches.
>> - [ ] automate the testing of ITs submitted by users
>> - [ ] Each IT should have its own repository if it needs
>> resources
>> from repository. We can't mess with a users repository
>> when
>> testing.
>> - [ ] We need to have a file system based remote repository for
>> testing
>> - [ ] We need to standardize on integration testing in
>> general. We
>> have people going all over the place and it's a disaster.
>> - [ ] We have too many IT plugins (3)
>> - [ ] We have too many invokers (5)
>> - [ ] We have too many verifiers (3)
>> - [ ] The ITs should run nicely from an IDE. Solution: this does
>> work but requires that you run mvn clean
>> resources:testResources first as the IDE doesn't know
>> how to
>> set that up. Needs to be fully fixed. But it is much nicer
>> running this stuff in your IDE.
>> - [-] Problems with ITs
>> - [+] Verifier jar required by the bootstrap requires a special
>> verifier.jar there is no released version of this tool.
>> Solution: the bootstrap now uses Ant and we've gotten
>> rid of
>> a lot of the complexity.
>> - [+] The maven-core-it plugin needs to be decoupled into its
>> separate purposes because there are currently 12 different
>> things going on in the plugin and it would be really
>> confusing for a new user to figure out what's going on
>> in the
>> plugin and how it applies to the integration testing.
>> Solution: these have now been broken down into plugins
>> that
>> correspond to their function in the ITs.
>> - [ ] it0006 is an integration test for the verifier plugin.
>> - [ ] it0014 uses the compiler plugin to test plugin
>> configuration.
>> - [ ] it0016 is an integration test for the WAR plugin.
>> - [ ] it0017 is an integration test for the EJB plugin.
>> - [ ] it0018 uses real dependencies to test artifact resolution.
>> - [ ] it0020 tests beanshell mojo support.
>> - [ ] it0024 uses the compiler plugin to test mojo
>> configuration.
>> - [ ] it0028 uses the compiler plugin to test mojo
>> configuration.
>> - [ ] it0029 uses the compiler plugin to test for
>> pluginManagement
>> injection of plugin configuration.
>> - [ ] it0033 is an integration test for the EAR plugin.
>> - [ ] it0043 uses the help plugin to look at the state of the
>> final
>> POM, we should have this built into Maven for testing.
>> - [ ] it0047 uses plexus-container-default for testing.
>> - [ ] it0048 uses the surefire plugin to test default value
>> population for mojo parameters.
>> - [ ] it0050 is an integration test for the surefire plugin.
>> - [ ] it0051 is an integration test for the release plugin.
>> - [ ] it0052 is an integration test for the release plugin.
>> - [ ] it0054 is an integration test for the resources plugin.
>> - [ ] it0055 is an integration test for the compiler plugin.
>> - [ ] it0056 uses the compiler plugin to test multiple
>> executions.
>> - [ ] it0060 uses the compiler plugin to test aggregation of
>> list
>> configuration items when using 'combine.children=append'
>> attribute.
>> - [ ] it0063 tests JDK 1.4.2 specifics.
>> - [ ] it0068 uses the modello plugin to test repository
>> accumulation (i'm not sure what that means, John?)
>> - [ ] it0069 uses classworlds dependency to test offline mode.
>> - [ ] it0070 is an integration test for the RAR plugin.
>> - [ ] it0074 uses the compiler plugin to test mojo
>> configuration.
>> - [ ] it0076 uses the WAR plugin to test pluginManagement.
>> - [ ] it0078 uses the compiler plugin to test pluginManagement.
>> - [ ] it0079 uses the source plugin to test that attached
>> artifacts
>> have the same build number as the primary artifact.
>> - [ ] it0080 uses the WAR plugin to test an artifact handler
>> that
>> specifies no contribution to transitive dependencies.
>> if the
>> behavior of this handler changed the test would break.
>> - [ ] it0081 uses production dependency of wagon as a dependency
>> - [ ] it0083 uses the WAR plugin to test an artifact handler
>> that
>> the WAR artifact handler currently behaves like
>> - [ ] it0086 uses production dependency of bsh to test
>> classloading
>> - [ ] it0087 uses prodcution dependency of commons-logging to
>> test
>> classloading
>> - [ ] it0089 is an integration test for the checkstyle plugin
>> - [ ] it0094 has a test that attempts to access a protected
>> field
>> in a ClassRealm
>> - [ ] it0095 uses the help and verifier plugins to test URL
>> calculation
>> - [ ] it0100 uses the antrun plugin to make sure
>> ${parent.artifactId} resolves correctly
>> - [ ] it0102 uses the help and antrun plugins to test profile
>> activation
>> - [ ] it0104 uses the surefire plugin to test interpolation
>> - [ ] it0105 is an integration test for the resources plugin
>> - [ ] artifactIds should be aligned with directories
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Integration Testing
Posted by David Whitehurst <dl...@gmail.com>.
Jason:
Here! here!
I recently joined the AppFuse bunch and being more the builder, packager,
deployer-type, I'm working on AppFuse2 and the use of the archetype. Since,
I've been on a large state project for Massachusetts, we have not used
Maven, so my knowledge of Maven has been some small use of Maven1. I'm am
so disappointed in my inability to just further or push the work on the
AppFuse archetype. It's bad for me personally because I'm a senior level
type but I can't just make good progress because I'm always having some
trouble determining *what* I'm supposed to do to get things to work.
AppFuse is difficult but Maven's even more difficult because I don't know
where the knowledge home is for every plugin, mojo, etc. I don't know *how*
I'm supposed to do things.
It seems that Maven and the Plugin World needs a roadmap and some throttling
of what gets created and what becomes public domain.
Thanks Jason for your work behind a great development tool and your work in
trying to slow things down.
David
On 12/11/06, Jason van Zyl <ja...@maven.org> wrote:
>
> Hi,
>
> This is in response to John's email about integration testing, some
> notes that I've taken while trying to clean up the integration
> testing, and some suggestions about where we go from here with
> respect to integration testing. You will see from the list below that
> there are many problems with the ITs ranging from integration tests
> for specific plugins being in there to using production dependencies,
> to having tons of duplicated for doing ITs.
>
> So, in response to John's email: I think we need to settle on what
> we're going to use and stop writing new tools. We have several
> invokers, several verifiers, several IT plugins, and the plugin
> harness. It is simply out of control. We have different methods being
> used in different plugins, nothing is standard and it's going to kill
> us. The most prevalent tool, as defective as it might be is what is
> being used in the ITs themselves. Stephane managed to use this
> successfully in some of his plugins. Then after that we have an array
> of usages. What should happen before we start writing more stuff is
> to figure out something we can use now, and how to merge what we have
> together instead of writing more tools.
>
> This is just to get the discussion started. I will take a first pass
> at enumerating the collection of tools we have and where they are
> used. But here are my notes from the main core ITs. Thus far as some
> of the ideas pertain to ITs in general like not polluting the local
> repo when testing ..
>
> Jason.
>
> ---
>
> - [-] Goals
> - [ ] An IT should be completely self-contained so that the problem
> can be understood by looking in one place, in one Maven
> project.
> - [ ] We should be able to create an Archetype so that users can
> easily create ITs for us
> - [+] The ITs should be in a project of their own so that we can
> reuse them across versions of Maven. We could actually run
> new versions of integration tests against old versions of
> Maven. Solution: the ITs are now in a separate build and it
> is possible to run them
> - [ ] We should be able to easily integrate the IT into a larger
> run where we can use forked or embedded execution.
> - [ ] We should create Archetypes for all categories of problems so
> that anyone can generate tests cases for us. Then there is so
> much that we can do in terms of automating this process of
> checking tests for quality along with the patches.
> - [ ] automate the testing of ITs submitted by users
> - [ ] Each IT should have its own repository if it needs resources
> from repository. We can't mess with a users repository when
> testing.
> - [ ] We need to have a file system based remote repository for
> testing
> - [ ] We need to standardize on integration testing in general. We
> have people going all over the place and it's a disaster.
> - [ ] We have too many IT plugins (3)
> - [ ] We have too many invokers (5)
> - [ ] We have too many verifiers (3)
> - [ ] The ITs should run nicely from an IDE. Solution: this does
> work but requires that you run mvn clean
> resources:testResources first as the IDE doesn't know how to
> set that up. Needs to be fully fixed. But it is much nicer
> running this stuff in your IDE.
> - [-] Problems with ITs
> - [+] Verifier jar required by the bootstrap requires a special
> verifier.jar there is no released version of this tool.
> Solution: the bootstrap now uses Ant and we've gotten rid of
> a lot of the complexity.
> - [+] The maven-core-it plugin needs to be decoupled into its
> separate purposes because there are currently 12 different
> things going on in the plugin and it would be really
> confusing for a new user to figure out what's going on in the
> plugin and how it applies to the integration testing.
> Solution: these have now been broken down into plugins that
> correspond to their function in the ITs.
> - [ ] it0006 is an integration test for the verifier plugin.
> - [ ] it0014 uses the compiler plugin to test plugin configuration.
> - [ ] it0016 is an integration test for the WAR plugin.
> - [ ] it0017 is an integration test for the EJB plugin.
> - [ ] it0018 uses real dependencies to test artifact resolution.
> - [ ] it0020 tests beanshell mojo support.
> - [ ] it0024 uses the compiler plugin to test mojo configuration.
> - [ ] it0028 uses the compiler plugin to test mojo configuration.
> - [ ] it0029 uses the compiler plugin to test for pluginManagement
> injection of plugin configuration.
> - [ ] it0033 is an integration test for the EAR plugin.
> - [ ] it0043 uses the help plugin to look at the state of the final
> POM, we should have this built into Maven for testing.
> - [ ] it0047 uses plexus-container-default for testing.
> - [ ] it0048 uses the surefire plugin to test default value
> population for mojo parameters.
> - [ ] it0050 is an integration test for the surefire plugin.
> - [ ] it0051 is an integration test for the release plugin.
> - [ ] it0052 is an integration test for the release plugin.
> - [ ] it0054 is an integration test for the resources plugin.
> - [ ] it0055 is an integration test for the compiler plugin.
> - [ ] it0056 uses the compiler plugin to test multiple executions.
> - [ ] it0060 uses the compiler plugin to test aggregation of list
> configuration items when using 'combine.children=append'
> attribute.
> - [ ] it0063 tests JDK 1.4.2 specifics.
> - [ ] it0068 uses the modello plugin to test repository
> accumulation (i'm not sure what that means, John?)
> - [ ] it0069 uses classworlds dependency to test offline mode.
> - [ ] it0070 is an integration test for the RAR plugin.
> - [ ] it0074 uses the compiler plugin to test mojo configuration.
> - [ ] it0076 uses the WAR plugin to test pluginManagement.
> - [ ] it0078 uses the compiler plugin to test pluginManagement.
> - [ ] it0079 uses the source plugin to test that attached artifacts
> have the same build number as the primary artifact.
> - [ ] it0080 uses the WAR plugin to test an artifact handler that
> specifies no contribution to transitive dependencies. if the
> behavior of this handler changed the test would break.
> - [ ] it0081 uses production dependency of wagon as a dependency
> - [ ] it0083 uses the WAR plugin to test an artifact handler that
> the WAR artifact handler currently behaves like
> - [ ] it0086 uses production dependency of bsh to test classloading
> - [ ] it0087 uses prodcution dependency of commons-logging to test
> classloading
> - [ ] it0089 is an integration test for the checkstyle plugin
> - [ ] it0094 has a test that attempts to access a protected field
> in a ClassRealm
> - [ ] it0095 uses the help and verifier plugins to test URL
> calculation
> - [ ] it0100 uses the antrun plugin to make sure
> ${parent.artifactId} resolves correctly
> - [ ] it0102 uses the help and antrun plugins to test profile
> activation
> - [ ] it0104 uses the surefire plugin to test interpolation
> - [ ] it0105 is an integration test for the resources plugin
> - [ ] artifactIds should be aligned with directories
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Integration Testing
Posted by John Casey <ca...@gmail.com>.
my only recommendation would be to take a look at the maven-assembly-plugin
(SVN:
http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-assembly-plugin)
and go for something like that...
On 4/16/07, Barrie Treloar <ba...@gmail.com> wrote:
>
> On 4/17/07, John Casey <ca...@gmail.com> wrote:
> > Jerome, that link contains information on the strategy I've been using
> in
> > the assembly plugin, and it seems to work well (although it's a bit
> slower,
> > since it's spawning so many Maven builds). I'm hoping to converge the
> tools
> > we're using in the core ITs with those in the
> maven-component-test-plugin
> > (used to be maven-plugin-test-plugin), and the maven-invoker-plugin, and
> > arrive at some single solution (a plugin) that we can use
> everywhere...but I
> > haven't even been able to come up with a unified feature list yet.
>
> So, does anyone have a recommended approach so I can move forward in
> the mean time?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Integration Testing
Posted by Barrie Treloar <ba...@gmail.com>.
On 4/17/07, John Casey <ca...@gmail.com> wrote:
> Jerome, that link contains information on the strategy I've been using in
> the assembly plugin, and it seems to work well (although it's a bit slower,
> since it's spawning so many Maven builds). I'm hoping to converge the tools
> we're using in the core ITs with those in the maven-component-test-plugin
> (used to be maven-plugin-test-plugin), and the maven-invoker-plugin, and
> arrive at some single solution (a plugin) that we can use everywhere...but I
> haven't even been able to come up with a unified feature list yet.
So, does anyone have a recommended approach so I can move forward in
the mean time?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Integration Testing
Posted by John Casey <ca...@gmail.com>.
Jerome, that link contains information on the strategy I've been using in
the assembly plugin, and it seems to work well (although it's a bit slower,
since it's spawning so many Maven builds). I'm hoping to converge the tools
we're using in the core ITs with those in the maven-component-test-plugin
(used to be maven-plugin-test-plugin), and the maven-invoker-plugin, and
arrive at some single solution (a plugin) that we can use everywhere...but I
haven't even been able to come up with a unified feature list yet.
-john
On 4/15/07, Jerome Lacoste <je...@gmail.com> wrote:
>
> On 2/24/07, Brett Porter <br...@apache.org> wrote:
> > On 04/01/2007, at 4:32 PM, Brett Porter wrote:
> >
> > > Jason - any further thoughts on this?
> >
> > Ping... No is a valid answer :)
> >
> > I'd like to get your summary put somewhere individuals can pick
> > things off to work on - probably a jira project for shared. WDYT?
> >
> > I'm overcommitted for working on things right now, but I know a
> > couple of people are confused about the IT testing, and we've got all
> > those chronically broken plugins. Volunteers?
>
> I want to improve the state of IT for the mojos I work with (in
> particular in the mojo project). I am particularly interested in doing
> it in an sort of official/standard way.
>
>
> - [ ] We need to standardize on integration testing in general. We
> have people going all over the place and it's a disaster.
> - [ ] We have too many IT plugins (3)
> - [ ] We have too many invokers (5)
> - [ ] We have too many verifiers (3)
>
> I've found this:
> http://maven.apache.org/developers/committer-testing-plugins.html
>
> Does that represent the current IT strategy 'standard' ? Was that
> written after the point above was resolved ?
>
> Cheers,
>
> Jerome
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Integration Testing
Posted by Jerome Lacoste <je...@gmail.com>.
On 2/24/07, Brett Porter <br...@apache.org> wrote:
> On 04/01/2007, at 4:32 PM, Brett Porter wrote:
>
> > Jason - any further thoughts on this?
>
> Ping... No is a valid answer :)
>
> I'd like to get your summary put somewhere individuals can pick
> things off to work on - probably a jira project for shared. WDYT?
>
> I'm overcommitted for working on things right now, but I know a
> couple of people are confused about the IT testing, and we've got all
> those chronically broken plugins. Volunteers?
I want to improve the state of IT for the mojos I work with (in
particular in the mojo project). I am particularly interested in doing
it in an sort of official/standard way.
- [ ] We need to standardize on integration testing in general. We
have people going all over the place and it's a disaster.
- [ ] We have too many IT plugins (3)
- [ ] We have too many invokers (5)
- [ ] We have too many verifiers (3)
I've found this:
http://maven.apache.org/developers/committer-testing-plugins.html
Does that represent the current IT strategy 'standard' ? Was that
written after the point above was resolved ?
Cheers,
Jerome
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Integration Testing
Posted by Barrie Treloar <ba...@gmail.com>.
On 2/24/07, Jason van Zyl <ja...@maven.org> wrote:
> > I'd like to get your summary put somewhere individuals can pick
> > things off to work on - probably a jira project for shared. WDYT?
> >
>
> I put the summary here for now, it's pretty elaborate and can most
> likely be worked on easily. Given one or two people have expressed
> interested or worked on the ITs I think that will suffice.
>
> http://svn.apache.org/repos/asf/maven/core-integration-testing/trunk/
> ITProblems.txt
>
Is there something that describes how to setup IT tests for plugins
and how to go about it?
I'm trying to use TDD to verify that the plugin I am testing, is
correctly attaching the write output to the project. via setArtifact
and addAttachedArtifact.
I'm not sure how to go about doing this.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Integration Testing
Posted by Jason van Zyl <ja...@maven.org>.
On 23 Feb 07, at 10:08 PM 23 Feb 07, Brett Porter wrote:
> On 04/01/2007, at 4:32 PM, Brett Porter wrote:
>
>> Jason - any further thoughts on this?
>
> Ping... No is a valid answer :)
>
> I'd like to get your summary put somewhere individuals can pick
> things off to work on - probably a jira project for shared. WDYT?
>
I put the summary here for now, it's pretty elaborate and can most
likely be worked on easily. Given one or two people have expressed
interested or worked on the ITs I think that will suffice.
http://svn.apache.org/repos/asf/maven/core-integration-testing/trunk/
ITProblems.txt
The top things that could be done:
1) The issues that would be most helpful that could be tackled on a
piecewise basis by many would be to take plugin specific ITs out of
the ITs. There are many in there for the surefire plugin so while
you're doing that you can look at it. Piecewise but probably totally
simple because you have to replace it with an IT that actually tests
what it was testing. A lot of time I have had to make a new IT plugin
flavour.
2) The next issue of importance would be to collect all the in IT
plugin plugins, invokers and verifiers and align all theses.
3) Once 2) is done then we wire the embedder option into the
resulting invoker.
As far as them working in situ: the ITs could now run from the top
level of http://svn.apache.org/repos/asf/maven/core-integration-
testing/trunk/ with an addition to the POM. It's not there because I
generally build from the top-level and then walk into http://
svn.apache.org/repos/asf/maven/core-integration-testing/trunk/core-
integration-tests/. The invoker plugin has been released and that's
what I used to install the supporting artifacts because they can't
install in a reactor run normally because there are 5 artifacts with
the id.
I am not entirely happy with the structure we have but I don't think
it's worth changing right now until 1) and 2) are done. It's not
obvious how to run them from and IDE and that's where I've found it
to be most convenient to run them.
> I'm overcommitted for working on things right now, but I know a
> couple of people are confused about the IT testing, and we've got
> all those chronically broken plugins. Volunteers?
>
>> On 18/12/2006, at 4:35 PM, Brett Porter wrote:
>>
>>>
>>> On 12/12/2006, at 5:08 AM, Jason van Zyl wrote:
>>>
>>>> So, in response to John's email: I think we need to settle on
>>>> what we're going to use and stop writing new tools. We have
>>>> several invokers, several verifiers, several IT plugins, and the
>>>> plugin harness. It is simply out of control. We have different
>>>> methods being used in different plugins, nothing is standard and
>>>> it's going to kill us. The most prevalent tool, as defective as
>>>> it might be is what is being used in the ITs themselves.
>>>> Stephane managed to use this successfully in some of his
>>>> plugins. Then after that we have an array of usages. What should
>>>> happen before we start writing more stuff is to figure out
>>>> something we can use now, and how to merge what we have together
>>>> instead of writing more tools.
>>>
>>> Agreed. I think that's what John was getting at too, but by doing
>>> it clean rather than rewriting something that was in use
>>> somewhere. So the work left to do, in either case, is apply it
>>> consistently and get rid of the stuff we aren't going to use.
>>>
>>> To me, it looks like:
>>> - the plugin-testing-harness needs to go. They should be
>>> integration tests that use a proper pom, or use pure mocks rather
>>> than the stubs that tend to just have a bunch of impossible-to-
>>> get-under-real-condition values.
>>> - John's test tools have the most complete invocation options,
>>> and tools for managing repositories that we can reuse, so I'd opt
>>> for that in that area
>>> - the verifier is well utilised, so if that is merged with the
>>> code from the verifier plugin then we can lose the invocation
>>> stuff and repository management stuff and merge it all together
>>>
>>> Can we have a wiki page with this work list? Or, can we check in
>>> the omni outliner files + an export for the non-mac users to review?
>>>
>>> [snip points I agree with]
>>>
>>>> - [+] The ITs should be in a project of their own so that we
>>>> can
>>>> reuse them across versions of Maven. We could actually
>>>> run
>>>> new versions of integration tests against old versions of
>>>> Maven. Solution: the ITs are now in a separate build
>>>> and it
>>>> is possible to run them
>>>
>>> How should this play out in plugins? I would be in favour of
>>> separate projects for these.
>>>
>>> Two things that are must haves for me:
>>> - integration tests / anything that forks a Maven instance must
>>> *not* be part of the normal test build for a plugin. They take
>>> way too long, and lead to use of maven.test.skip :(
>>> - as far as integration testing in general, I think we recommend
>>> a separate project, but enable them to be part of the same
>>> project for simplicity of development (this is more specific to
>>> things like web applications where it is probably beneficial).
>>>
>>>> - [ ] We should be able to easily integrate the IT into a
>>>> larger
>>>> run where we can use forked or embedded execution.
>>>
>>> Not sure what you mean here. What is an IT that *doesn't* use
>>> forked or embedded execution?
>>>
>>>> - [ ] automate the testing of ITs submitted by users
>>>
>>> what does this mean? I think, like a patch, a submitted IT still
>>> needs to be reviewed, and incorporated into the main test suite
>>> (with corresponding fix-for version so it only runs when it is
>>> expected to work). Otherwise, long term, we'll have lots of
>>> duplicated or poorly conceived ITs. I've seen test cases
>>> submitted that are quite useful at demonstrating something, but
>>> contain half of the user's proect which is not good for our long
>>> term scalability.
>>>
>>>> - [ ] Each IT should have its own repository if it needs
>>>> resources
>>>> from repository. We can't mess with a users repository
>>>> when
>>>> testing.
>>>> - [ ] We need to have a file system based remote repository for
>>>> testing
>>>
>>> Agreed. Isn't that what John's tool already does?
>>>
>>>> - [ ] We need to standardize on integration testing in
>>>> general. We
>>>> have people going all over the place and it's a disaster.
>>>> - [ ] We have too many IT plugins (3)
>>>> - [ ] We have too many invokers (5)
>>>> - [ ] We have too many verifiers (3)
>>>
>>> Let's specifically get these mapped out and a path forward so
>>> that everyone can push towards it, rather than relying on you to
>>> do the work.
>>>
>>>> - [ ] The ITs should run nicely from an IDE. Solution: this
>>>> does
>>>> work but requires that you run mvn clean
>>>> resources:testResources first as the IDE doesn't know
>>>> how to
>>>> set that up. Needs to be fully fixed. But it is much
>>>> nicer
>>>> running this stuff in your IDE.
>>>
>>> Agree with the point, but not sure what you are referring to
>>> about testResources - the generated projects for IDEA and I think
>>> Eclipse already do this (and obviously better integration will
>>> bring it).
>>>
>>> I think the dangerous thing is using resources for non-classpath
>>> resources. It's better for the tests to setup and use a clean
>>> project instance for an IT itself (using helper tools).
>>>
>>> [snip specific notes on old ITs that need to be updated]
>>>
>>>> - [ ] artifactIds should be aligned with directories
>>>
>>> Agreed. Also, as I did in the last test I wrote, what do we think
>>> about using purposeful names rather than numbers for integration
>>> tests?
>>>
>>> Thanks for this.
>>>
>>> Cheers,
>>> Brett
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Integration Testing
Posted by Brett Porter <br...@apache.org>.
On 04/01/2007, at 4:32 PM, Brett Porter wrote:
> Jason - any further thoughts on this?
Ping... No is a valid answer :)
I'd like to get your summary put somewhere individuals can pick
things off to work on - probably a jira project for shared. WDYT?
I'm overcommitted for working on things right now, but I know a
couple of people are confused about the IT testing, and we've got all
those chronically broken plugins. Volunteers?
> On 18/12/2006, at 4:35 PM, Brett Porter wrote:
>
>>
>> On 12/12/2006, at 5:08 AM, Jason van Zyl wrote:
>>
>>> So, in response to John's email: I think we need to settle on
>>> what we're going to use and stop writing new tools. We have
>>> several invokers, several verifiers, several IT plugins, and the
>>> plugin harness. It is simply out of control. We have different
>>> methods being used in different plugins, nothing is standard and
>>> it's going to kill us. The most prevalent tool, as defective as
>>> it might be is what is being used in the ITs themselves. Stephane
>>> managed to use this successfully in some of his plugins. Then
>>> after that we have an array of usages. What should happen before
>>> we start writing more stuff is to figure out something we can use
>>> now, and how to merge what we have together instead of writing
>>> more tools.
>>
>> Agreed. I think that's what John was getting at too, but by doing
>> it clean rather than rewriting something that was in use
>> somewhere. So the work left to do, in either case, is apply it
>> consistently and get rid of the stuff we aren't going to use.
>>
>> To me, it looks like:
>> - the plugin-testing-harness needs to go. They should be
>> integration tests that use a proper pom, or use pure mocks rather
>> than the stubs that tend to just have a bunch of impossible-to-get-
>> under-real-condition values.
>> - John's test tools have the most complete invocation options, and
>> tools for managing repositories that we can reuse, so I'd opt for
>> that in that area
>> - the verifier is well utilised, so if that is merged with the
>> code from the verifier plugin then we can lose the invocation
>> stuff and repository management stuff and merge it all together
>>
>> Can we have a wiki page with this work list? Or, can we check in
>> the omni outliner files + an export for the non-mac users to review?
>>
>> [snip points I agree with]
>>
>>> - [+] The ITs should be in a project of their own so that we can
>>> reuse them across versions of Maven. We could actually run
>>> new versions of integration tests against old versions of
>>> Maven. Solution: the ITs are now in a separate build
>>> and it
>>> is possible to run them
>>
>> How should this play out in plugins? I would be in favour of
>> separate projects for these.
>>
>> Two things that are must haves for me:
>> - integration tests / anything that forks a Maven instance must
>> *not* be part of the normal test build for a plugin. They take way
>> too long, and lead to use of maven.test.skip :(
>> - as far as integration testing in general, I think we recommend a
>> separate project, but enable them to be part of the same project
>> for simplicity of development (this is more specific to things
>> like web applications where it is probably beneficial).
>>
>>> - [ ] We should be able to easily integrate the IT into a larger
>>> run where we can use forked or embedded execution.
>>
>> Not sure what you mean here. What is an IT that *doesn't* use
>> forked or embedded execution?
>>
>>> - [ ] automate the testing of ITs submitted by users
>>
>> what does this mean? I think, like a patch, a submitted IT still
>> needs to be reviewed, and incorporated into the main test suite
>> (with corresponding fix-for version so it only runs when it is
>> expected to work). Otherwise, long term, we'll have lots of
>> duplicated or poorly conceived ITs. I've seen test cases submitted
>> that are quite useful at demonstrating something, but contain half
>> of the user's proect which is not good for our long term scalability.
>>
>>> - [ ] Each IT should have its own repository if it needs
>>> resources
>>> from repository. We can't mess with a users repository
>>> when
>>> testing.
>>> - [ ] We need to have a file system based remote repository for
>>> testing
>>
>> Agreed. Isn't that what John's tool already does?
>>
>>> - [ ] We need to standardize on integration testing in
>>> general. We
>>> have people going all over the place and it's a disaster.
>>> - [ ] We have too many IT plugins (3)
>>> - [ ] We have too many invokers (5)
>>> - [ ] We have too many verifiers (3)
>>
>> Let's specifically get these mapped out and a path forward so that
>> everyone can push towards it, rather than relying on you to do the
>> work.
>>
>>> - [ ] The ITs should run nicely from an IDE. Solution: this does
>>> work but requires that you run mvn clean
>>> resources:testResources first as the IDE doesn't know
>>> how to
>>> set that up. Needs to be fully fixed. But it is much nicer
>>> running this stuff in your IDE.
>>
>> Agree with the point, but not sure what you are referring to about
>> testResources - the generated projects for IDEA and I think
>> Eclipse already do this (and obviously better integration will
>> bring it).
>>
>> I think the dangerous thing is using resources for non-classpath
>> resources. It's better for the tests to setup and use a clean
>> project instance for an IT itself (using helper tools).
>>
>> [snip specific notes on old ITs that need to be updated]
>>
>>> - [ ] artifactIds should be aligned with directories
>>
>> Agreed. Also, as I did in the last test I wrote, what do we think
>> about using purposeful names rather than numbers for integration
>> tests?
>>
>> Thanks for this.
>>
>> Cheers,
>> Brett
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Integration Testing
Posted by Brett Porter <br...@apache.org>.
Jason - any further thoughts on this?
On 18/12/2006, at 4:35 PM, Brett Porter wrote:
>
> On 12/12/2006, at 5:08 AM, Jason van Zyl wrote:
>
>> So, in response to John's email: I think we need to settle on what
>> we're going to use and stop writing new tools. We have several
>> invokers, several verifiers, several IT plugins, and the plugin
>> harness. It is simply out of control. We have different methods
>> being used in different plugins, nothing is standard and it's
>> going to kill us. The most prevalent tool, as defective as it
>> might be is what is being used in the ITs themselves. Stephane
>> managed to use this successfully in some of his plugins. Then
>> after that we have an array of usages. What should happen before
>> we start writing more stuff is to figure out something we can use
>> now, and how to merge what we have together instead of writing
>> more tools.
>
> Agreed. I think that's what John was getting at too, but by doing
> it clean rather than rewriting something that was in use somewhere.
> So the work left to do, in either case, is apply it consistently
> and get rid of the stuff we aren't going to use.
>
> To me, it looks like:
> - the plugin-testing-harness needs to go. They should be
> integration tests that use a proper pom, or use pure mocks rather
> than the stubs that tend to just have a bunch of impossible-to-get-
> under-real-condition values.
> - John's test tools have the most complete invocation options, and
> tools for managing repositories that we can reuse, so I'd opt for
> that in that area
> - the verifier is well utilised, so if that is merged with the code
> from the verifier plugin then we can lose the invocation stuff and
> repository management stuff and merge it all together
>
> Can we have a wiki page with this work list? Or, can we check in
> the omni outliner files + an export for the non-mac users to review?
>
> [snip points I agree with]
>
>> - [+] The ITs should be in a project of their own so that we can
>> reuse them across versions of Maven. We could actually run
>> new versions of integration tests against old versions of
>> Maven. Solution: the ITs are now in a separate build and it
>> is possible to run them
>
> How should this play out in plugins? I would be in favour of
> separate projects for these.
>
> Two things that are must haves for me:
> - integration tests / anything that forks a Maven instance must
> *not* be part of the normal test build for a plugin. They take way
> too long, and lead to use of maven.test.skip :(
> - as far as integration testing in general, I think we recommend a
> separate project, but enable them to be part of the same project
> for simplicity of development (this is more specific to things like
> web applications where it is probably beneficial).
>
>> - [ ] We should be able to easily integrate the IT into a larger
>> run where we can use forked or embedded execution.
>
> Not sure what you mean here. What is an IT that *doesn't* use
> forked or embedded execution?
>
>> - [ ] automate the testing of ITs submitted by users
>
> what does this mean? I think, like a patch, a submitted IT still
> needs to be reviewed, and incorporated into the main test suite
> (with corresponding fix-for version so it only runs when it is
> expected to work). Otherwise, long term, we'll have lots of
> duplicated or poorly conceived ITs. I've seen test cases submitted
> that are quite useful at demonstrating something, but contain half
> of the user's proect which is not good for our long term scalability.
>
>> - [ ] Each IT should have its own repository if it needs
>> resources
>> from repository. We can't mess with a users repository when
>> testing.
>> - [ ] We need to have a file system based remote repository for
>> testing
>
> Agreed. Isn't that what John's tool already does?
>
>> - [ ] We need to standardize on integration testing in
>> general. We
>> have people going all over the place and it's a disaster.
>> - [ ] We have too many IT plugins (3)
>> - [ ] We have too many invokers (5)
>> - [ ] We have too many verifiers (3)
>
> Let's specifically get these mapped out and a path forward so that
> everyone can push towards it, rather than relying on you to do the
> work.
>
>> - [ ] The ITs should run nicely from an IDE. Solution: this does
>> work but requires that you run mvn clean
>> resources:testResources first as the IDE doesn't know
>> how to
>> set that up. Needs to be fully fixed. But it is much nicer
>> running this stuff in your IDE.
>
> Agree with the point, but not sure what you are referring to about
> testResources - the generated projects for IDEA and I think Eclipse
> already do this (and obviously better integration will bring it).
>
> I think the dangerous thing is using resources for non-classpath
> resources. It's better for the tests to setup and use a clean
> project instance for an IT itself (using helper tools).
>
> [snip specific notes on old ITs that need to be updated]
>
>> - [ ] artifactIds should be aligned with directories
>
> Agreed. Also, as I did in the last test I wrote, what do we think
> about using purposeful names rather than numbers for integration
> tests?
>
> Thanks for this.
>
> Cheers,
> Brett
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Integration Testing
Posted by Brett Porter <br...@apache.org>.
On 12/12/2006, at 5:08 AM, Jason van Zyl wrote:
> So, in response to John's email: I think we need to settle on what
> we're going to use and stop writing new tools. We have several
> invokers, several verifiers, several IT plugins, and the plugin
> harness. It is simply out of control. We have different methods
> being used in different plugins, nothing is standard and it's going
> to kill us. The most prevalent tool, as defective as it might be is
> what is being used in the ITs themselves. Stephane managed to use
> this successfully in some of his plugins. Then after that we have
> an array of usages. What should happen before we start writing more
> stuff is to figure out something we can use now, and how to merge
> what we have together instead of writing more tools.
Agreed. I think that's what John was getting at too, but by doing it
clean rather than rewriting something that was in use somewhere. So
the work left to do, in either case, is apply it consistently and get
rid of the stuff we aren't going to use.
To me, it looks like:
- the plugin-testing-harness needs to go. They should be integration
tests that use a proper pom, or use pure mocks rather than the stubs
that tend to just have a bunch of impossible-to-get-under-real-
condition values.
- John's test tools have the most complete invocation options, and
tools for managing repositories that we can reuse, so I'd opt for
that in that area
- the verifier is well utilised, so if that is merged with the code
from the verifier plugin then we can lose the invocation stuff and
repository management stuff and merge it all together
Can we have a wiki page with this work list? Or, can we check in the
omni outliner files + an export for the non-mac users to review?
[snip points I agree with]
> - [+] The ITs should be in a project of their own so that we can
> reuse them across versions of Maven. We could actually run
> new versions of integration tests against old versions of
> Maven. Solution: the ITs are now in a separate build and it
> is possible to run them
How should this play out in plugins? I would be in favour of separate
projects for these.
Two things that are must haves for me:
- integration tests / anything that forks a Maven instance must *not*
be part of the normal test build for a plugin. They take way too
long, and lead to use of maven.test.skip :(
- as far as integration testing in general, I think we recommend a
separate project, but enable them to be part of the same project for
simplicity of development (this is more specific to things like web
applications where it is probably beneficial).
> - [ ] We should be able to easily integrate the IT into a larger
> run where we can use forked or embedded execution.
Not sure what you mean here. What is an IT that *doesn't* use forked
or embedded execution?
> - [ ] automate the testing of ITs submitted by users
what does this mean? I think, like a patch, a submitted IT still
needs to be reviewed, and incorporated into the main test suite (with
corresponding fix-for version so it only runs when it is expected to
work). Otherwise, long term, we'll have lots of duplicated or poorly
conceived ITs. I've seen test cases submitted that are quite useful
at demonstrating something, but contain half of the user's proect
which is not good for our long term scalability.
> - [ ] Each IT should have its own repository if it needs resources
> from repository. We can't mess with a users repository when
> testing.
> - [ ] We need to have a file system based remote repository for
> testing
Agreed. Isn't that what John's tool already does?
> - [ ] We need to standardize on integration testing in general. We
> have people going all over the place and it's a disaster.
> - [ ] We have too many IT plugins (3)
> - [ ] We have too many invokers (5)
> - [ ] We have too many verifiers (3)
Let's specifically get these mapped out and a path forward so that
everyone can push towards it, rather than relying on you to do the work.
> - [ ] The ITs should run nicely from an IDE. Solution: this does
> work but requires that you run mvn clean
> resources:testResources first as the IDE doesn't know how to
> set that up. Needs to be fully fixed. But it is much nicer
> running this stuff in your IDE.
Agree with the point, but not sure what you are referring to about
testResources - the generated projects for IDEA and I think Eclipse
already do this (and obviously better integration will bring it).
I think the dangerous thing is using resources for non-classpath
resources. It's better for the tests to setup and use a clean project
instance for an IT itself (using helper tools).
[snip specific notes on old ITs that need to be updated]
> - [ ] artifactIds should be aligned with directories
Agreed. Also, as I did in the last test I wrote, what do we think
about using purposeful names rather than numbers for integration tests?
Thanks for this.
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org