Какими пользуешься системами сборки

Основные системы сборки в арсенале QA Automation Engineer

В моей практике QA Automation Engineer я активно использую несколько систем сборки, выбор которых зависит от стека технологий проекта, требований к производительности и специфики CI/CD пайплайна.

Maven – стандарт для Java-проектов

Для проектов на Java (особенно с использованием Selenium, TestNG, JUnit, Rest-Assured) Maven является основным инструментом. Его ключевые преимущества:

• Структура проекта – строгое следование конвенциям упрощает навигацию (src/test/java, pom.xml).
• Управление зависимостями – централизованное в pom.xml с автоматическим разрешением из репозиториев (Maven Central).
• Жизненный цикл и плагины – предопределенные фазы (clean, compile, test, package) и обширная экосистема плагинов (например, maven-surefire-plugin для запуска тестов, maven-failsafe-plugin для интеграционных).

Пример базового pom.xml для автотестов:

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.example</groupId>
    <artifactId>qa-automation</artifactId>
    <version>1.0</version>

    <properties>
        <maven.compiler.source>11</maven.compiler.source>
        <maven.compiler.target>11</maven.compiler.target>
        <selenium.version>4.14.0</selenium.version>
    </properties>

    <dependencies>
        <dependency>
            <groupId>org.seleniumhq.selenium</groupId>
            <artifactId>selenium-java</artifactId>
            <version>${selenium.version}</version>
        </dependency>
        <dependency>
            <groupId>org.testng</groupId>
            <artifactId>testng</artifactId>
            <version>7.8.0</version>
            <scope>test</scope>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-plugin</artifactId>
                <version>3.1.2</version>
                <configuration>
                    <suiteXmlFiles>
                        <suiteXmlFile>testng.xml</suiteXmlFile>
                    </suiteXmlFiles>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>

Для запуска тестов используется команда: mvn clean test.

Gradle – для гибкости и производительности

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

• Производительность – инкрементальные сборки и кеширование ускоряют процесс.
• Гибкий DSL – конфигурация на Groovy или Kotlin предоставляет больше возможностей, чем XML.
• Расширяемость – легко писать кастомные задачи (tasks) для специфических нужд автоматизации (например, подготовка тестовых данных, генерация отчетов).

Пример build.gradle.kts (Kotlin DSL):

plugins {
    java
    id("org.jetbrains.kotlin.jvm") version "1.9.0"
}

repositories {
    mavenCentral()
}

dependencies {
    testImplementation("org.junit.jupiter:junit-jupiter:5.10.0")
    testImplementation("io.rest-assured:rest-assured:5.3.2")
    implementation(kotlin("stdlib-jdk8"))
}

tasks.test {
    useJUnitPlatform()
    systemProperties = mapOf(
        "browser" to System.getProperty("browser", "chrome")
    )
}

// Кастомная задача для генерации аллюр-отчета
tasks.register("allureReport") {
    dependsOn(tasks.test)
    doLast {
        exec {
            commandLine("allure", "generate", "build/allure-results", "-o", "build/reports/allure-report")
        }
    }
}

NPM Scripts & Yarn – для JavaScript/TypeScript проекта

В мире фронтенд-автоматизации (Playwright, Cypress, WebdriverIO) стандартом де-факто является NPM (Node Package Manager) или его альтернатива Yarn.

• Интеграция – тесно связаны с экосистемой Node.js.
• Скрипты – возможность определять удобные команды в package.json.
• Быстрое управление зависимостями – node_modules.

Пример секции scripts в package.json для Playwright:

{
  "name": "playwright-tests",
  "version": "1.0.0",
  "scripts": {
    "test": "playwright test",
    "test:chrome": "playwright test --project=chromium",
    "test:api": "playwright test api-tests/",
    "test:ui:headed": "playwright test --headed",
    "report": "playwright show-report",
    "codegen": "playwright codegen"
  },
  "devDependencies": {
    "@playwright/test": "^1.40.0",
    "@types/node": "^20.0.0"
  }
}

Запуск: npm run test:chrome или yarn test:api.

Интеграция с CI/CD системами

Все перечисленные системы сборки тесно интегрируются в CI/CD пайплайны (Jenkins, GitLab CI, GitHub Actions, TeamCity). Это позволяет:

1. Автоматически запускать сборку и тесты при пуше в репозиторий.
2. Управлять зависимостями и окружением изолированно на агенте.
3. Публиковать артефакты (отчеты, логи, скриншоты).

Критерии выбора системы сборки

• Язык и стек проекта: Java/Kotlin – Maven/Gradle, JS/TS – NPM/Yarn.
• Сложность проекта: Для простых достаточно Maven/NPM, для сложных с кастомной логикой – Gradle.
• Требования к скорости: Gradle часто быстрее Maven за счет инкрементальности.
• Предпочтения команды и инфраструктура: Уже настроенные пайплайны и экспертиза в компании.

В современных условиях QA Automation Engineer должен уверенно владеть хотя бы одной системой сборки, соответствующей основному стеку проекта, и понимать принципы их работы для эффективной отладки, конфигурирования и интеграции тестов в процесс непрерывной поставки.