Функционал

Часто в разговоре люди упоминаю Функционал в разрезе функциональных требований/ возможностей системы. Это неправильно.

Оставлю эту ссылку здесь.

pytest BVT часть 2

Как и обещал продолжаю цикл статей про pytest и создание фреймворка для организации BVT.

В прошлой части немного разобрались с терминологией, в этой же более детально опишем, что же будем разрабатывать.

BVT - это базовый набор тестов, который проверяет самое основное, очень часто в это набор уносят тесты, которые проверяют, что называется, целостность сборки. Что будет входить в наш тестовый фреймворк:

1. Проверка наличия файлов. Удобно для проверки бинарных файлов, логов, конфигов, раскиданных по ФС и т.д. и т.п.
2. Запрос версии. У каждого исполняемого файла обязательно должна быть версия или подпись. Почему версия удобна и необходима думаю не нужно говорить.
3. Проверка опций в конфигурационных файлах. Эти проверки избавят от проблем протечки в продакшн конфигов с включенным дебагом. 
4. Статусы запущенных/зарегистрированных сервисов.
5. Проверка статусов запущенных программ.
6. Открытые порты.
7. Проверка ответов на http запросы. Бывает в сервисы встраивают возможность проверки состояния сервисов (а-ля /healthcheck, /check). Удобно проверить и данную функциональность.

На Линуксе подобные проверки легко решаются использованием bash, на github есть замечательный проект https://github.com/sstephenson/bats, который представляет эту возможность из коробки.

Т.к. нашей целью является изучение pytest, то в качестве основы предлагаю взять таверн https://github.com/taverntesting/tavern. Чем он хорош с точки зрения донорского проекта?

1. Декларативный конфиг на yaml. Сама по себе декларация очень удобна, она позволит разделить понятия тестового движка и тестов. Соответственно один человек будет заниматься написанием кода, а другой за наполнение тесового плана. Плюс yaml гораздо удобнее и проще относительно json, xml.
2. Написан на pytest. Можно брать много годных идей, например, cli для прогона тестов.
3. Для фреймворка написаны свои тесты. Да,да, именно тесты. Фреймворки имеют тенденцию с годами расширяться и усложняться, соответственно нужны регрессионные автотесты.
4. Ну и куча других плюше - настроенный gitlab-ci, requirements, документация и т.п.

В следующей части набросаем скелет фреймворка и напишем на нем "hello world".