Всем привет. Меня зовут Ирек, и я в профессиональном IT с 2012 года. Прошел путь от специалиста службы поддержки до разработчика. На данный момент занимаюсь автоматизацией тестирования в компании РТК ИТ. В статье хочу рассказать о полезных для автоматизатора возможностях Gradle. На своих проектах чаще всего используем джавийный стэк. Мы к нему привыкли и уже обросли всем необходимым для старта проекта автоматизации тестирования любой сложности. Gradle был с самого начала перехода на Java и полностью нас устраивает: мощный, гибкий и краткий. Действительно у Gradle отличная документация и там можно найти абсолютно все, что вам нужно, но осилить целиком возможно будет трудновато, так как полная документация на момент написания статьи занимает 1357 страниц. Можно поискать решения на sof или baeldung, но для этого нужно знать, что именно вы ищете. Поэтому было решено собрать все в одной статье, а заодно обсудить, что действительно полезно, что не имеет смысла и, может, дополнить список примерами из комментариев. При создании нового проекта build.gradle выглядит следующим образом. Теперь давайте попробуем немного облегчить себе жизнь накрутив чуть больше различных опций для запуска тестов. Если запустить прогон тестов командой то увидим следующее сообщение Как мы видим тест под номером 3 упал, а что произошло с остальными можно догадаться только из общего вывода. Добавляем следующие строчки в блок test{} в build.gradle и смотрим, как поменялся вывод Теперь у нас есть вывод о том, какие тесты и в каком порядке выполнялись. Это очень удобно, когда мы смотрим все это в выводах пайплайна. Добавим плагин, который позволяет перезапускать упавшие тесты. Далее указываем количество попыток перезапуска тестов Запустим тесты и видим следующее (часть вывода сокращу, для облегчения чтения) Видим, что test3 упал, потом прошли оставшиеся тесты и далее было 3 попытки перезапустить test3. Если хотя бы одна из них завершилась бы удачно, то тест бы считался успешным. Это не все возможности плагина. Так же можно задавать максимальное количество упавших тестов, после которых прогон будет остановлен. Можно задавать условия запуска через пайплайн. Почитать подробнее можно тут. Добавим в конец файла build.gradle Отлично, теперь у нас есть 2 новые задачи по тестированию, которые умеет запускать Gradle. Для примера методу test3 добавим аннотации Tag("smoke") и Tag("regress"). А методу test1 только Tag("regress"). Запустим И видим, что выполнился только test3 Теперь запустим регресс Очень удобная штука. Еще можно передавать значения необходимых тэгов прямо из CI, чтобы например запустить все тесты которые например относятся к версии 2.1.0 и не придется хардкодить номер версии вашего приложения. Выше был описан способ, когда мы создаем отдельную таску и настраиваем в ней фильтрацию. Но не всегда это бывает удобно и необходимо. Можно добиться того же результата используя параметры запуска в командной строке. Например Выполнит все тесты, описанные в классе SomeTestClass. Можно задать несколько параметров для запуска Подробно это описано в документации. Фильтрация по тэгам через командную строку не реализована, но можно создать небольшую таску следующего вида Теперь можно запускать тесты с фильтрами по тэгам.Например -P это ключ для обозначения параметра. Подробнее тут. Представьте, что у нас есть некоторое количество тестов, которые помечены аннотацией Disabled и мы хотим проверить, что они все еще поломаны. Комментировать или удалять аннотации в коде будет очень утомительно. Но мы можем задать в системных свойствах значение, которое отключит аннотацию Disabled. Можно создать отдельную задачу, чтобы время от времени запускать и проверять отключенные тесты. Подробнее, как это работает, описано здесь. С помощью системных свойств можно также тонко настраивать работу любых других плагинов. Например, мы  не хотим, чтобы определенная группа тестов гонялась на продуктовом стенде. Теперь, если мы запустим эту таску на всех стендах, то она отработает везде, кроме продакшена. Конечно, это только малая часть возможностей. Есть еще множество плагинов, которые могут помочь побороть сложности на вашем проекте. Также я не стал затрагивать тему распараллеливания запуска тестов. На это есть две причины. Во-первых, об этом уже написано везде, где только можно. Во-вторых, если уж и освещать эту тему, то она требует отдельной статьи. Если кто-то хочет разобраться с Gradle детальнее, то есть хорошая серия статей на эту тему. На этом все. Делитесь своими рецептами в комментариях.  qa