Тестирование API и интеграций

На проекте поставщик HTTP-API меняется независимо от потребителя. Какой тест быстрее всего выявит несовместимое изменение формата ответа до выката поставщика?

Какой дефект не обнаружит тест API, если внешняя система полностью заменена моком?

Интеграционный тест проходит отдельно, но падает в общем прогоне из-за общего тестового пользователя. Какой принцип подготовки данных устранит зависимость от порядка запуска?

Сервис повторяет HTTP-запрос после тайм-аута. Какой контракт должен защитить операцию от двойного эффекта?

Практическая ситуация: сервис записывает заказ в базу данных и публикует событие для другого сервиса. При сбое между этими действиями заказ сохраняется, но событие теряется. Какой механизм устранит этот разрыв?

начать транзакцию базы данных
заказ = сохранить_заказ(данные)
зафиксировать транзакцию
опубликовать("ЗаказСоздан", заказ.id)

Потребитель иногда получает событие «ЗаказОплачен» раньше «ЗаказСоздан». Какой контракт события позволит тестом выявить нарушение порядка?

Тест HTTP-клиента проверяет только путь запроса, а мок отвечает на любой HTTP-метод и тело. Какой дефект такая настройка способна скрыть?

Тест вебхука проверяет подпись после разбора и повторной сериализации JSON. Какой дефект такая проверка может скрыть?

При частичном обновлении ресурса клиент различает отсутствие поля и значение null. Какой контрактный инвариант должен сохранить сервер?

Событие публикуется независимо от версии потребителя: продюсер добавил обязательное поле, после чего старый потребитель перестал его обрабатывать. Какой инвариант совместимости должен проверять интеграционный тест?

Практическая ситуация: HTTP-команда запускает асинхронную обработку, а результат становится доступен позже. Как построить интеграционную проверку, чтобы она не зависела от фиксированной задержки?

Практическая ситуация: два клиента читают один ресурс, затем один из них сохраняет изменения раньше другого. Какой HTTP-контракт должен предотвратить перезапись более свежих данных вторым клиентом?

GET /accounts/42 HTTP/1.1

HTTP/1.1 200 OK
ETag: "v7"

PATCH /accounts/42 HTTP/1.1
If-Match: "v7"

HTTP/1.1 412 Precondition Failed

Объясните, как контракт HTTP должен описывать даты-время, чтобы интеграционный тест выявлял расхождение часовых поясов между клиентом и сервером.

Сервис возвращает HTTP 200 с признаком ошибки в теле вместо ожидаемого 4xx. Как интеграционный тест должен выявить нарушение контракта?

При постраничном чтении списка между запросами появляются новые записи. Какой контракт пагинации должен проверить интеграционный тест, чтобы клиент не пропускал элементы и не получал дубли?

Ночью интеграционный тест проверки срока действия токена иногда падает из-за перехода через полночь. Как сделать такую проверку детерминированной?

Сервис-потребитель получил одно событие дважды. Какой контракт события позволит отличить повторную доставку от двух разных событий?

Что останется незамеченным, если HTTP-клиент в интеграционном тесте автоматически следует редиректам, а API неожиданно начинает перенаправлять запрос на другой URL?

Клиент отправляет JSON-тело с неподдерживаемым значением Content-Type, но интеграционный тест проверяет только структуру тела. Какой дефект HTTP-контракта останется незамеченным?

Сервис поддерживает условный GET, а клиент уже сохранил представление ресурса. Какой основной контракт должен проверить интеграционный тест при отсутствии изменений ресурса?

GET /profiles/42 HTTP/1.1
If-None-Match: "v7"

HTTP/1.1 304 Not Modified
ETag: "v7"