Groovy & Gradle: JVM Automation and Build Engineering · Lektion

Test Fixtures und gemeinsam genutzter Testcode

Verwenden Sie das Plugin java-test-fixtures, um wiederverwendbare Testhelfer, Builder und Fakes modulübergreifend zu teilen, ohne sie in den Produktionscode gelangen zu lassen.

Lektion 4 von 413 Schritte

Test Fixtures und gemeinsam genutzter Testcode ist eine kostenlose Groovy & Gradle: JVM Automation and Build Engineering-Lektion auf CoddyKit. Dies ist Lektion 4 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Groovy & Gradle: JVM Automation and Build Engineering-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Groovy & Gradle: JVM Automation and Build Engineering-Kurs umfasst insgesamt 4 Lektionen.

Teile dieser Lektion wurden noch nicht übersetzt und werden auf Englisch angezeigt.

The Shared Test Code Problem

Multiple modules often need the same test helpers (builders, fakes, fixtures). Copy-pasting them is brittle, and putting them in main code ships test-only classes to production.

Enter Test Fixtures

Gradle ships the java-test-fixtures plugin, which adds a dedicated testFixtures source set whose code can be consumed by other modules tests.

plugins {
    id("java-library")
    id("java-test-fixtures")
}

Source Set Layout

The plugin creates src/testFixtures/java. Classes there are compiled separately and packaged into a fixtures artifact.

  • src/main production
  • src/test tests
  • src/testFixtures shared test helpers

Writing a Fixture

Place reusable builders in the fixtures source set. They can depend on the main classes of the module.

public class UserBuilder {
    public static User aUser() {
        return new User("test", 42);
    }
}

Using Fixtures Inside the Module

The modules own tests automatically see its fixtures, no extra configuration needed.

@Test
void usesFixture() {
    User u = UserBuilder.aUser();
    assertEquals(42, u.getId());
}

Consuming Fixtures Across Modules

Another module declares a dependency on the fixtures using the testFixtures() helper.

dependencies {
    testImplementation(testFixtures(project(":core")))
}

Fixture Dependencies

Fixtures can declare their own dependencies with the testFixturesImplementation configuration, kept separate from production deps.

dependencies {
    testFixturesImplementation("org.assertj:assertj-core:3.25.0")
}

Why Not Just Use main?

Putting test helpers in main leaks them into the published JAR and the production classpath, increasing size and risk. Fixtures keep them isolated.

Publishing Fixtures

The fixtures artifact can be published alongside the main JAR, so downstream consumers in other repositories reuse them too.

gradle publish

Comparison with a Separate Module

You could create a standalone test-helpers module, but fixtures avoid an extra module, keep helpers next to the code they support, and use a clear naming convention.

Best Practices

Keep fixtures focused:

  • Only put genuinely reusable helpers here
  • Avoid leaking fixtures into main accidentally
  • Name builders/fakes clearly

Quick Check

Test your understanding of test fixtures.

Recap

You learned test fixtures:

  • Apply java-test-fixtures
  • Put shared helpers in src/testFixtures
  • Consume with testFixtures(project(...))
  • Keeps test-only code out of production artifacts
Kostenlos starten

Lerne Groovy mit einem KI-Tutor — kostenlos

Schreibe und führe echten Code in deinem Browser aus, bekomme sofortige Hilfe von einem 24/7 KI-Tutor und setze dein Lernen im Web oder in der App fort.

Kurse
12
Lektionen
48

Häufig gestellte Fragen

Ist die Lektion „Test Fixtures und gemeinsam genutzter Testcode“ kostenlos?

Ja — der vollständige Text von „Test Fixtures und gemeinsam genutzter Testcode“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Groovy & Gradle: JVM Automation and Build Engineering-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Groovy & Gradle: JVM Automation and Build Engineering-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Test Fixtures und gemeinsam genutzter Testcode“?

Verwenden Sie das Plugin java-test-fixtures, um wiederverwendbare Testhelfer, Builder und Fakes modulübergreifend zu teilen, ohne sie in den Produktionscode gelangen zu lassen. Du übst Groovy & Gradle: JVM Automation and Build Engineering mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um Groovy & Gradle: JVM Automation and Build Engineering zu starten?

Keine Vorkenntnisse erforderlich. Groovy & Gradle: JVM Automation and Build Engineering auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 4 von 4.

Wie lange dauert die Lektion „Test Fixtures und gemeinsam genutzter Testcode“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser Groovy & Gradle: JVM Automation and Build Engineering-Lektion Code schreiben und ausführen?

Ja. Jede Groovy & Gradle: JVM Automation and Build Engineering-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

  1. Unit- und Integrationstests
  2. Testberichte und Filterung
  3. Codeabdeckung und statische Analyse
  4. Test Fixtures und gemeinsam genutzter Testcode
← Zurück zu Groovy & Gradle: JVM Automation and Build Engineering