Биллингу нельзя доверять тесты в общем контуре: как изолировать окружения и сымитировать сбой шлюза

Биллингу нельзя доверять тесты в общем контуре: как изолировать окружения и сымитировать сбой шлюза

Биллинг ломается не на «красивых» сценариях, а на пограничных: дубль webhooks, таймаут на авторизации, частичный успех и повторная доставка события. Поэтому тестовый контур должен быть изолирован по данным, ключам и очередям: отдельные merchant_id, отдельные idempotency-keys, отдельные базы для ledger и event log.

Для внешних шлюзов нужен не мок «успех/ошибка», а управляемая симуляция отказов:
— задержка ответа до истечения таймаута;
— ответ 500 после списания на стороне шлюза;
— потеря callback при уже подтвержденной операции;
— повторная доставка одного и того же события;
— рассинхрон статуса между API и webhook.

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

Хорошая схема теста — матрица «событие × сбой × повтор»: кто источник истины, где хранится correlation_id, какой шаг считается финальным. Если этого нет, любой «успешный прогон» в тесте ничего не говорит о revenue leakage в проде.

Надежный биллинг проверяют не по happy path, а по тому, как он ведет себя при сетевом сплите, ретраях и несогласованности статусов.