You need to remove the compile time dependency from foo-test-utils to foo. Obviously you will have a runtime dependency, but that's ok. One simple way is to use reflection in foo-test-utils when instantiating the Foo object. Not pretty, but a simple solution. There are more elegant solutions but they could be overkill in this case.
/Anders On Fri, Mar 13, 2020 at 10:29 AM Andreas Sewe < s...@st.informatik.tu-darmstadt.de> wrote: > 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 > >
