Тестирование распределённых систем

Проверяйте конечное состояние, а не тайминг: опрашивайте callback-endpoint или поле статуса с ограниченным таймаутом и back-off вместо фиксированного sleep. Прогоняйте каждую ветку осознанно — чистый файл, заражённый файл, который скан обязан отклонить, и принудительный сбой шага, чтобы сработал cron-повтор — и проверяйте payload webhook, письмо и идемпотентность при повторной доставке. Ловите callback stub-приёмником, чтобы результат был наблюдаем.

Верификация смещается с разовых ворот на живое сравнение: следите за частотой ошибок, задержкой и ключевой бизнес-метрикой новой версии против старого baseline, обслуживающего реальный трафик, а не только против фиксированного порога. Задайте триггер отката заранее — ограниченная регрессия по этим сигналам сама откатывает или сливает canary. Держите сравнение честным, разбивая когорты случайно и сопоставляя сопоставимый трафик, чтобы сдвиг метрики отражал код, а не перекошенную аудиторию или время суток.

Проверьте, что обработка идемпотентна: доставьте ту же ставку повторно и убедитесь, что итог не изменился — ни двойной ставки, ни двойного списания. Установите реальную гарантию порядка: очередь упорядочивает лишь в пределах partition или ключа, а не глобально, поэтому направьте ставки по одному лоту на один ключ и проверьте порядок в пределах лота, приняв, что несвязанные ставки чередуются. Подписывайте только когда дубли доказуемо поглощаются, а нужный продукту порядок совпадает с тем, что обеспечивает партиционирование.

Ни одна крайность. Спустите основную массу вниз: unit-тесты на сервис для логики, контрактные тесты на каждом стыке, чтобы каждая пара оставалась совместимой без развёртывания всего, и тонкий e2e-ярус лишь по критическим путям — реальное оформление, отклонённый платёж, отсутствующий на складе товар. Каждый уровень владеет своим классом отказов, а пирамида держит обратную связь быстрой. Оставьте e2e для тех немногих путей, где риск — именно межсервисное взаимодействие, а не логика одного сервиса.

Внедряйте режимы отказа осознанно — задержку, ошибки и полный отказ каждой зависимости, плюс убийство одного узла инвентаря посреди запроса. Проверяйте, что страница деградирует, а не ломается: при упавших рекомендациях она убирает этот блок и всё равно отрисовывает товар; когда сервис просто медленный, таймаут и fallback держат страницу в её бюджете, а не в подвисании. Для убийства узла убедитесь, что закоммиченная запись выживает, а запрос либо повторяется, либо чисто падает — без частичных или потерянных данных.

Контрактный тест на Pact фиксирует одну пару consumer–producer: consumer записывает ожидаемые запросы и ответы, producer их воспроизводит, и каждая сторона проверяется отдельно, без развёртывания обеих. End-to-end гоняет всю цепочку вживую — он ловит ошибки связки и потока данных, но медленный и flaky. Контрактные тесты указывают, какая сторона сломала контракт; e2e доказывает, что собранная система работает.

Сначала убедитесь, что запись долговечна, а не потеряна: прочитайте из primary, чтобы проверить, что она сохранилась, — это исключает потерю данных. Затем измерьте окно сходимости — за сколько все реплики и кэш начнут отдавать новое значение — и сравните с согласованной границей устаревания. Это ожидаемая согласованность в конечном счёте, если чтения сходятся в пределах границы; это баг, если окно превышает границу, устаревшее значение живёт дольше TTL кэша или значение не сходится вовсе.

Воспроизводите на нескольких клиентах, а не одном: сценарьте два и более сеанса, вставляйте переподключения и обрывы сети и чередуйте отправки, чтобы всплыли гонки. Проверяйте порядок в пределах одного отправителя, ровно однократный показ после переподключения и что каждый клиент сходится к одному финальному списку в ограниченном окне. Отделяйте настоящий баг — стойкое расхождение или потерю и перестановку сообщений после сходимости — от ожидаемого временного лага, пока состояние ещё устаканивается.

Тестируйте против sandbox вендора плюс контрактно-проверенного stub, а не прода: sandbox прогоняет реальное поведение протокола с тестовыми картами под каждый исход, а stub даёт детерминированный контроль над отклонениями, таймаутами и дублирующимися или пришедшими не по порядку webhook. Держите двойник верным контрактным тестом против вендора, чтобы он не разошёлся молча. Проверяйте расчёт, утверждая конечное состояние, к которому приходит ваш обработчик webhook — идемпотентно и независимо от порядка — никогда по фиксированному ожиданию.

Стык несёт контракт — имена и типы полей, сериализацию, коды статусов, таймауты, авторизацию и расхождение версий. Unit-тест подменяет вторую сторону заглушкой и лишь подтверждает вашу же догадку; интеграционный тест делает настоящий вызов и ловит момент, когда догадка неверна.