What are test fixtures in Gradle, and how do you enable them in a project?
answer
- java-test-fixtures plugin
- src/testFixtures/java source set
- testFixturesApi vs testFixturesImplementation
- separate -test-fixtures jar / variant
- own test gets fixtures automatically
basics
~10 sTest fixtures are reusable test helper code (builders, fakes, sample data) shared across test classes and other projects. Enable them by applying the java-test-fixtures plugin, then put code in src/testFixtures/java.
solid answer
~40 sTest fixtures are shared test-support code — object mothers, fakes, assertion helpers, sample data — that you don't want to duplicate across test classes or modules. Gradle's built-in `java-test-fixtures` plugin formalizes this: apply it and Gradle creates a new `testFixtures` source set at `src/testFixtures/java` plus dedicated `testFixturesApi`/`testFixturesImplementation` configurations. The project's own `test` source set automatically gets the fixtures on its compile/runtime classpath, so tests can use them with no extra wiring. The fixtures are also packaged into a separate artifact (a `-test-fixtures` classifier jar) with its own variant, so other projects can consume them via `testFixtures(project(':lib'))`. It depends on `java` or `java-library`, so apply it alongside one of those.
code
kotlin · 11 linesplugins {
`java-library`
`java-test-fixtures`
}
dependencies {
// visible to consumers of the fixtures
testFixturesApi("org.assertj:assertj-core:3.25.3")
// internal to the fixtures only
testFixturesImplementation("com.github.javafaker:javafaker:1.0.2")
}go deeper
Know that java-test-fixtures exists, that fixture code lives in src/testFixtures/java, and that it's for sharing test helpers.
Explain the auto-created configurations and source set, the api/implementation split, and that the module's own tests use fixtures for free.
Discuss the separate variant/capability, the published -test-fixtures jar, and why explicit opt-in keeps test code out of runtime.
Frame fixtures as a way to standardize test-support code across a multi-module codebase and weigh them against a dedicated shared test module.
## What problem test fixtures solve In real projects you accumulate test-support code that isn't a test itself: object builders ("object mothers"), in-memory fakes, custom assertions, sample JSON, random data generators. If this lives in `src/test`, only that module's tests can use it. Copy-pasting it into downstream modules is the usual hack. Gradle's **`java-test-fixtures`** plugin gives this code a first-class home. ## What the plugin does Applying it (it requires `java` or `java-library`): - Creates a new **source set** `testFixtures` rooted at `src/testFixtures/java` (and `resources`). - Creates configurations **`testFixturesApi`** and **`testFixturesImplementation`** (mirroring the `api`/`implementation` split — `testFixturesApi` dependencies leak onto the consumer's compile classpath, `testFixturesImplementation` stay internal). - Wires the project's own `test` source set to compile and run against the fixtures automatically. - Produces a separate **artifact/variant** (jar with the `test-fixtures` classifier) and an outgoing **`testFixturesApiElements`/`testFixturesRuntimeElements`** configuration so other modules can resolve it. ## Consuming fixtures From another project's test code: ```kotlin dependencies { testImplementation(testFixtures(project(":lib"))) } ``` The `testFixtures(...)` helper selects the fixtures variant rather than the main variant. You can also consume published fixtures from an external module with `testFixtures("com.example:lib:1.0")`, provided the producer published Gradle Module Metadata describing that variant. ## Why a separate variant, not just another jar Gradle uses **variant-aware resolution** — each artifact carries attributes describing its capabilities. The fixtures jar advertises a distinct *capability* (`group:name-test-fixtures`), so consumers must explicitly opt in with `testFixtures(...)`; they won't get fixtures by accident on the production classpath. This keeps test-only helpers out of your runtime distribution.
- Where does fixture source code live, and what is the configuration to add a third-party library only to the fixtures?Code goes in `src/testFixtures/java`. Use `testFixturesImplementation` for libraries internal to the fixtures, or `testFixturesApi` if the dependency's types appear in the fixtures' public API and should reach consumers.
- Does the producing module's own tests need extra wiring to use the fixtures?No. The plugin automatically puts the `testFixtures` output on the `test` source set's compile and runtime classpath, so the module's own tests use them with zero extra configuration.
saying these in an interview costs you the question
- Claiming you must manually add the fixtures source set or configurations — the plugin creates them.
- Saying fixtures end up on the production/runtime classpath of consumers automatically (they require explicit opt-in via testFixtures(...)).