Оглавление

Введение
Что такое Gradle?
Краткая история создания
Что содержит build.gradle
Жизненный цикл сборки
Команды
Gradle vs Maven: что выбрать для автотестов
Завершение

Введение

Если вы автоматизируете на Java или Kotlin, вы не могли не слышать о Gradle. Одни его хвалят за скорость и гибкость, другие ругают за сложность конфигурации. Что же это за инструмент и почему всё больше проектов переходят на него с Maven? В этой статье мы разберем Gradle, чтобы вы могли уверенно использовать его в своих проектах для автоматизации тестирования, а так же спокойно ответить на вопросы на собеседовании.

Что такое Gradle?

Gradle — это система автоматизации сборки, которая сочетает в себе мощь и гибкость Ant с удобством соглашений по умолчанию из Maven.

Если говорить проще, Gradle — это умный помощник, который:

Скачивает все библиотеки, которые вы подключаете в проект.
Компилирует ваш Java-код.
Запускает ваши автотесты.
Создает отчеты и упаковывает проект.

Ключевое преимущество, которое оценят QA-инженеры — Gradle использует язык программирования (Groovy или Kotlin) для файлов конфигурации, а не статический XML, как Maven. Это дает широкие возможности для создания сложных и гибких сценариев сборки, что особенно полезно в больших проектах с автотестами.

Краткая история создания

2007 год: Рождение Gradle. Проект основал Ханс Доктер (Hans Dockter) как ответ на ограничения Ant и Maven.
Основная идея: "Соглашения поверх конфигурации" (как в Maven), но с возможностью легко эти соглашения ломать и настраивать под себя с помощью настоящего языка программирования.
2013 год: Gradle стал стандартом для сборки Android-приложений, что резко подняло его популярность.
Современность: Сегодня Gradle — это выбор по умолчанию для Kotlin, активно используется в крупных Java-проектах и продолжает отбирать долю у Maven благодаря своей производительности.

Что содержит build.gradle

Главный конфигурационный файл Gradle — build.gradle — управляет всеми аспектами проекта: от зависимостей до собственных задач. В нём описаны основные блоки, которые определяют, как будет собираться и тестироваться ваш код.

Блок	Что содержит	Для чего нужен
plugins	Подключаемые плагины	Добавляют необходимую функциональность: сборка Java-кода, запуск тестов, генерация отчётов, упаковка приложения и т.д.
repositories	Источники зависимостей	Указывают, откуда Gradle будет скачивать библиотеки и плагины.
dependencies	Список библиотек и фреймворков	Автоматически загружает и подключает нужные JAR-файлы для тестов и основной логики проекта.
group	Пространство имён проекта	Используется для идентификации проекта при публикации или подключении как зависимости.
version	Текущая версия проекта	Позволяет отслеживать изменения и управлять версиями артефактов при сборке.
sourceCompatibility	Версия Java, с которой компилируется проект	Обеспечивает совместимость исходного кода с нужной версией JVM.
tasks	Набор встроенных и пользовательских задач	Управляют процессом сборки, тестирования, очистки и публикации проекта.

Пример build.gradle

plugins {
    id 'java'
}

group = 'org.example'
version = '1.0-SNAPSHOT'

sourceCompatibility = '17'

dependencies {
    // JUnit 5
    testImplementation platform(libs.junit.bom)
    testImplementation libs.junit.jupiter
    testRuntimeOnly libs.junit.platform.launcher
    
    // Библиотеки для автотестов
    testImplementation libs.selenium.java
    testImplementation libs.webdrivermanager
    testImplementation libs.assertj.core
}

test {
    useJUnitPlatform()
    
    testLogging {
        events "passed", "skipped", "failed"
        showStandardStreams = true
    }
}

gradle/libs.versions.toml - управление версионностью

[versions]
# Здесь храним все версии в одном месте
junit = "5.14.0"
selenium = "4.38.0"
webdrivermanager = "6.3.2"
assertj = "3.27.3"

[libraries]
# JUnit
junit-bom = { module = "org.junit:junit-bom", version.ref = "junit" }
junit-jupiter = { module = "org.junit.jupiter:junit-jupiter", version.ref = "junit" }
junit-platform-launcher = { module = "org.junit.platform:junit-platform-launcher", version.ref = "junit" }

# Библиотеки для автотестов
selenium-java = { module = "org.seleniumhq.selenium:selenium-java", version.ref = "selenium" }
webdrivermanager = { module = "io.github.bonigarcia:webdrivermanager", version.ref = "webdrivermanager" }
assertj-core = { module = "org.assertj:assertj-core", version.ref = "assertj" }

[bundles]
# Группы библиотек (можно подключать одной строкой)
test-dependencies = ["junit-jupiter", "selenium-java", "webdrivermanager", "assertj-core"]

settings.gradle - центральное управление репозиториями

// Настройки плагинов - откуда качать сами плагины Gradle
pluginManagement {
    repositories {
        gradlePluginPortal()  // Главный магазин плагинов Gradle
        mavenCentral()        // Резервный источник
    }
}

// Центральное управление репозиториями для зависимостей
dependencyResolutionManagement {
    // Режим работы: запрещаем репозитории в build.gradle (чтобы все было тут)
    repositoriesMode = RepositoriesMode.FAIL_ON_PROJECT_REPOS
    
    repositories {
        mavenCentral()  // Все библиотеки качаем отсюда
    }
}

// Название нашего проекта
rootProject.name = 'autotests-project'

Жизненный цикл сборки

Gradle выполняет сборку в несколько фаз (phases), которые последовательно превращают ваши скрипты в готовый результат — будь то запуск тестов, сборка артефактов или деплой.
Жизненный цикл состоит из трёх основных этапов:

Этап	Название	Что происходит
Фаза 1. Инициализация (Initialization)	Определяется структура сборки	Gradle обнаруживает файл `settings.gradle` или `settings.gradle.kts`, создаёт объект Settings, анализирует, какие проекты входят в сборку (включая мультипроектные). Для каждого проекта создаётся экземпляр Project.
Фаза 2. Настройка (Configuration)	Анализируются build-скрипты	Gradle последовательно выполняет конфигурационные блоки каждого проекта, читает файлы `build.gradle`, формирует граф задач (Task Graph) — список действий, которые нужно выполнить.
Фаза 3. Выполнение (Execution)	Выполняются задачи	Gradle запускает только те задачи, которые были запрошены пользователем (например, `build`, `test`, `clean`), соблюдая порядок зависимостей.

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

📘 Подробнее о жизненном цикле читайте в официальной документации Gradle — Build Lifecycle

Важно: В отличие от Maven, Gradle выполняет только те задачи, которые необходимы. Если код не менялся, Gradle не будет перекомпилировать его повторно, что и дает огромный прирост скорости.

Команды

Gradle Wrapper

Gradle Wrapper — это рекомендуемый способ работы с Gradle, который гарантирует, что все участники проекта используют одинаковую версию Gradle для сборки. Wrapper автоматически скачивает и использует правильную версию Gradle, указанную в проекте.

Основные команды:

.\gradlew — использование Gradle Wrapper на Windows
./gradlew — использование Gradle Wrapper на Linux/macOS

Альтернатива: Если у вас установлен Gradle локально и добавлен в системные переменные PATH, вы можете использовать команду gradle вместо .\gradlew или ./gradlew.

Что происходит при первом запуске:

Wrapper читает версию Gradle из файла gradle/wrapper/gradle-wrapper.properties
Скачивает нужную версию Gradle (если её нет)
Сохраняет её в папку ~/.gradle/wrapper/
Использует эту версию для всех последующих сборок

Обновление Wrapper в существующем проекте:

.\gradlew wrapper --gradle-version 9.1.0

Что создается:

Test/
├── gradlew.bat        # Главный скрипт для Windows
├── gradle/
│   └── wrapper/
│       ├── gradle-wrapper.jar      #  Jar-файл
│       └── gradle-wrapper.properties  # Здесь прописана версия Gradle
└── build.gradle       # Ваш обычный файл настройки

Команда	Что делает
`.\gradlew clean test allureReport` `.\gradlew allureServe`	Комбо (2 команды): очистить проект, запустить тесты, сгенерировать Allure-отчёт и сразу открыть его в браузере
`.\gradlew test --tests "Smoke"`	Запустить только Smoke-тесты по шаблону имени класса или метода
`.\gradlew clean build --refresh-dependencies`	Очищает проект, обновляет зависимости и пересобирает проект (полезно при проблемах с кэшем)
`.\gradlew build --scan`	Создать Build Scan — интерактивный отчёт о сборке с графиками и логами
`.\gradlew --stop`	Завершить все активные демоны Gradle (если процесс завис или не освобождает ресурсы)
`.\gradlew test --tests "*LoginTest"`	Запустить тесты из классов, чьи имена содержат 'LoginTest'

Gradle vs Maven: что выбрать для автотестов?

Давайте сравним по ключевым для QA критериям:

Вот компактная таблица с основными критериями сравнения:

Критерий	Gradle	Maven
Язык конфигурации	Groovy / Kotlin (код)	XML (декларативный)
Производительность	Быстрее (инкрементальная сборка)	Медленнее (сборка с нуля)
Гибкость	Высокая (можно писать свою логику)	Ограниченная (жесткие соглашения)
Управление зависимостями	Version Catalogs, более умное разрешение	Центральный pom.xml, простой подход

Итог сравнения для QA:

Выбирайте Gradle, если вы начинаете новый проект, особенно на Kotlin, или если вам нужна максимальная скорость и гибкость для сложных сценариев запуска тестов.
Maven остается отличным и простым выбором для стандартных Java-проектов, где не требуется сверхгибкость.

Завершение

Gradle — это мощный и современный инструмент, который стоит изучить каждому QA-автоматизатору. Он может показаться сложнее Maven на первых порах, но его скорость, гибкость и растущая популярность с лихвой окупают первоначальные усилия.

Удачи в изучении и пишите стабильные автотесты

Gradle для QA-инженера