1. Основы проектирования: структура Java-проекта и управление зависимостями в Maven/Gradle
Основы проектирования: структура Java-проекта и управление зависимостями
Почему один проект автоматизации легко поддерживает команда из десяти человек, а другой превращается в «спагетти-код», где страшно поменять версию библиотеки? Разница кроется не в количестве тестов, а в фундаменте — архитектуре проекта и управлении его зависимостями. Если вы когда-либо сталкивались с ситуацией, когда локально тесты проходят, а на CI падают из-за конфликта версий библиотек, значит, вы уже ощутили важность правильной сборки проекта.
Многослойная архитектура: зачем делить проект
Профессиональный фреймворк — это не просто набор скриптов, а полноценное программное обеспечение. Чтобы система была масштабируемой, мы разделяем ответственность между слоями. Это позволяет менять библиотеку (например, перейти с Selenium на Selenide), не переписывая саму логику тестов.
Стандартная структура современного Java-проекта (согласно соглашениям Maven/Gradle) выглядит так:
* src/main/java — здесь живет «движок» фреймворка: базовые страницы, конфигурации, утилиты для работы с Kafka и БД.
* src/test/java — здесь находятся только тестовые сценарии и тестовые данные.
* src/test/resources — файлы конфигурации (.properties, .yaml), логи и настройки окружения.
> Разделение main и test — это не просто формальность. При сборке артефакта (jar-файла) для использования в других проектах, тестовые классы не попадут в финальную сборку, что уменьшает размер и исключает лишние зависимости.
Выбор инструмента сборки: Maven vs Gradle
Для построения фреймворка нам нужен менеджер зависимостей. Он решает две задачи: скачивает нужные библиотеки (Selenium, TestNG, Kafka Client) и управляет процессом компиляции и запуска.
| Характеристика | Maven | Gradle |
| :--- | :--- | :--- |
| Конфигурация | XML (pom.xml) — строго, декларативно. | Groovy/Kotlin (build.gradle) — гибко, программно. |
| Скорость | Стандартная. | Высокая (за счет инкрементальной сборки и кэширования). |
| Порог входа | Низкий — структура всегда одинакова. | Выше — требует понимания скриптового языка. |
| Популярность | Стандарт индустрии для Enterprise. | Растущий стандарт, особенно для сложных Android/Mobile систем. |
Для нашего курса мы будем использовать Maven как наиболее стабильный и предсказуемый инструмент для Enterprise-решений, однако принципы управления зависимостями идентичны для обоих инструментов.
Управление зависимостями и транзитивные конфликты
Одной из главных проблем при проектировании фреймворка является конфликт версий. Например, ваша библиотека для работы с Kafka требует Jackson версии 2.12, а Selenium — версии 2.15.
В Maven управление зависимостями строится на дереве. Если возникает конфликт, Maven применяет правило «ближайшего объявления» (Nearest Definition). Чтобы избежать хаоса, мы используем секцию <dependencyManagement>.
Здесь — итоговая версия библиотеки, которая будет включена в проект. Мы сначала проверяем наличие жестко заданной версии в блоке управления (dependencyManagement), и только если её там нет, используем правило «ближайшего соседа» в дереве зависимостей.
Проектирование структуры пакетов
Правильное именование пакетов (packages) определяет, насколько быстро новый инженер разберется в вашем коде. Мы будем придерживаться инвертированного доменного имени:
com.autoframework.core — базовые классы драйвера и конфигурации.com.autoframework.pages — реализация Page Object (UI-логика).com.autoframework.steps — бизнес-шаги (Business Layer).com.autoframework.utils — работа с Kafka, БД, чтение файлов.Такая изоляция позволяет реализовать принцип Low Coupling (слабая связанность). Если завтра нам понадобится добавить интеграцию с Kubernetes, мы просто создадим новый пакет в utils, не затрагивая слой тестов.
Жизненный цикл сборки
Важно понимать, в какой момент происходит запуск тестов. В Maven это фаза test, которая следует за compile.
clean — удаление папки target с результатами прошлой сборки.compile — проверка синтаксиса и компиляция кода.test — запуск тестов (именно здесь подключаются TestNG или JUnit).verify — проверка результатов (например, проверка отчетов Allure).Именно на этапе проектирования мы закладываем возможность запускать тесты одной командой в терминале: mvn clean test -Dbrowser=chrome. Это критически важно для будущей интеграции с CI/CD пайплайнами.