Yegor,

If you look at the links he put in the 1st message it shows the POM he's
talking about. It includes multiple "execution" sections within the surefire
plugin section that run the tests only after building and deploying
something (I guess its the code being tested). Each "execution" of the tests
has some properties set so that the tests run somehow differently.

Since the test jar is already built maybe its easier than we thought. This
is just a hint of an idea though ...

Maybe, Tim could create a POM of his own that has that test jar as a
dependency of test scope. Then he could use a single AllTest.java in
src/test/java somewhere that has a suite() method that tells SureFire about
the tests that should be run. Those tests would all be in the test-jar. The
only maintenence here is that if the underlying code adds some tests or
comes out with a new version with new tests, he would have to find their
names and add them to the suite.

Tim's new pom would not be a child of the project's pom but would have
similar "execution" sections under the SureFire plugin section.

-- Lee

On Fri, Mar 25, 2011 at 12:20 PM, Yegor Bugayenko
<e...@technoparkcorp.com>wrote:

> In such a case (if you still want to reuse tests apart from the SUT they
> are
> designed for) your approach with dependency:unpack looks correct.
>
> But again, I would suggest to analyze the reason behind this operation and
> do everything you can to avoid this artificial separation of the SUT
> (system
> under testing) and its tests.
>
> —
> Yegor Bugayenko, PMP®, SCEA
>
>
>
> On Fri, Mar 25, 2011 at 11:02 AM, Tim Pizey <tim.pi...@gmail.com> wrote:
>
> > Thanks for your comments Yegor, however you do not address the question,
> > perhaps I did not put it well.
> >
> > What is the best way to re-use tests, given that Surefire will not
> discover
> > tests in a jar and you cannot extend a non-pom project?
> >
> > I feel that the solution I have come up with is pretty clunky and would
> > welcome
> > a more elegant to the problem of test reuse.
> >
> > cheers
> > Tim
> >
> >
> >
> >
> >
> >
> > On 24 March 2011 08:08, Yegor Bugayenko wrote:
> > > What is the point of retesting a library which has already been tested?
> > > You need your own tests, that will check the validity of your own
> > > application, not a third-party library. If you want to reuse some code
> > from
> > > the library - just get their .java files from their repository and add
> > them
> > > to your project statically (don't forget to review their license
> > > restrictions).
> > > —
> > > Yegor Bugayenko, PMP®, SCEA
> > >
> > >
> > >
> > > On Tue, Mar 22, 2011 at 12:17 PM, Tim Pizey <tim.pi...@gmail.com>
> wrote:
> > >>
> > >> Hi,
> > >>
> > >> Atombeat http://code.google.com/p/atombeat/ has a set of possible
> > >> configurations with different backends and security policies.
> > >>
> > >>     atombeat-exist-full
> > >>     atombeat-exist-minimal
> > >>     atombeat-exist-full-secure
> > >>     atombeat-exist-minimal-secure
> > >>     atombeat-orbeon-full
> > >>     atombeat-orbeon-minimal
> > >>     atombeat-orbeon-full-secure
> > >>     atombeat-orbeon-minimal-secure
> > >>
> > >> Atombeat  has a separate project which contains the tests for all of
> the
> > >> above:
> > >>
> > >>
> >
> http://code.google.com/p/atombeat/source/browse/trunk/parent/atombeat-integration-tests/pom.xml
> > >>
> > >> As an Atombeat user I want to re-purpose these tests to test a
> > >> particular Atombeat installation, with a different security mechanism
> > >> (CAS).
> > >>
> > >> Because the Atombeat tests test a set of different configurations some
> > >> are not applicable - testing security on an unsecured configuration
> > >> for example - so the tests pom file contains a lot of configuration
> > >> information.
> > >> I had hoped to be able to inherit from the Atombeat test pom, ie set
> > >> it as parent, but parents may only be of type pom.
> > >>
> > >> The Atombeat test source is in src/test/java, so currently no jar file
> > >> is produced.
> > >>
> > >> I can fix that by adding
> > >>
> > >>     <plugin>
> > >>        <groupId>org.apache.maven.plugins</groupId>
> > >>        <artifactId>maven-jar-plugin</artifactId>
> > >>        <executions>
> > >>          <execution>
> > >>            <goals>
> > >>              <goal>test-jar</goal>
> > >>            </goals>
> > >>          </execution>
> > >>        </executions>
> > >>      </plugin>
> > >>
> > >> however the surefire plugin will not run the tests as it does not look
> > >> inside jars to discover tests.
> > >>
> > >> Unpacking the jar into target/test-classes gets the tests discovered
> > >> by Surefire.
> > >>
> > >> I then need to configure my project by duplicating the configuration
> > >> information in the test POM.
> > >>
> > >> Is this the best way to reuse tests?
> > >>
> > >> cheers
> > >> Tim
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> --
> > >> Tim Pizey - http://pizey.net/~timp
> > >> Centre for Genomics and Global Health - http://cggh.org
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > >> For additional commands, e-mail: users-h...@maven.apache.org
> > >>
> > >
> > >
> >
> >
> >
> > --
> > Tim Pizey - http://pizey.net/~timp
> > Centre for Genomics and Global Health - http://cggh.org
> >
>



-- 
-- Lee Meador
Sent from gmail. My real email address is lee AT leemeador.com

Reply via email to