Единые тесты

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

• Доступные тесты
• Запуск тестов
• Установка зависимостей
• Расширение единых тестов
  • Структурирование единых тестов
  • Общие тесты для модуля
  • Файлы фикстур
  • Покрытие кода новыми или обновлёнными едиными тестами

Доступные тесты

Единые тесты можно найти в test/units. Обратите внимание, что структура каталога тестов соответствует структуре lib/ansible/.

Запуск тестов

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

cd /path/to/ansible/source
source hacking/env-setup
ansible-test units --tox

Для отдельного файла:

ansible-test units --tox apt

Или для определённой версии Python:

ansible-test units --tox --python 2.7 apt

Для расширенного использования см. онлайн-справку:

ansible-test units --help

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

Установка зависимостей

ansible-test имеет ряд зависимостей. Для units тестов мы рекомендуем использовать tox.

Зависимости можно установить, используя аргумент --requirements, который установит все необходимые зависимости для единых тестов. Например:

ansible-test units --tox --python 2.7 --requirements apache2_module

Полный список требований можно найти в test/runner/requirements. Файлы требований названы в соответствии с соответствующими командами. Также см. ограничения, применимые ко всем командам.

Расширение единых тестов

Структурирование единых тестов

Ansible управляет едиными тестами с помощью pytest. Это означает, что тесты могут быть написаны как простые функции, включенные в любой файл, например, test_<something>.py, или как классы.

Вот пример функции:

#this function will be called simply because it is called test_*()

def test_add()
    a = 10
    b = 23
    c = 33
    assert a + b = c

Вот пример класса:

import unittest:

class AddTester(unittest.TestCase)

    def SetUp()
        self.a = 10
        self.b = 23

    # this function will
    def test_add()
      c = 33
      assert self.a + self.b = c

   # this function will
    def test_subtract()
      c = -13
      assert self.a - self.b = c

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

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

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

Общие тесты для модуля

Общие коды должны быть максимально специфичными внутри структуры каталога test/units/. Например, если они специфичны для тестирования модулей Amazon, они должны находиться в test/units/modules/cloud/amazon/. Не импортируйте общий код единого теста из директорий, находящихся за пределами текущей или родительской директорий.

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

Файлы фикстур

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

Текстовые файлы находятся в test/units/modules/network/PLATFORM/fixtures/

Данные загружаются с помощью метода load_fixture

См. eos_banner тест для практического примера.

Если вы моделируете API, вы можете обнаружить, что python placebo полезен. См. документ: testing_units_modules для получения дополнительной информации.

Покрытие кода новыми или обновлёнными едиными тестами

Новый код будет отсутствовать в отчётах о покрытии codecov.io (см. Тестирование Ansible), поэтому необходимо локальное отслеживание. Большинство ansible-test команд позволяют собирать покрытие кода; это особенно полезно для определения места расширения тестирования.

Для сбора данных о покрытии добавьте аргумент --coverage к вашей команде ansible-test:

ansible-test units --coverage apt
ansible-test coverage html

Результаты будут записаны в test/results/reports/coverage/index.html

Отчёты можно сгенерировать в нескольких форматах:

• ansible-test coverage report — Отчёт в консоли.
• ansible-test coverage html — Отчёт в формате HTML.
• ansible-test coverage xml — Отчёт в формате XML.

Для очистки данных между запусками тестов используйте команду ansible-test coverage erase. См. testing_units_running_locally для получения дополнительной информации о создании отчётов о покрытии кода.