Комментарии 4
Спасибо за отличную статью!
Вопрос: а как вы поддерживаете актуальность моков в соответствии с контрактами внешних сервисов? Пока у вас интеграция с одним-двумя сервисами, вроде все легко, но когда число интеграций увеличивается - число моков, которые необходимо поддерживать растет в прогрессии.
И второй вопрос: ваша команда ходит в сервис N. И соседняя команда тоже использует сервис N. В данном случае каждая команда поддерживает моки самостоятельно, или есть какой-то механизм шеринга?
Спасибо за вопросы!
>как вы поддерживаете актуальность моков в соответствии с контрактами внешних сервисов?
Если коротко - руками. Да, количество моков, которые нужно поддерживать, и правда немаленькое, но любые изменения во взаимодействии с внешним сервисом отслеживаются, ставится задача на изменение контракта. А в рамках задачи на тестирование изменений QA в том числе правит моки - вечные для ручного тестирования и шаблоны заглушек для автотестов.
>ваша команда ходит в сервис N. И соседняя команда тоже использует сервис N. В данном случае каждая команда поддерживает моки самостоятельно, или есть какой-то механизм шеринга?
Каждая команда поддерживает моки самостоятельно.
Спасибо что делитесь знаниями.
Не очень понял как работает приоритизация моков. Вернее приблизительно понял на основе своих знаний как это может работать. Плюс в таблице вы пишите что у Scope = Countdown автоматическое удаление = "Да, каждую ночь". А в конце пишете что Scope = Countdown это одноразовые моки и они удаляются после использования.
Если Countdown мок живет сутки то он все равно может мешать другим запросам которым нужен мок Persistent, так?
А если он удаляется автоматически после первого запроса, то есть вероятность что другой автотест или тестировщик сделает запрос раньше чем придет запрос от автотеста который его создал и оба получат не то что ожидалось.
Не думали добавлять к запросам заголовок Scope по значению которого Mockingbird поймет какой мок использовать в конретном случае - Persistent, Countdown или Ephemeral?
Разным автотестам может потребоваться свой ответ с приоритетом Countdown и они могут быть запущены параллельно. Почему бы в фикстуре при запросе на создание мока не возвращать его ID, и не передавать этот ID в тест, который так же отправит его в заголовке и получит в ответ персональный мок?
Привет! На связи разработчик mockingbird
Скоупы были изначально задуманы для того, чтобы mockingbird мог одновременно обслуживать и happypath для каких-то демонстрационных контуров и моки для автоматизированных интеграционных тестов:
Persistent - дефолные моки, которых обслуживают happypath (но в принципе можно настроить и более сложное поведение, например, настроив предикаты для "волшебных" значений в каких-то полях)
Countdown - скоуп для автотестов, для них можно настроить количество срабатываний
Ephemeral - это "нечто среднее" и задумывался он для того, чтобы переопределить Persistent мок на время дебага, но потом не забыть удалить (мок удалится сам через сутки). Может звучит немного странно, но на практике - удобно.
Добавлять в Mockingbird какой-то специальный заголовок не нужно - желаемое вами поведение можно сконфигурировать предикатом в моке (конкретный мок может требовать специфический заголовок с определённым значением). А вообще если двум автотестам нужны разные моки, то это разруливается заданием "узких" правил их срабатывания, предикаты в mockingbird очень гибкие, а scope в этом плане вторичен
Mockingbird, или Как убить всех зайцев одним выстрелом