skip to content

A teammate added testImplementation(testFixtures(project(':lib'))) but the consumer's tests can't find the fixture classes at compile time. How do you diagnose and fix it?

level: middleimportance: should knowfreq 24%

answer

  1. is java-test-fixtures applied on producer?
  2. classes under src/testFixtures/java?
  3. leaked type needs testFixturesApi not Implementation
  4. dependencyInsight on testCompileClasspath
  5. wrapper present + on testImplementation; GMM for external

basics

~10 s

Check that :lib actually applies java-test-fixtures, that the classes live in src/testFixtures/java, and that any types the consumer references are declared testFixturesApi (not testFixturesImplementation). Then use dependencyInsight to confirm the right variant resolved.

solid answer

~50 s

Work down the chain. First, does the producer apply the `java-test-fixtures` plugin and do the fixtures actually compile into `src/testFixtures/java`? If the plugin is missing, `testFixtures(project(":lib"))` resolves nothing useful. Second, **compile-time visibility**: a consumer compiling against a fixture's *public* signature needs the transitive types on its compile classpath; if a referenced type comes from a `testFixturesImplementation` dependency it's hidden — move it to `testFixturesApi`. Third, confirm variant selection with `./gradlew :app:dependencyInsight --configuration testCompileClasspath --dependency lib` — you should see `testFixturesApiElements` selected with the `lib-test-fixtures` capability. Fourth, check the consumer used the `testFixtures()` wrapper (not bare `project(":lib")`) and put it on `testImplementation`, not `implementation`. For an external module, verify it was published with Gradle Module Metadata (POM-only publishing loses the fixtures variant). Finally, an IDE that hasn't re-synced can show false 'unresolved' errors — re-import the Gradle project.

code

bash · 7 lines
bash
# Did the fixtures even compile on the producer?
./gradlew :lib:compileTestFixturesJava

# Which variant/capability did the consumer resolve?
./gradlew :app:dependencyInsight \
  --configuration testCompileClasspath \
  --dependency lib

go deeper

for a junior

Check the obvious: plugin applied, wrapper used, dependency on testImplementation.

for a middle

Run through the full checklist including the api/implementation leakage cause and dependencyInsight.

for a senior

Reason about variant selection output and external GMM publishing edge cases.

for a principal

Encode the checklist as a team runbook; standardize fixtures conventions to prevent the recurring mistakes.

## A systematic checklist When `testFixtures(project(":lib"))` 'doesn't work', the failure is almost always one of a handful of causes. Diagnose top-down. ### 1. Producer plugin & layout ```kotlin // lib/build.gradle.kts plugins { `java-library`; `java-test-fixtures` } ``` No plugin ⇒ no `testFixtures` source set and no consumable fixtures variant. Confirm the helper classes are under `src/testFixtures/java/...` (the plugin won't pick up `src/test`). Run `./gradlew :lib:compileTestFixturesJava` to prove they compile. ### 2. Compile-time visibility (the most common real bug) If the consumer code references a type that appears in a fixture's public signature, that type must be on the consumer's **compile** classpath. Types coming from a `testFixturesImplementation` dependency are hidden. Fix by promoting to `testFixturesApi`: ```kotlin dependencies { // was: testFixturesImplementation(...) -> consumer couldn't see the leaked type testFixturesApi("org.junit.jupiter:junit-jupiter-api:5.10.2") } ``` ### 3. Confirm variant selection ```bash ./gradlew :app:dependencyInsight \ --configuration testCompileClasspath \ --dependency lib ``` A correct result shows the `testFixturesApiElements` variant selected and the `:lib-test-fixtures` capability. If you instead see the normal `apiElements`, the `testFixtures()` wrapper was forgotten. ### 4. Consumer declaration mistakes - Bare `testImplementation(project(":lib"))` (missing wrapper) ⇒ wrong variant. - Declared on `implementation`/`compileOnly` instead of `testImplementation` ⇒ not on the test classpath. ### 5. External modules & metadata If `:lib` is an external dependency, it must have been published with **Gradle Module Metadata**; a POM-only publication drops the fixtures variant/capability and `testFixtures("group:lib:ver")` will fail to resolve. ### 6. IDE noise Gradle resolves correctly on the CLI but the IDE shows red? Re-sync/re-import the Gradle project so the IDE picks up the fixtures source set on the test module's classpath. ## Quick triage order plugin applied → classes in right folder → needed types on `testFixturesApi` → `dependencyInsight` shows fixtures variant → wrapper + correct configuration → (external) GMM published → IDE re-sync.

  • Runtime works but compile fails for one specific type the fixture exposes — most likely cause?
    That type's dependency is on `testFixturesImplementation` (runtime-only for consumers); promote it to `testFixturesApi`.
  • The dependency is an external library and resolution fails entirely — what to check?
    Whether it was published with Gradle Module Metadata; a POM-only publication drops the fixtures variant and capability.
  • CLI build is green but the IDE flags unresolved fixtures — fix?
    Re-import/re-sync the Gradle project so the IDE adds the fixtures source set to the test classpath.

saying these in an interview costs you the question

  • Jumping to 'it's a Gradle bug' before checking the plugin, source-set folder, and api/implementation leakage.
  • Trusting IDE red squiggles over an actual `./gradlew` build result.

context

resolving links…