Sharing Test Fixtures Across Projects

## The problem In a multi-project build you often write helper code for tests — builders, fake implementations, assertion utilities, sample data factories — that you'd like to reuse from *another* module's tests. Putting it in `src/main` ships it to production; putting it in `src/test` makes it invisible to other modules because the `test` source set isn't published as a consumable variant. ## The `java-test-fixtures` plugin Gradle ships a built-in plugin that solves this cleanly: ```kotlin plugins { `java-library` `java-test-fixtures` } ``` Applying it does three things in the **producing** module: 1. Creates a new source set `testFixtures` rooted at `src/testFixtures/java` (and `src/testFixtures/resources`). 2. Wires that source set so it can compile against the module's own `main` output. 3. Registers dependency configurations `testFixturesImplementation`, `testFixturesApi`, `testFixturesRuntimeOnly`, etc., plus **consumable outgoing variants** (`testFixturesApiElements`, `testFixturesRuntimeElements`) that expose a `*-test-fixtures.jar`. The producing module's own `test` source set automatically gets the fixtures on its classpath, so you can use them locally too. ## Consuming the fixtures In another module: ```kotlin dependencies { testImplementation(testFixtures(project(":lib"))) } ``` The `testFixtures(...)` wrapper is the key. Without it, `project(":lib")` resolves the normal API/runtime variant. With it, Gradle attaches a **capability** request for `lib-test-fixtures` and uses attribute matching to select the test-fixtures variant. The consumer's test compile and runtime classpath then includes the fixture classes (and their transitive `testFixturesApi` dependencies). ## How variant selection works Under the hood the fixtures are modelled as a *feature variant* carrying a distinct **capability** (`group:lib-test-fixtures`). Gradle's variant-aware resolution matches the requested capability and the `org.gradle.usage`/`org.gradle.libraryelements` attributes to pick `testFixturesRuntimeElements`. This is why `testFixtures()` works for both `project(...)` (composite/multi-project) and external `module(...)` coordinates that were published with fixtures metadata (Gradle Module Metadata records the extra capability). ## Why not a separate test-utils project? A dedicated `:test-utils` module also works but has costs: it can't easily reach into the producer's `internal`/`main` types, it pollutes the dependency graph for production, and it needs its own publishing. Test fixtures keep helpers next to the code they exercise while keeping them out of the production jar.