Почему мы уверены в том, что развернули

[tytar]

Я могу грубо ошибаться, но кажется дымовые тесты они же smoke testing это самый минимальный тест, если код не прошел, то дальше нет смысла его тестировать. А у Вас они описаны так, что обычно тестируют уже сами тестировщики.

[mukolaich]

Самый минимальный тест — это unit, набор всех юнит тестов (порядка нескольких тысяч) выполняется секунды. Дальше по времени выполнения идут интеграционные и системные (их тоже много), выполняются около минуты.

Смоки делятся на 2 категории: Тестирование сборки и Приемочные тесты. У нас это выглядит как последовательный автоматизированный набор тест-кейсов, которые проходят примерно 30 минут. Если все ок — дальше заходят manual QA и нажимают кнопочки, прорабатывая не автоматизированные кейсы.

Самые длинные — это регресионные тесты (порядка нескольких часов). Это детальное тестирование всего, что должно работать в принципе.

Такой подход позволяет нам быть уверенными в релизе, и деливерить максимально качественный продукт за минимальные сроки :)

[popstas]

Для меня тема тестирования ansible ролей и плейбуков сейчас очень интересна, поэтому задам пару вопросов:

1. Знаете ли вы репозитории, где можно посмотреть примеры адекватных тестов, без проверки того, что ansible уже проверяет?

2. Каким фреймворком пользуетесь вы для тестирования (kitchen, molecule, самописный)?

3. Используете ли вы тесты для проверки продакшена, или только на CI? Если используете, то запускаете ли вы тесты периодически (как healthcheck) или только сразу после разворачивания?

4. Чем из перечисленного тестируете вы? Мне по читаемости больше нравится goss, но мне почему-то кажется, что выживет testinfra.

[mukolaich]

1. На github.com есть отличные примеры открытый ролей, где проводится тестирование конечного результата. Следует понимать, что универсальных решений не существует, то что подходит всем — может не подходить вам. Именно поэтому и была написана статья — оцените, что должна делать Ваша роль или плейбук — и протестируйте результат.

2. У нас построен глубокий CI для написания Configuration management, и тулзы которые Вы указали — там есть.

3. Конечно используем, т.к. мы деплоимся достаточно часто, и декларируем хорошее качество — у нас каждую ночь проходят глубокие регресионные тесты, с кастомными интеграциями типа: упал тест -> создается тикет в Jira.

4. Для Ansible мы используем Testinfra, для Chef — Inspec.

[kharkevich]

https://molecule.readthedocs.io
Вполне достойный инструмент для проверки ansible ролей и плейбуков

[popstas]

Да, я им и пользуюсь, но подозрительно мало инфы о нем.

[kharkevich]

Документация, на мой взгляд, — ок.
Использование +- понятное.
Да и последний коммит был меньше суток назад — вполне живой проект.

[popstas]

Да, как пользователь я вижу, что проект живет. Если полазить по ишьюсам, то становится понятно, что metacloud сейчас активно пишут 2-ю версию molecule, там будут сценарии, которых мне сейчас не хватает.

[erthad]

После полугода экспериментов с тестами я пришел к такому выводу:

• юнитами тестируем подстановки/склейки переменных (в т.ч. в конфигах) и подобное
• юнитами тестируем всякие хелперы
• логику в рецептах лучше вообще не держать, но если все же есть, можно попробовать ее тоже юнитами протестировать
• интеграционными тестируем относящееся к описываемому сервису — состояние системного сервиса, наличие процессов в памяти, доступность портов, наличие и выполнимость команды (для всяких cli-штук)

И пара общих, но очень важных штук:

• Тестируем в изоляции. Если для теста кукбука X нужно настроить кукбук Y, это часто означает, что у вас ошибка компоновки.
• И самое главное, пожалуй: тестируем не все, а только важное