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