В системном программирования достаточно часто возникает ситуация, когда значительная часть функциональности программы перекладывается на внешние компоненты. Типичный пример — операции с iptables, дисковыми образами и виртуальными машинами. Классически для тестирования такого кода используются массовые моки, отрезающие тестируемый код от всех внешних зависимостей.
При очевидных достоинствах (полная независимость тестов от внешнего мира, скорость исполнения, etc) у моков есть некоторое количество недостатков — самый главный это переход от тестирования того что должно быть сделано к тестирования того как это сделано. Если нужно проверить функцию, которая настраивает проброс порта, то вместо тестирования результата (правильного прохождения пакетов) проверяется, что iptables вызвалась с правильными параметрами.
По итогу юнит тест проверяет не правильность работы кода, а является отражением его структуры. Такой тест помогает обеспечить постоянную проверку на отсутствие AttributeError и ему подобных (python), но на этом его полезность оканчивается. Учитывая желание менеджера и/или заказчика получить заветные X% покрытия ситуация становится совсем идиотской. Несколько последних проектов, в которых я учавствовал были именно такие — тонкая прослойка из python, связывающая вместе БД, REST, xen, iptables и еще горстку linux утилит в небольшой специализированный клауд. По итогу заметная часть UT требует переписывания после каждого рефакторинга, потому как изменилось взаимодействие с внешними компонентами. То что должно поощрять рефакторинг и улучшение кода становится одним из главных его тормозов.
Частично эта ситуация отражает объективный факт — мы не можем позволить юнит-тестам бесконтрольтно модифицировать файловую систему на локальной машине, изменять правила прохождения пакетов или ip маршруты. Дополнительный минус — рабочая машина разработчика не всегда соответствует требованиям к конечному серверу.
Решение совершенно очевидное — использовать для тестов виртуальные машины и проводить тесты на необходимой конфигурации + исключить бОльшую часть моков из тестов.
Итого — что хотелось получить:
- исполнять отдельные юнит-тесты на виртуальных машинах или группах машин
- интеграция с nosetests и coverage
- максимально простое использование
- высокая скорость — юнит-тесты должны исполняться быстро
Как хотелось это использовать:
@on_vm('worker-1')
def test_iptables():
make_iptables_rules()
check_packages_goes_ok()@on_vm(‘worker-2’)
def test_something():
make_something()
check_something_works()
@on_vm('worker-1')
def test_iptables():
make_iptables_rules()
check_packages_goes_ok()@on_vm(‘worker-2’)
def test_something():
make_something()
check_something_works()
Доводить идею до рабочего варианта в рамках внутреннего проекта взялись интерны нашей компании — Игорь Гарагатый и Настя Криштопа.
Для начала было решено реализовать достаточно простой вариант: перед исполнением каждого теста, требующего виртуальную машину, запускалась соответствующая vm, на нее копировался код и тесты, запускались тесты и их результаты тестов возвращались назад на хост машину. Если тест выбросит исключение оно должно передаваться назад на хост и выбрасываться из локального теста — nose не должен замечать разницы между локальным и удаленным исполнением теста.
В итоге были выбраны два варианта — LXC и KVM. LXC позволяет запустить виртуальную машину менее чем за секунду и не требует аппаратной поддержки виртуализации, а KVM это более надежный вариант, позволяющий запускать виртуальные машины любых конфигураций (LXC использует ядро хост системы, поэтому поднять в нем другую версию ядра или другую OS невозможно).
Хотелось иметь в vm файловую систему доступную для записи, но возвращаемую в начальное состояние после окончания теста. Для kvm это естественным образом решается возможностями qcow2, который позволяет сохранять все изменения в отдельный файл, не трогая оригинальный образ. Для LXC же нужна была файловая система с поддержкой снимков и быстрым откатом к ним. После рассмотрения btrfs, LVM+XFS и aufs решили остановиться на первом варианте.
Что в итоге получилось:
- Пользователь подготавливает образы и конфигурации виртуальных машин, которые будут использоваться для UT
- Оборачивает отдельные тесты декоратором on_vm с указанием на какой конфигурации его запускать
- nosetests unitTests
- profit (итоги тестов и coverage)
Примерная схема работы:
- Декоратор on_vm создает отдельный процесс, для поднятия ВМ и запускает поток, слушающий результаты на сокете
- test_executor.py создает с помощью libvirt необходимую конфигурацию vm, предварительно сделав слепок btrfs или подключив qcow2 файл для сохранения изменений (в зависимости от типа виртуальной машины)
- test_executor.py дожидается окончания запуска vm, копирует туда необходимые файлы и запускает только выбранные тест на исполнение, предварительно выставив переменные окружения
- on_vm по переменным окружения определяет, что это реальных запуск и исполняет тест
- при возникновении ошибки она сериализуется и передается на хост
- итоги теста передаются на хост вместе с результатами покрытия
- процесс на хосте принимает результаты, гасит vm, откатывает состояние образа и имитирует локальное исполнение теста.
На текущий момент результат пока в состоянии альфа готовности, еще много чего хотелось бы добавить (иммитацию правильного времени исполнения, повторное использование уже запущенных vm, поднятие групп vm с определенными сетевыми настройками), но текущая реализация уже готова для проб. Код можно найти тут vm_ut.
Ссылки:
github.com/koder-ua/vm_ut
koder-ua.blogspot.com/2012/01/lxc.html
mirantis.com
github.com/ogirOK
github.com/anakriya
pypi.python.org/pypi/coverage
readthedocs.org/docs/nose/en/latest
Исходники этого и других постов со скриптами лежат тут — github.com/koder-ua. При использовании их, пожалуйста, ссылайтесь на koder-ua.blogspot.com.
Автор: konstantin danilov
