Принудительный запуск тестов в Gradle без пересборки проекта

Быстрый ответ

Чтобы принудительно запустить тесты Gradle, воспользуйтесь командой --rerun-tasks:

./gradlew test --rerun-tasks

Также можно перенастроить тестовую задачу в build.gradle, игнорируя статус UP-TO-DATE:

test {
    outputs.upToDateWhen { false }
}

Или воспользоваться задачей cleanTest, чтобы удалить результаты предыдущих тестов без модификации build.gradle:

./gradlew cleanTest test

В этом случае тесты будут перезапущены без необходимости полной перекомпиляции проекта.

Конфигурация Gradle

Настройка непрерывного запуска тестов

Для активации тестирования при каждом запуске, независимо от внесенных изменений (например, в рамках CI/CD процессов), отключите проверку на статус UP-TO-DATE в задаче test:

tasks.withType(Test) {
    outputs.upToDateWhen { false }
}

Подробнее об этом расскажет наш спикер на видео

Сочетание производительности и точности

Для обеспечения эффективности тестов без ущерба точности результатов, используйте флаг --no-build-cache:

./gradlew test --no-build-cache

Это позволит выполнить тесты, учитывая результаты предыдущих сборок, где это возможно.

Реакция на изменение входных данных

Запуск тестов может быть вызван не только изменением кода, но и изменением входных данных задачи, таких как конфигурации, необходимые для тестов.

Механизм кеширования Gradle

Важно понимать работу механизма кеширования Gradle для оптимизации сборки. Умение использовать --no-build-cache позволяет запускать тесты в особых ситуациях, даже если входные данные не менялись.

Визуализация

Вот как принудительно запустить тесты Gradle, если все они помечены как UP-TO-DATE:

Статус кеша Gradle Test: 🟢 UP-TO-DATE

КОМАНДА:

./gradlew test --rerun-tasks

РЕЗУЛЬТАТ:

🔄 Принудительный перезапуск тестов! Кеширование игнорируется...

Теперь тесты проведены заново, статус UP-TO-DATE проигнорирован. Пора сделать перерыв и выпить кофе! ☕️💻

Подготовка к перезапуску тестов

При наличии зависимых от окружения нестабильных тестов, cleanTest позволяет инициировать их запуск без влияния на другие задачи:

./gradlew cleanTest test -i

Использование -i помогает получить более детальную информацию при анализе возникающих проблем.

Управление зависимостями на профессиональном уровне

Учтите зависимости тестов от других задач, таких как, processResources, и совмещайте запуск задач с командой clean:

./gradlew cleanTest cleanProcessResources test

Так вы обеспечите готовность к запуску как самих тестов, так и их зависимостей.

Избегаем потенциальные ошибки

Помните о некоторых распространенных ошибках:

• Если забыть указать флаг --rerun-tasks, тесты могут не отразить последние изменения.
• Использование --no-rebuild может помешать выполнению необходимых компиляций.
• Важно понимать разницу между общей командой очистки clean и специфической, например cleanTest.

Полезные материалы

1. Тестирование в Java и JVM-проектах — подробности работы механизма проверки статуса UP-TO-DATE в Gradle.
2. Интерфейс командной строки — подробности принудительного выполнения задач в Gradle с использованием --rerun-tasks.
3. Test – Gradle DSL Версия 8.6 — настройка тестовых задач с помощью DSL Gradle.
4. Руководство по пользователю Gradle — всё об оптимизации сборок с помощью кеширования.
5. Входные данные (Gradle API 8.6) — использование аннотаций @Input для управления входными данными задач.
6. Жизненный цикл сборки — обзор основных фаз жизненного цикла сборки в Gradle.