Как обновлять тестовые дубли в интегрированных тестах
Я новичок в разработке микросервисной архитектуры. После того, как узнал
- Тестирование микросервисов, Мартин Фолвер: https://martinfowler.com/articles/microservice-testing/
- Масштабируемая непрерывная интеграция: https://docs.google.com/presentation/d/1pBz_lQQZZiEXSZQJnYnRBoAcbN-wXUoYlwCpdzyPpB4/edit#slide=id.g3f5c82004_8646
Говорят, что терминологический интеграционный тест используется неправильно, поэтому для ясности я прошу «интегрированные тесты» или «совместный тест», обсуждаемые в этом блоге: https://blog.thecodewhisperer.com/permalink/integrated-tests-are- обман
Также я думаю, что это «интеграционный тест», описанный в письме Фаулера: https://martinfowler.com/bliki/IntegrationTest.html
В этих материалах я мог прочитать идею о том, что интегрированное тестирование не так хорошо, как должно быть, когда дело доходит до практики с точки зрения эффективности выполнения, точности обнаружения ошибок и т. Д. Тестовые двойники приходят на помощь в этих статьях, и это выглядит как идеальное решение для интеграционного тестирования.
Но я хочу знать, что: есть ли какой-либо инструмент / методология, гарантирующая, что тестовый двойник, созданный разработчиком компонента, всегда будет в курсе реальной внешней службы, с которой компонент будет взаимодействовать во время выполнения в производственной среде?
Поскольку мы можем создавать тесты контрактов, чтобы гарантировать, что наши предположения о внешних сервисах не нарушаются без уведомления, но обычно нет связи между предположением, которое мы применяли в тестах контрактов (сторона потребителя), и аналогом в интегрированных тестах.
Таким образом, чтобы иметь возможность обнаруживать несоответствие двух предположений, можно также сделать двойной тест, чтобы убедиться, что эти тесты действительны.