Anders Hammar wrote: > I'd say option 4 is the way to go. But you need to solve the circular > dependency problem. One way is to have a third api project/module, which > foo-test-utils have a compile time dependency on. Here you could use the > Service Provider Interface pattern.
>> 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". I don't think adding a SPI can be used to make option 4 work. Simplest case: - Project "foo" contains a class Foo. - Project "foo-test-utils" contains a class FooTestDataBuilder, whose code obviously refers to Foo. Hence, "foo-test-utils" needs a compile-scoped dependency on "foo" - Tests in project "foo" would like to use the FooTestDataBuilder. Even I add a IFooTestDataBuilder interface, I could get the tests of project "foo" to *compile*, but to actually *run* them, I would need a FooTestDataBuilder -- which is defined in the *dependent* project "foo-test-utils". But maybe I am missing something. Best wishes, Andreas
signature.asc
Description: OpenPGP digital signature
