Работал ли ты с кастомными Gradle тасками

Что проверяют

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

Как отвечать

Расскажите про задачу, ради которой таск заводили. Типичное для тестировщика: отдельные наборы прогонов по тегам, генерация отчёта, подготовка тестовых данных, запуск против выбранного стенда.

tasks.register<Test>("smoke") {
    useJUnitPlatform { includeTags("smoke") }
    systemProperty("env", project.findProperty("env") ?: "stage")
    outputs.upToDateWhen { false }
    finalizedBy("allureReport")
}

Дальше покажите, что знаете устройство Gradle:

• фазы: инициализация, конфигурация, выполнение. Действие таска живёт в doLast, а не в теле блока;
• регистрация: tasks.register создаёт таск лениво, он не конфигурируется, пока реально не понадобится;
• порядок: dependsOn для обязательного предшественника, finalizedBy для того, что должно случиться после в любом исходе;
• входы и выходы: объявленные inputs и outputs включают инкрементальность и кэш сборки.

Где спотыкаются

Пишут логику прямо в теле блока регистрации. Такой код исполняется на фазе конфигурации при любой команде, даже при выводе списка тасков, и потом непонятно, почему тестовые данные создаются, когда тесты никто не запускал.

Забывают, что тестовый таск умеет считаться актуальным. Если входы не менялись, Gradle помечает его как UP-TO-DATE, прогон молча не идёт, а в отчёте лежит вчерашний результат. Лечится отключением кэширования результата или очисткой перед запуском.

Вешают сборку отчёта через dependsOn или отдельной командой следом. Упавшие тесты обрывают цепочку, и отчёта о падении, ради которого всё делалось, не появляется. Нужна связка finalizedBy плюс осознанное решение, ронять ли сборку.