Как организовать интеграционные тесты в микросервисном приложении?

Question

[Владислав Копылов]

Есть микросервисное приложение с определенным зоопарком технологий (3 API-приложения, фронтенд для публичной части, фронтенд-админка).

Все API-приложения покрыты юнит и интеграционными тестами. Дали задачу по организации тестировании посредством UI-тестов в эмуляторе браузера на важные экраны приложений. Со стеками технологий тестирования остановился на комбинации WebdriverIO и Mocha. Покрыл тестами один экран.

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

• Дали задачу написать тесты на такой-то экран. Написал тесты, запустил их локально, убедился что все зеленые, сделал pull-request.
  
• Дали задачу по добавлению функционала на экран. Написал функционал, запустил готовые тесты на это экран, убедился что все зеленые, сделал pull-request.
  

Вопросы по порядку:

1. Окружение: при разработке фронта, фронт использует заготовленный API на удаленной машине. С ним удобно работать, так как там уже есть куча данных с которыми он может работать и манипулировать ими. При запуске тестов, хочется использовать отдельное окружение содержащее минимальный набор данных, которое бы после прохода тестов откатывалось в первоначальное состояние. Есть идея использовать для этого docker-контейнер, но хочется узнать как это организованно у других
   
2. Запуск тестов: у разработчика должна быть возможность комфортного запуска тестов, буквально одной командой в консоли. Поэтому хочется узнать где нужно хранить такие тесты (в репозитории с фронтом или в отдельном) и как правильно/удобнее развертывать окружение перед запуском?
   
3. Частота запуска и интеграция с CI: Как часто такого вида тесты (когда задействуется вся структура) должны запускаться? При каждом обновлении одного из репозиториев; при каждом обновлении репозитория с фронтом; перед релизом?
   

Answer 1

[Николай]

Делаете docker-compose файл, в котором поднимаете контейнеры со всеми нужными сервисами (DB, API,..., selenium/что угодно).
Делаете контейнер, который маунтит папку с тестами в себя и запускает их
Тогда тесты будут запускаться грубо говоря одной командой docker-compose up %название_сервиса%
В CI это можно запускать так же (по крайней мере в travis / jenkins)
Про хранение - логичнее всего держать это в отдельной репе, если фронт и разные API находятся в разных репозиториях, это же не тесты фронта.

Answer 2

[Stanislav Pugachev]

1) Ну можно поднимать Vagrant'ом виртуалку и туда все деплоить каким-нибудь ansible'ом
прогонять тесты и после этого удалять виртуалку
тут есть 2 преимущества: весь процесс деплоя описан в ансибл скриптах и он будет рабочим так как будет испльзоваться постоянно, и второй плюс - не нужно ничего откатывать, просто vagrant destroy.
с докером все тоже самое можно организовать
если по богатому - то виртуалки можно не локально запускать а где-то в клауде ( меньше геморроя будет, вагрант не нужен и тд)

2) я бы хранил в отдельной репе
потому что как показывает практика все равно под каждый более-менее большой проект все равно в итоге пилится свой собственный мини-фреймворк на селениуме(в вашем случае вебдрайвер). И я не говорю что это плохо.
Как результат - интеграционные тесты живут отдельно от остального проекта своей собственной жизнью
там зачастую задействованы девелоперы которые не касаются основного приложения в принципе никогда.

3) на каждый пул-реквест я бы такие тесты не гонял потому что как показывает практика опять же - они довольно тяжеловесные получаются и занимают прилично времени
есть же стандартные use-case scenarios - раз в день ночной билд, регрессия перед релизом, прогнать разок перед тем как собрались мержить фичу в мастер

вообще тут очень все субъективно
зависит от того как настроенны процессы у вас в кампании, как часто вы деплоите, насколько большое требуется покрытие и тд и тп