Настройка CI/CD и Test IT для запуска автотестов на Java

🎯 Задача

Настроить запуск автотестов на Java (JUnit 5, Maven) в GitLab CI и Test IT с передачей результатов в Test IT.

💡 Решение

В CI/CD настроим runner (раннер), подключим адаптер Test IT для JUnit, в Test IT создадим вебхуки для запуска автотестов. Если нужно, настроим запуск по расписанию. После настройки каждый запуск автоматически создаст в Test IT прогон с полными результатами тестов.

Перед началом работы

📝 Вам потребуются:

⏱ Время: ≈30-40 мин

Шаг 1: подключаем GitLab Runner

ℹ️ GitLab Runner (раннер) — это агент, который работает вместе с GitLab CI/CD и выполняет задания (jobs). Он нужен для запуска пайплайна (конвейера) в GitLab.

🛠️ Чтобы подключить GitLab Runner:

  1. Установите раннер по официальной инструкции GitLab.
  2. Зарегистрируйте раннер по официальной инструкции GitLab.
    Раннер отобразится в директории Settings → CI/CD → Runners.

✅ Результат: В GitLab установлен и настроен раннер. Он доступен в директории Settings → CI/CD → Runners и активен. GitLab Runner для интеграции автотестов с Test IT

Шаг 2: Подключаем адаптер Test IT к проекту Maven

ℹ️ Подробнее о подключении адаптера к проекту Maven

🛠️ Чтобы подключить адаптер к проекту Maven:

  1. В файл pom.xml в dependencies добавьте данные о JUnit 5 и адаптере Test IT:
    • junit-jupiter
    • testit-java-commons
    • testit-adapter-junit5
    • aspectjweaver, aspectjrt
    • junit-platform-launcher
  2. Перезагрузите проект Maven.

📥 Скачать образец файла pom.xml

✅ Результат: Адаптер Test IT подключен к проекту Maven.

Шаг 3: указываем конфигурацию пайплайна GitLab CI

ℹ️ Справка по синтаксису файла .gitlab-ci.yml

🛠️ Чтобы указать конфигурацию пайплайна GitLab CI:

  1. Добавьте в корень репозитория файл .gitlab-ci.yml с нужным пайплайном.
  2. В файле .gitlab-ci.yml перед текстом mvn test укажите:
    • Описание стадии build
    • Описание стадии test, содержащее в разделе src/test/resources формирование testit.properties

📥 Скачать образец файла .gitlab-ci.yml

✅ Результат: Пайплайн в GitLab CI настроен и готов к работе.

Шаг 4: определяем конфигурацию адаптера и выбираем режим работы

ℹ️ О конфигурации адаптера на GitHub

🛠️ Чтобы сконфигурировать адаптер:

  1. В корневой папке проекта cоздайте конфигурационный файл connection_config.ini.
  2. В файле connection_config.ini укажите необходимые параметры в зависимости от режима работы адаптера (определяется параметром adapterMode):
    • Mode 0 (используется по умолчанию): загрузка результатов в существующий прогон с фильтрацией
    • Mode 1: загрузка результатов в существующий прогон без фильтрации
    • Mode 2 (рекомендуется): автоматическое создание нового прогона

    Укажите режим работы адаптера

    Если не указать режим работы (adapterMode), будет использован Mode 0, тогда параметр testRunId станет обязательным.

    Mode 2 (рекомендуется)

    Описание: Адаптер создает новый прогон в Test IT и отправляет результаты всех запущенных тестов в этот новый прогон.

    Когда использовать: Идеально для локальной отладки, первичного подключения и ежедневных запусков без заранее созданного тест-плана. Вам не нужно предварительно ничего создавать в интерфейсе Test IT.

    Пример connection_config.ini:

    [testit]
url = http://192.168.187.81/
privateToken = S2RZUmpiRnp4U1RlRmNmVEcz
projectId = 569f28f1-a8f9-4762-b12b-c40955bc63f1
configurationId = be1b1df4-aae6-4f5f-a8df-2be01d5c0311
automaticCreationTestCases = false
certValidation = false
adapterMode = 2
📝 Параметры конфигурации (список)
#ПараметрОбязательныйОписание
1urlДаURL Test IT
2privateTokenДаAPI-токен
В Test IT: Настройки профиля → Безопасность
3projectIdДаGUID проекта из URL
В Test IT: Проекты → Меню действий → Скопировать ID
4configurationIdРекомендуетсяGUID конфигурации (если не указать — результаты попадут в Any).
В Test IT: Конфигурации → Меню действий → Скопировать GUID
5testRunIdДля Mode 0-1GUID существующего прогона Test IT
В Test IT: Прогоны → Меню действий → Скопировать ID
6testRunNameНетНазвание прогона (для Mode 2)
7adapterModeВажноВыбор режима: 0, 1 или 2.
По умолчанию: 0.
8automaticCreationTestCasesНетtrue — создавать ручные кейсы из автотестов
false (по умолчанию) — не создавать
9automaticUpdationLinksToTestCasesНетtrue — обновлять связи автотестов с кейсами
false (по умолчанию) — не обновлять
10certValidationНетtrue (по умолчанию) — проверять SSL-сертификат
false — для самоподписанных сертификатов
11importRealtimeНетtrue (по умолчанию) — отправлять каждый тест сразу после выполнения
false — собрать все и отправить пакетом
12testItНетtrue (по умолчанию) — включить интеграцию с Test IT
false — отключить интеграцию с Test IT

✅ Результат: В корневой папке проекта находится файл connection_config.ini, определяющий конфигурацию адаптера, включая режим его работы.

Шаг 5: создаем вебхуки в Test IT

ℹ️ Для управления автотестами из Test IT нужно создать вебхук для события Запуск автотестов. Подробнее о вебхуках в Test IT.

🛠️ Чтобы создать вебхук:

  • Следуйте инструкции в документации Test IT. При создании вебхука укажите:
    • URL: URL репозитория CI/CD
    • Тип запроса: POST (выбран по умолчанию) Создание вебхука для запуска автотестов в Test IT
    • Параметры URL: Ветку GitLab; токен GitLab; параметр TEST_RUN_ID со значением $TEST_RUN_IDСоздание вебхука для запуска автотестов в Test IT
⚠️ Возможные трудности для серверной версии, установленной в Docker Compose

Если Test IT развёрнут на виртуальной машине и сам обращается к GitLab по HTTPS (например, по вебхуку), возможны проблемы с сертификатом. В таких случаях:

✅ Результат: В проекте Test IT (Вебхуки → Настройка) создан вебхук для запуска автотестов.

Шаг 6: Делаем пробный прогон автотестов

ℹ️ После запуска автотестов в Test IT будут созданы карточки автотестов и прогон. Можно будет работать с автотестами из интерфейса Test IT.

🛠️ Для проверки нужно запустить автотесты:

  • Из GitLab: Сделайте push ветки.
    При успешном запуске в GitLab появится пайплайн, а в Test IT — новый прогон Run с результатами по всем автотестам.
  • Из интерфейса Test IT: Запустите несколько автотестов, следуя инструкции.
    При успешном запуске в GitLab будет запущен пайплайн с переменной TEST_RUN_ID, в Test IT будет создан прогон, содержащий выбранные тесты.

✅ Результат: В разделе Автотестирование → Библиотека автотестов Test IT находятся карточки с метаданными автотестов. В разделе Автотестирование → Прогоны Test IT находятся прогоны с результатами автотестов.

GitLab CI настроен для запуска автотестов и передачи результатов в Test IT. Следующий шаг — настройка расписания запусков в GitLab — опциональный.

Шаг 7: настраиваем запуск по расписанию (scheduler)

ℹ️ Документация GitLab о настройке расписания

🛠️ Чтобы запускать все автотесты по расписанию (например, выполнять ночной прогон):

  1. В GitLab откройте ваш проект, затем перейдите в Build → Pipeline schedules → New schedule.
  2. Укажите:
    • Описание прогона
    • Целевую ветку (например, main — она должна совпадать с ветками, указанными в rules .yml-файла)
    • Интервал в формате cron (время в UTC). Примеры:
      • 0 2 * * — каждый день в 02:00 UTC
      • 0 /6 * * — каждые 6 часов
      • /3 * * * * — каждые 3 минуты (удобно для проверки)
    • Опционально: В расписании задайте дополнительные переменные (например, переопределить TMS_*)
  3. Сохраните изменения.

При срабатывании расписания пайплайн запускается так же, как при выполнении команды push.

✅ Результат: В проекте GitLab в разделе Build → Pipeline schedules создано расписание прогонов. Когда расписание активно, прогоны автоматически выполняются по расписанию. Расписание GitLab для автоматических прогонов в Test IT

Обновлено: