Тестовые приспособления и общий код тестов
Используйте плагин java-test-fixtures, чтобы делиться между модулями повторно используемыми помощниками тестов, построителями и имитациями, не включая их в рабочий код.
«Тестовые приспособления и общий код тестов» — бесплатный урок Groovy & Gradle: JVM Automation and Build Engineering на CoddyKit. Это урок 4 из 4. Ты можешь прочитать весь урок бесплатно ниже — а потом практиковать его прямо в браузере с встроенным редактором кода и ИИ-репетитором 24/7. Это часть пути обучения 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
Изучай Groovy с ИИ-репетитором — бесплатно
Пиши и запускай код прямо в браузере, получай мгновенную помощь от ИИ-репетитора 24/7 и продолжи учиться на сайте или в приложении.
- Курсы
- 12
- Уроки
- 48
Часто задаваемые вопросы
Урок «Тестовые приспособления и общий код тестов» бесплатный?
Да — полный текст урока «Тестовые приспособления и общий код тестов» бесплатно доступен здесь в веб-версии. Чтобы практиковать его интерактивно (встроенный редактор кода и ИИ-репетитор 24/7) и разблокировать остальной курс 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/7 отвечает на твои вопросы во время урока.
Нужен ли мне опыт, чтобы начать Groovy & Gradle: JVM Automation and Build Engineering?
Предыдущий опыт не требуется. Groovy & Gradle: JVM Automation and Build Engineering на CoddyKit структурирован для всех уровней — от новичков до продвинутых, поэтому ты можешь начать отсюда или с самого начала и учиться в своем темпе. Это урок 4 из 4.
Сколько времени занимает урок «Тестовые приспособления и общий код тестов»?
Большинство уроков CoddyKit занимают около 5–10 минут. Каждый из них компактный и интерактивный, поэтому ты постоянно делаешь прогресс и продолжаешь с того же места в веб-версии и приложении.
Можно ли писать и запускать код в этом уроке Groovy & Gradle: JVM Automation and Build Engineering?
Да. Каждый урок Groovy & Gradle: JVM Automation and Build Engineering включает встроенный редактор кода, поэтому ты пишешь и запускаешь реальный код прямо в браузере и получаешь моментальную обратную связь от AI — локальная установка не требуется.
Все уроки этого курса
- Модульное и интеграционное тестирование
- Отчёты и фильтрация тестов
- Покрытие кода и статический анализ
- Тестовые приспособления и общий код тестов