ชุดทดสอบและโค้ดทดสอบร่วม

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.

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

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

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

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

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

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

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

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

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.

Keep fixtures focused:

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

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