Hi Andreas,
In your use case I would keep everything in the same foo project but I
would generate a kind of 'testutils' jar.
>From what I understood your project structure is a bit like
foo
src/main/java
src/test/java
com.yourcompany.tests.utils
com.yourcompany.tests.yourtests
Then using `maven-jar-plugin` (see [1]) I would generate a dedicated jar
with classifier 'testutils' using only tests classes of
com.yourcompany.tests.utils package (filter what you need) resulting in
producing/publishing an additional foo-X.Y.Z-testutils.jar
Then client projects would need to use 2 dependencies
<dependency>
<artifactId>foo</artifactId>
<version>X.Y.Z</version>
</dependency>
<dependency>
<artifactId>foo</artifactId>
<version>X.Y.Z</version>
<classifier>testutils</ classifier>
<type>jar</type>
<scope>test</scope>
</dependency>
Hope it can help.
Matthieu
[1] :
https://maven.apache.org/plugins/maven-jar-plugin/examples/attached-jar.html
On Fri, Mar 13, 2020 at 1:49 PM Nick Stolwijk <nick.stolw...@gmail.com>
wrote:
> Put the testutils and the tests in the same project as foo in src/test/java
> and make the tests package private (JUnit Jupiter). Other projects can
> depend on the test artifact of foo and only use the test-utils.
>
> Hth,
>
> Nick Stolwijk
>
> ~~~ Try to leave this world a little better than you found it and, when
> your turn comes to die, you can die happy in feeling that at any rate you
> have not wasted your time but have done your best ~~~
>
> Lord Baden-Powell
>
>
> On Fri, Mar 13, 2020 at 12:01 PM Zak Mc Kracken <zakmc...@yahoo.it.invalid
> >
> wrote:
>
> > On 12/03/2020 13:55, Andreas Sewe wrote:
> >
> > If the test utilities are simple enough and are somehow specific to foo,
> > I would put them into foo, under src/main/java, in a package like
> > com.foo.testing. If they are more general, so that they could be used to
> > write tests for some other package not related to foo, I would create a
> > test-utils module. For instance, a utility to verify that an SQL string
> > parameter yields a given result parameter would go into such a module.
> >
> > If the test utils so complex that foo would become too big and would
> > drag too many not-often-used dependencies, but they're foo-specific, I
> > would create the module foo-test-utils and both foo and foo-testing
> > would depend on it. This is similar to creating test-utils.
> >
> > Option 3 creates a circular dependency and it's not to clean anyway
> > (even if you had a way to remove the circularity from the technical
> > point of view, it would remain at conceptual level). Attaching tests
> > seems to be less clear and forces a dependant to link all the tests just
> > to be able to include some utility. I happened to do it only for already
> > existing and hard-to-refactor projects, and only for the purpose making
> > the dependant extract some common files inside test/resources.
> >
> > Hope it helps,
> > Marco
> >
> > > Hi,
> > >
> > > I am struggling to figure out what the Maven Way is for distributing
> > > test utils.
> > >
> > > Say I have a project "foo" along with some unit tests for it. Moreover,
> > > I have some utilities that help in testing "foo" (e.g., test data
> > > builders or test fixtures). These utilities are used by the unit tests
> > > for "foo", but may also be useful to projects depending on "foo" (e.g.,
> > > a FooTestDataBuilder that produces Foo instances could also be used in
> > > the tests of a dependent project "bar").
> > >
> > > The question is where to place these test utilities and how to depend
> on
> > > them.
> > >
> > > 1. I could follow the "guide to using attached tests" [1], place the
> > > test utilizes in foo/src/test/java, and attach the test-jar to "foo".
> > > Then, a dependent project "bar" could depend on the test-jar in its
> test
> > > scope. Alas, as the test scope is not transitive, I would need to
> > > declare all test-dependencies of "foo" again in "bar", even though I
> may
> > > not even use them directly (e.g., if the FooTestDataBuilder uses them
> > > only internally).
> > >
> > > 2. I could split "foo" into three projects: "foo", "foo-test-utils",
> and
> > > "foo-tests", with the latter depending on both "foo-test-utils" and
> > > "foo-tests". A project "bar" would then simply depend on "foo" in
> > > compile scope and "foo-test-utils" in test scope. This would make all
> > > dependencies explicit, but would result in some oddities, e.g.,
> > > foo-tests/src/main/java being empty, as all tests need to be placed in
> > > tests/src/test/java to be picked up by Surefire.
> > >
> > > 3. I could split "foo" into just two projects, "foo" and "foo-testing".
> > > foo-testing/src/main/java would the contain the test utilities for
> > > "foo", whereas foo-testing/src/test/java would contain the actual
> tests.
> > > This is again somewhat odd, as the tests in foo-testing/src/test/java
> > > are not testing "foo-testing" but "foo".
> > >
> > > 4. Option 4 is the most natural way, but unfortunately it doesn't work,
> > > because it introduces a cyclic dependency: Have "foo" and
> > > "foo-test-utils" and let the tests of "foo" depend on "foo-test-utils".
> > >
> > > Am I missing something? In particular, why is [1] apparently the
> > > recommended approach, even though it requires you to duplicate
> > > dependency information?
> > >
> > > Any suggestions are greatly appreciated.
> > >
> > > Best wishes,
> > >
> > > Andreas
> > >
> > > [1] <https://maven.apache.org/guides/mini/guide-attached-tests.html>
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>
