テストフィクスチャと共有テストコード
java-test-fixturesプラグインを使い、再利用可能なテストヘルパー、ビルダー、フェイクをモジュール間で共有します。これらが本番コードへ漏れ出すこともありません。
「テストフィクスチャと共有テストコード」はCoddyKit上の無料Groovy & Gradle: JVM Automation and Build Engineeringレッスンです。 これはレッスン4/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。 これはGroovy & Gradle: JVM Automation and Build Engineering学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Groovy & Gradle: JVM Automation and Build Engineeringコースには全4レッスンが含まれています。
このレッスンの一部はまだ翻訳されておらず、英語で表示されています。
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/mainproductionsrc/testtestssrc/testFixturesshared 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 publishComparison 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
よくある質問
「テストフィクスチャと共有テストコード」レッスンは無料ですか?
はい。「テストフィクスチャと共有テストコード」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し(組み込みコードエディタと24時間対応のAIチューター)、Groovy & Gradle: JVM Automation and Build Engineeringコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Groovy & Gradle: JVM Automation and Build Engineeringコースには全4レッスンが含まれています。
「テストフィクスチャと共有テストコード」で何を学びますか?
java-test-fixturesプラグインを使い、再利用可能なテストヘルパー、ビルダー、フェイクをモジュール間で共有します。これらが本番コードへ漏れ出すこともありません。 ブラウザで直接実行するハンズオンコードでGroovy & Gradle: JVM Automation and Build Engineeringを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。
Groovy & Gradle: JVM Automation and Build Engineeringを始めるのに経験は必要ですか?
事前経験は必要ありません。CoddyKitのGroovy & Gradle: JVM Automation and Build Engineeringは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン4/4です。
「テストフィクスチャと共有テストコード」レッスンにはどのくらい時間がかかりますか?
ほとんどのCoddyKitレッスンは約5~10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。
このGroovy & Gradle: JVM Automation and Build Engineeringレッスンでコードを書いて実行できますか?
はい。すべてのGroovy & Gradle: JVM Automation and Build Engineeringレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。
このコースのすべてのレッスン
- 単体テストと統合テスト
- テストレポートとフィルタリング
- コードカバレッジと静的解析
- テストフィクスチャと共有テストコード