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 > > > > >