m
на сервере
Size: a a a
2020 March 13
m
вроде аксиос такое умел
IK
Я ж не против
IK
Я просто говорю что это не е2е :)
IK
Просто слишком часто вот такие условности приводят к всяким интересным вещам
IK
Потому что тесты по сути полагаются на проявления логики, которые есть на бэке
IK
И если бэк не имеет СТРОГО ТАКИХ ЖЕ тестов на эту логику, то ценность таких тестов многократно падает, вплоть до "нет смысла писать, есть смысл писать интеграционные тесты нижнего уровня"
m
вообще в этом есть конечно логика
m
потому что когда на ci запускается e2e тест в клиентском монорепозитории, он будет обращаться к внешнему api получается
m
которое еще могло не обновиться
m
и тогда не понятно как знать что бекенд обновился и можно на ci при сборке front-end запускать e2e тесты
m
И вообще как правильно тогда писать e2e тесты в случае микросервисной архитектуры? Каждый микросервис мокать?
IK
m^^combat
И вообще как правильно тогда писать e2e тесты в случае микросервисной архитектуры? Каждый микросервис мокать?
Нет, разворачивать всю архитектуру
IK
На то они и е2е
m
а как разворачивать всю архитектуру если фронтэнд и бэкэнд в разных репозиториях?
m
вопрос конечно о CI
IK
Брать и разворачивать
m
У вас какие-то очень странные вопросы.
Брать и разворачивать. Готовить контейнеры с дев окружением, писать миграции на бд, рулить этим делом через энв переменные
Брать и разворачивать. Готовить контейнеры с дев окружением, писать миграции на бд, рулить этим делом через энв переменные
IK
Джоба не привязана ж к одному репозиторию
IK
У всех ci есть куча механизмов для этого