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