Тестирование Ansible

• Введение
• Типы тестов
• Тестирование в GitHub & Shippable
  • Организация
  • Повторное выполнение не пройденного CI задания
• Как протестировать PR
  • Настройка: Выгрузка запроса на добавление изменений
  • Тестирование запроса на добавление изменений
    • Онлайн покрытие кода
• Хотите узнать больше о тестировании?

Введение

Этот документ описывает:

• как тестируется Ansible
• как протестировать Ansible локально
• как расширить возможности тестирования

Типы тестов

На высоком уровне у нас есть следующие классификации тестов:

Если вы разработчик, одним из самых ценных действий является просмотр списка проблем GitHub и помощь в исправлении ошибок. Мы почти всегда отдаём приоритет исправлению ошибок по сравнению с разработкой новых функций.

Даже для не-разработчиков помощь в тестировании запросов на добавление изменений для исправления ошибок и новых функций очень важна. Пользователи Ansible, которые понимают написание playbooks и ролей, должны быть в состоянии добавлять интеграционные тесты, а запросы на добавление изменений с интеграционными тестами, демонстрирующими ошибки, также будут отличным способом помочь.

Тестирование в GitHub & Shippable

Организация

При создании запросов на добавление изменений (PR) они тестируются с помощью Shippable, инструмента непрерывной интеграции (CI). Результаты отображаются в конце каждого PR.

Когда Shippable обнаруживает ошибку, и её можно связать с файлом, изменённым в PR, соответствующие строки будут добавлены в качестве комментария GitHub. Например:

The test `ansible-test sanity --test pep8` failed with the following errors:

lib/ansible/modules/network/foo/bar.py:509:17: E265 block comment should start with '# '

The test `ansible-test sanity --test validate-modules` failed with the following errors:
lib/ansible/modules/network/foo/bar.py:0:0: E307 version_added should be 2.4. Currently 2.3
lib/ansible/modules/network/foo/bar.py:0:0: E316 ANSIBLE_METADATA.metadata_version: required key not provided @ data['metadata_version']. Got None

Из приведённого примера видно, что --test pep8 и --test validate-modules выявили проблемы. Приведенные команды позволяют запускать те же тесты локально, чтобы убедиться, что вы исправили проблемы, не отправляя изменения в GitHub и не дожидаясь Shippable, например:

Если у вас ещё нет Ansible, используйте локальную копию, запустив:

source hacking/env-setup

Затем запустите тесты, описанные в комментарии GitHub:

ansible-test sanity --test pep8
ansible-test sanity --test validate-modules

Если в комментарии GitHub не указано, что произошло сбой, вы можете проверить результаты, нажав кнопку «Подробности» под сообщением «проверки не пройдены» в конце PR.

Повторное выполнение не пройденного CI задания

Иногда ваш PR может завершиться неудачей по причине, не связанной с вашим изменением. Это может произойти по нескольким причинам, в том числе:

• временная проблема с доступом к внешнему ресурсу, такому как yum или git репозиторий
• тайм-аут при создании виртуальной машины для запуска тестов

Если кажется, что проблема связана с одной из этих причин, вы можете перепроверить Shippable-тесты, выполнив:

• закрытие и повторное открытие PR
• внесите другое изменение в PR и отправьте его в GitHub

Если проблема сохраняется, пожалуйста, свяжитесь с нами в #ansible-devel на канале Freenode IRC.

Как протестировать PR

В идеале код должен добавлять тесты, подтверждающие работоспособность кода. Это не всегда возможно, и тесты не всегда исчерпывающи, особенно когда пользователь не имеет доступа к широкому спектру платформ или использует API или веб-сервис. В этих случаях тестирование в реальном времени на реальном оборудовании может быть более ценным, чем автоматизация, выполняемая на симулированных интерфейсах. В любом случае, вещи всегда должны тестироваться вручную в первый раз.

К счастью, помощь в тестировании Ansible довольно проста, предполагая, что вы знакомы с тем, как работает Ansible.

Настройка: Выгрузка запроса на добавление изменений

Вы можете сделать это, выполнив:

• выгрузку Ansible
• создание тестовой ветки от основной ветки
• слияние проблемы GitHub
• тестирование
• добавление комментариев к этой конкретной проблеме в GitHub

Вот как:

Создайте новую рабочую область:

git clone https://github.com/ansible/ansible.git ansible-pr-testing
cd ansible-pr-testing

Далее найдите запрос на добавление изменений, который вы хотите протестировать, и обратите внимание на строку вверху, которая описывает исходные и целевые репозитории. Она будет выглядеть примерно так:

Someuser wants to merge 1 commit into ansible:devel from someuser:feature_branch_name

Имя пользователя и ветка в конце — важные части, которые будут преобразованы в команды git следующим образом:

git checkout -b testing_PRXXXX devel
git pull https://github.com/someuser/ansible.git feature_branch_name

Первая команда создаёт и переключается на новую ветку, названную testing_PRXXXX, где XXXX — фактический номер проблемы, связанной с запросом на добавление изменений (например, 1234). Эта ветка основана на ветке devel. Вторая команда подтягивает новый код из ветки с функциями пользователя в только что созданную ветку.

Исходный код Ansible включает скрипт, позволяющий использовать Ansible напрямую из исходного кода без полной установки, который часто используется разработчиками Ansible.

Просто запустите его (чтобы использовать терминологию Linux/Unix), чтобы начать его немедленное использование:

source ./hacking/env-setup

Этот скрипт изменяет переменные среды PYTHONPATH (а также ещё несколько вещей), которые будут временно установлены до тех пор, пока ваше сеанса работы с оболочкой открыто.

Тестирование запроса на добавление изменений

На этом этапе вы должны быть готовы к тестированию!

Некоторые идеи по тестированию:

• Создайте тестовый Playbook с примерами и проверьте, работают ли они правильно
• Проверьте, возвращаются ли какие-либо обратные следы Python (это ошибка)
• Тестируйте на разных операционных системах или с разными версиями библиотек

Любые потенциальные проблемы должны быть добавлены в комментарии к запросу на добавление изменений (и допустимо добавлять комментарий, если функция работает также), не забывая включить вывод ansible --version

Пример:

Works for me! Tested on `Ansible 2.3.0`.  I verified this on CentOS 6.5 and also Ubuntu 14.04.

Если PR не разрешает проблему, или вы видите какие-либо сбои из юнит/интеграционных тестов, просто включите этот вывод вместо него:

Онлайн покрытие кода

The online code coverage reports <https://codecov.io/gh/ansible/ansible> — хороший способ определить области для улучшения тестирования Ansible. Следуя красным цветам, вы можете углубиться в отчёты, чтобы найти файлы, в которых вообще нет тестов. Добавление интеграционных и юнит-тестов, чётко демонстрирующих, как работает код, проверка важных функций Ansible и повышение охвата тестирования в областях, где его нет, — ценный способ улучшения Ansible.

Отчёты о покрытии кода охватывают только ветку devel Ansible, где происходит разработка новых функций. Запросы на добавление изменений и новый код будут отсутствовать в отчётах о покрытии codecov.io, поэтому необходимо местное отслеживание. Большинство ansible-test команд позволяют собирать данные о покрытии кода, это особенно полезно для указания областей расширения тестирования. См. Тестирование Ansible для получения дополнительной информации.

Хотите узнать больше о тестировании?

Если вы хотите узнать больше о планах по улучшению тестирования Ansible, то почему бы не присоединиться к Рабочей группе по тестированию.