Comments 2
А что если users, orders и вот это всё всегда крутится в dev контуре и доступно...
Тогда получаем, что тестируем мы не наши моки, а существующую систему - здесь и сейчас, ту систему которая через 3-4 дня окажется на проде. Даже Кафки свои в dev контуре. И при этом не важно кто и что запускает: локально поправленный users и его работу с gateway в dev или тестировщик интеграционные тесты на реальном приложении в dev контуре... Все работают с одной системой, а не с разными замоканными представлениями о системе
Гладко было на бумаге, да забыли про овраги. Стоит добавить хоть одну операцию на запись или обновление, и вся стройная система правил рано или поздно превращается в макаронного монстра с золотой поддержкой, ничего не имеющего общего с полезным кодом. Вносим в контракты монотонно меняющие значения, такие так метки времени - и вся изоляция начинает требовать тонкую настройку системных часов, или лютых логик по конфигурации каждого теста.
В таких случаях, реальные дев стейджи, и продуманные административные интерфейсы куда как полезнее. Надо протестировать метку времени и идентификатор нового объекта - штатным интерфейсом потребителя все делаем, административным интерфейсом выгружаем - проверяем. И без регекспов в правилах сопоставления по образцу.
Пишем быстрые API-автотесты без флаков, стендов и боли: изоляционный подход в CI/CD