How do people share test utilities between modules? - Create an extra module and place test utility ...

# test

[spand]

How do people share test utilities between modules?
• Create an extra module and place test utility in source set. Seems quite verbose.
• Place utility in test source set and depend directly on the that ie. testImplementation project(':hltv-dataaccess').sourceSets.test.output
• Crazy stuff like: https://vkuzel.com/shared-test-sources-in-gradle-multi-module-project
• https://docs.gradle.org/5.6/userguide/java_testing.html#sec:java_test_fixtures Anyone used this with Kotlin?
• Other ?
I do not find any of the above options very appealing. Has anyone found a good solution ? (and why is it good)

[bbaldino]

We've got a multi-repo project and do the first option (a separate artifact which can be added as a test dependency). It's not great but is basically required since we've got artifacts across multiple repos. This only for test helpers which make sense to be re-used in a lot of places. For test code that only a single piece uses, we just put them in a helpers (or something) package in the test dir.

[robstoll]

I put them in a separate artifact as well and so far I did not have any problems with this approach. What are your problems?

[spand]

The problem is that we have 30 modules already and doubling that just to get test utility in its own module.. well my team would drag me into the streets 🙂

[spand]

We decided to begin trialling with the java_test_fixtures plugin.

[robstoll]

Why doubling? You have an own test artifact per module? And what do you share exactly? I have a lot modules as well sometimes but usually only one additional test artifact with test helpers, assertion functions etc.

[spand]

I must have misunderstood you then.
1. Where is the shared code location ? (src/test ?)
2. How do you put that in its own artifact and how do you depend on it?

[bbaldino]

Can't answer for Robert, but we have a single test artifact (e.g. "test-helpers") which has all the common code we use for tests. This includes things like a stdout logger implementation, a fake version of Clock, a fake version of ExecutorService, etc. Stuff that we find useful in tests. Then the code (multiple artifacts across multiple repos) depends on this common test library (as a test dependency) to use the code there.

[robstoll]

I do exactly the same

[Davide Giuseppe Farella]

How do you deal with dependency circle?
I have module X with DispachersProvider and I wanna share TestDispatchersProvider and at the same time I wanna use it for X tests

[bbaldino]

If the type is specific to module, I just write the test impl in the tests for that module. I haven't had a use case where I need a concrete test impl (i.e. a mock won't suffice) for a type in module A outside module A

[Davide Giuseppe Farella]

Well, I just gave an example 😅 DispatchersProvider and a base test interface I was planning for deal with Coroutines

[bbaldino]

I don't know what DispachersProvider does, but if it's a helper type which doesn't depend on other things in the project, we'd have that in a utils or common code repo which doesn't rely on any of our other stuff.

[bbaldino]

So DispachersProvider goes in the utils repo and TestDispatchersProvider goes in the test utils repo

[Davide Giuseppe Farella]

Yes, that's what I did at the end, but I have some test doubles ( I.e. Movies, actors, genres ) and I have to keep them in the codebase in that case