Непрерывная интеграция

После того, как вы настроили набор тестов и запустили его, вы захотите запускать тесты регулярно. Если вы обеспечите, чтобы тесты выполнялись при каждом изменении кода или хотя бы один раз в день, вы можете быть уверены, что не будет регрессии. Это позволяет поддерживать стабильность вашей системы. Но разработчики не так увлечены ручным запуском всех тестов, они также могут забыть выполнить тесты перед отправкой кода в производство… Решение простое, выполнение тестов должно быть автоматизировано. Вместо запуска их локально лучше иметь выделенный сервер, ответственный за выполнение тестов для команды. Таким образом, мы можем гарантировать, что тесты каждого пользователя выполнены, какой коммит внёс регрессию в кодовую базу, и что мы можем развернуть приложение только после успешного прохождения тестов.

Существует много серверов непрерывной интеграции. Мы постараемся перечислить основные шаги по настройке тестов Codeception с ними. Если ваша система CI не упомянута, вы можете получить представление по аналогии. Пожалуйста, помогите нам расширить это руководство, добавив инструкции для различных CI.

Jenkins

Jenkins — одно из самых популярных открытых решений на рынке. Его легко настроить и настроить, применяя различные плагины.

Подготовка Jenkins

Рекомендуется установить следующие плагины:

• Плагин Git — для построения тестов для репозитория Git
• Зелёные шарики — для отображения успешных результатов зелёным цветом.
• Плагин xUnit, Плагин jUnit — для обработки и отображения отчетов Codeception в формате XML
• Плагин HTML Publisher — для обработки отчетов Codeception в формате HTML
• Плагин AnsiColor — для отображения цветного вывода консоли.

Базовая настройка

Сначала нам нужно создать проект сборки. В зависимости от ваших потребностей вы можете настроить периодическую сборку или запустить сборку при внесении изменений в GitHub (для этого вам понадобится плагин GitHub).

Нам нужно определить шаги сборки. Наиболее простая настройка может выглядеть следующим образом:

 vendor/bin/codecept run

Затем мы можем начать первую задачу и проверить процесс выполнения. Если тесты завершатся неудачно, мы увидим это в консоли:

XML-отчеты

Но мы не хотим анализировать вывод консоли для каждой неудачной сборки. Особенно, если Jenkins может собирать и отображать результаты внутри своего веб-интерфейса. Codeception может экспортировать свои результаты в формате XML JUnit. Для генерации отчёта XML при каждой сборке нам нужно добавить --xml опцию к команде выполнения Codeception. Codeception напечатает result.xml файл, содержащий информацию о статусе теста с шагами и отслеживанием стека для неудачных тестов.

Теперь давайте обновим шаг сборки, чтобы сгенерировать XML:

 vendor/bin/codecept run --xml

и попросим Jenkins собрать полученные XML-файлы. Это можно сделать в рамках действий после сборки. Добавьте действие «Опубликовать отчет о результатах тестирования xUnit» и настройте его для использования с отчётами PHPUnit.

Теперь мы должны указать путь к XML-отчетам в стиле PHPUnit. В случае стандартной настройки Codeception мы должны указать tests/_output/*.xml в качестве шаблона для сопоставления полученных XML-файлов. Теперь сохраняем проект и перестраиваем его.

Теперь для всех сборок мы увидим график тенденций результатов, который показывает нам процент успешных и неудачных тестов. Мы также увидим ссылку «Последние результаты тестирования», которая переведёт нас на страницу, где все выполненные тесты и их статистика представлены в таблице.

HTML-отчеты

Чтобы получить больше деталей о выполненных шагах, вы можете сгенерировать HTML-отчёт и использовать Jenkins для его отображения.

 vendor/bin/codecept run --html

Теперь нам нужно настроить плагин HTML Publisher для отображения сгенерированных HTML-файлов. Его нужно добавить как действие после сборки, аналогично тому, как мы это сделали для XML-отчётов.

Jenkins должен найти report.html в tests/_output/. Теперь Jenkins будет отображать HTML-отчёты для каждой сборки.

TeamCity

TeamCity — это хостированное решение от JetBrains. Настройка может быть немного сложной, так как TeamCity использует свой собственный формат отчета для анализа результатов тестирования. PHPUnit с версии 5.x имеет встроенную поддержку этого формата, как и Codeception. Нам нужно настроить Codeception для использования пользовательского репортера. По умолчанию есть --report опция, которая предоставляет альтернативный вывод. Вы можете изменить класс репортера в codeception.yml конфигурации:

reporters:
  report: PHPUnit_Util_Log_TeamCity

В качестве альтернативы вы можете использовать стороннее расширение TeamCity для лучшей отчетности.

После создания проекта сборки вы должны определить шаг сборки с Codeception, который выглядит следующим образом

 vendor/bin/codecept run --report

После выполнения первой сборки вы должны увидеть подробный отчет внутри интерфейса TeamCity:

TravisCI

Travis CI — популярная служба CI с хорошей интеграцией с GitHub. Codeception самотестируется с Travis CI. Нет ничего особенного в конфигурации. Просто добавьте в конец конфигурации Travis:

php vendor/bin/codecept run

Дополнительные сведения о конфигурации можно получить из документации Codeception по .travis.yml.

Travis не предоставляет визуализации для XML или HTML-отчётов, поэтому вы не можете просматривать отчеты в формате, отличном от вывода консоли. Однако Codeception генерирует хороший вывод в консоль с подробными сообщениями об ошибках.

GitLab

Если файл .gitlab-ci.yml существует в корне репозитория Git, GitLab запустит конвейер каждый раз, когда вы внесёте изменения в репозиторий GitLab. Файл настраивает образ Docker, который будет вызван. Ниже приведён пример, который загружает образ php7 Docker, клонирует ваши файлы, устанавливает зависимости Composer, запускает встроенный веб-сервер PHP и, наконец, запускает Codeception:

# Select image from https://hub.docker.com/_/php/
image: php:7.0

# Select what we should cache
cache:
  paths:
  - vendor/

before_script:
# Install git and unzip (composer will need them)
- apt-get update && apt-get install -qqy git unzip
# Install composer
- curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
# Install all project dependencies
- composer install
# Run webserver
- php -S localhost:8085 --docroot public &>/dev/null&

# Test
test:
  script:
  - vendor/bin/codecept run

Для приёмочного тестирования вы можете использовать codeception/codeception образ Docker в качестве базы. Смотрите пример ниже:

image:
  name: codeception/codeception
  # clear image entrypoint to make bash being available
  entrypoint: [""]

# run selenium chrome as a local service (put "host: 'selenium__standalone-chrome'" in environment configuration)
services:
  - selenium/standalone-chrome:latest

# Select what we should cache
cache:
  paths:
  - vendor/

before_script:
# Install all project dependencies
- composer install

# Test
test:
  script:
    - vendor/bin/codecept run acceptance --xml --html
  artifacts:
    when: always
    expire_in: 1 week
    paths:
      - tests/_output
    # make the report available in Gitlab UI. see https://docs.gitlab.com/ee/ci/unit_test_reports.html
    reports:
      junit: tests/_output/report.xml

Заключение

Настоятельно рекомендуется использовать систему непрерывной интеграции в процессе разработки. Codeception легко установить и запустить в любой системе CI. Однако у каждой из них есть свои особенности, которые следует учитывать. Вы можете использовать различные репортеры для предоставления вывода в формате, ожидаемом системой CI.

• Следующая глава: Параллельное выполнение >
• Предыдущая глава: < Покрытие кода