Оглавление

Введение
Что такое 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 — управляет всеми аспектами проекта: от зависимостей до собственных задач. В нём описаны основные блоки, которые определяют, как будет собираться и тестироваться ваш код.

Пример 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), которые последовательно превращают ваши скрипты в готовый результат — будь то запуск тестов, сборка артефактов или деплой.
Жизненный цикл состоит из трёх основных этапов:

Таким образом, 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.

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

1. Wrapper читает версию Gradle из файла gradle/wrapper/gradle-wrapper.properties

2. Скачивает нужную версию Gradle (если её нет)

3. Сохраняет её в папку ~/.gradle/wrapper/

4. Использует эту версию для всех последующих сборок

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

.\gradlew wrapper --gradle-version 9.1.0

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

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

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

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

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

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

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

• Maven остается отличным и простым выбором для стандартных Java-проектов, где не требуется сверхгибкость.

Завершение

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

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