Интеграционные тесты

• Быстрый старт
• Конфигурация
• Предварительные требования
• Неразрушающие тесты
• Разрушающие тесты
• Тесты для Windows
• Тесты в контейнерах Docker
  • Запуск интеграционных тестов
  • Изображения контейнеров
    • Python 2
    • Python 3
• Тесты для устаревшей облачной инфраструктуры
• Дополнительная конфигурация для облачных тестов
• Политики IAM для AWS
  • testing-iam-policy.json.j2
  • Другие необходимые определения
• Тесты для сетей
  • Создание тестов сетевой интеграции
    • Конвенции
    • Добавление новой сетевой платформы
• Дополнительная информация

Система Ansible для интеграционных тестов.

Тесты для playbooks, по playbooks.

Для некоторых тестов могут потребоваться учетные данные. Учетные данные можно указать с помощью credentials.yml.

Для некоторых тестов может потребоваться права root.

Быстрый старт

Настоятельно рекомендуется установить и активировать пакет python argcomplete. Он обеспечивает автодополнение в bash для исполнителя тестов ansible-test.

Конфигурация

Создание собственной версии integration_config.yml позволит настроить некоторые параметры, что поможет лучше запустить тесты в вашей среде. Некоторые тесты (например, облачные) будут выполняться только при предоставлении учетных данных доступа. Более подробную информацию об поддерживаемых учетных данных см. в credentials.template.

Предварительные требования

Тесты предполагают, что инструменты hg, svn и git установлены и доступны в переменной среды PATH. Некоторые тесты (например, тесты для Amazon Web Services) требуют отдельных определений, которые будут рассмотрены позже в данном документе.

(Полный список ожидается)

Неразрушающие тесты

Эти тесты изменяют файлы в подкаталогах, но не выполняют действия, такие как установка или удаление пакетов или элементы за пределами этих подкаталогов. Они также не переконфигурируют или не перезапускают системные службы.

Запустите все тесты для платформ POSIX, выполняемые нашей системой непрерывной интеграции (CI), следующим образом:

test/runner/ansible-test integration --docker fedora25 -v posix/ci/

Вы также можете выбрать определенные тесты, например, для отдельных модулей:

test/runner/ansible-test integration -v ping

Установив argcomplete, вы можете получить полный список, выполнив:

test/runner/ansible-test integration <tab><tab>

Разрушающие тесты

Эти тесты могут устанавливать и удалять некоторые тривиальные пакеты. Вероятно, вы захотите использовать для них виртуальную среду, например, Docker. Они не отформатируют вашу файловую систему:

test/runner/ansible-test integration --docker fedora25 -v destructive/

Тесты для Windows

Эти тесты используют плагин подключения winrm и модули для Windows. Вам необходимо определить инвентаризацию с удаленным сервером Windows 2008 или 2012 для использования в тестах и включить удаленный PowerShell для продолжения.

Запуск этих тестов может привести к изменениям на вашем хосте Windows, поэтому не запускайте их в рабочей/критической среде Windows.

Включите удаленный PowerShell (запустите на хосте Windows через удаленный рабочий стол):

Enable-PSRemoting -Force

Определите инвентаризацию Windows:

cp inventory.winrm.template inventory.winrm
${EDITOR:-vi} inventory.winrm

Запустите тесты для Windows, выполняемые нашей системой непрерывной интеграции (CI):

test/runner/ansible-test windows-integration -v windows/ci/

Тесты в контейнерах Docker

Если у вас есть система Linux с установленным Docker, рекомендуется запускать интеграционные тесты с использованием тех же контейнеров Docker, которые используются системой непрерывной интеграции (CI) Ansible.

Запуск интеграционных тестов

Чтобы запустить все цели интеграционных тестов CI для платформ POSIX в контейнере Ubuntu 16.04:

test/runner/ansible-test integration -v posix/ci/ --docker

Вы также можете запустить определенные тесты или выбрать другую дистрибуцию Linux. Например, чтобы запустить тесты для модуля ping в контейнере Ubuntu 14.04:

test/runner/ansible-test integration -v ping --docker ubuntu1404

Изображения контейнеров

Python 2

Большинство контейнерных образов предназначены для тестирования с Python 2:

• centos6
• centos7
• fedora24
• fedora25
• opensuse42.1
• opensuse42.2
• ubuntu1204
• ubuntu1404
• ubuntu1604

Python 3

Для тестирования с Python 3 используйте следующие образы:

• ubuntu1604py3

Тесты для устаревшей облачной инфраструктуры

Некоторые облачные тесты выполняются как обычные интеграционные тесты, а другие — как устаревшие тесты; см. страницу Использование устаревшей системы интеграционных тестов для получения дополнительной информации.

Дополнительная конфигурация для облачных тестов

Для запуска некоторых тестов необходимо предоставить учетные данные доступа в файле с именем cloud-config-aws.yml или cloud-config-cs.ini в каталоге test/integration. Доступны соответствующие файлы шаблонов (.template) для помощи в синтаксисе. Более новые тесты для AWS теперь используют файл test/integration/cloud-config-aws.yml

Политики IAM для AWS

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

testing-iam-policy.json.j2

Файл testing-iam-policy.json.j2 содержит политику, которая может быть предоставлена пользователю, выполняющему тесты, чтобы минимизировать права этого пользователя. Обратите внимание, что, хотя эта политика ограничивает пользователя одной областью, это не полностью ограничивает пользователя (в основном из-за ограничений обозначения Amazon ARN). Пользователь по-прежнему будет иметь широкие привилегии для просмотра определений учетных записей и также сможет управлять некоторыми ресурсами, которые не связаны с тестированием (например, AWS лямбда-функциями с другими именами). В любом случае тесты не следует запускать в основной рабочей учетной записи.

Другие необходимые определения

Помимо установки политики и предоставления ее идентификатору пользователя, выполняющему тесты, необходимо создать роль lambda ansible_integration_tests, имеющую базовые права выполнения лямбда-функций.

Тесты для сетей

На этой странице подробно описаны аспекты тестирования сетевых модулей Ansible.

Сетевые интеграционные тесты можно запустить, выполнив:

cd test/integration
ANSIBLE_ROLES_PATH=targets ansible-playbook network-all.yaml

Для фильтрации набора тестовых случаев установите limit_to в имя группы, как правило, это имя модуля:

ANSIBLE_ROLES_PATH=targets ansible-playbook -i inventory.network network-all.yaml -e "limit_to=eos_command"

Для фильтрации отдельного тестового случая установите опцию тегов на eapi или cli, установите limit_to для группы тестов и test_cases для имени теста:

ANSIBLE_ROLES_PATH=targets ansible-playbook -i inventory.network network-all.yaml --tags="cli" -e "limit_to=eos_command test_case=notequal"

Создание тестов сетевой интеграции

Тестовые случаи добавляются в роли на основе тестируемого модуля. Тестовые случаи должны включать как клиенты, так и API-тестовые случаи. Клиентские тестовые случаи должны быть добавлены в test/integration/targets/modulename/tests/cli, а API-тесты — в test/integration/targets/modulename/tests/eapi или nxapi.

В дополнение к позитивным тестам требуются негативные тесты, чтобы гарантировать, что пользовательские предупреждения и ошибки генерируются, а не трассировки стека, например:

Конвенции

• Каждый тестовый случай, как правило, должен следовать схеме:

  настройка —> тест —> утверждение —> повторный тест (идемпотентность) —> утверждение —> разборка (при необходимости) —> завершено

  Это помогает предотвратить превращение тестовых playbooks в монолитные и сложные для отладки.

• Включите имя для каждой задачи, которая не является утверждением. (Добавление имен к утверждениям также допустимо. Но чтобы легко идентифицировать сломанную задачу в случае неудачи теста, предоставьте, по крайней мере, понятное имя для каждой задачи.)
• Файлы, содержащие тестовые случаи, должны заканчиваться на .yaml

Добавление новой сетевой платформы

Требуется playbook верхнего уровня, например, ansible/test/integration/eos.yaml, который необходимо указать в ansible/test/integration/network-all.yaml.

Дополнительная информация

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