Учебный кейс: оплаченный заказ №42 отменяют через API. По правилам должен быть один возврат. Статус в orders стал CANCELLED. Но если смотреть только эту строку, можно пропустить второй возврат. Предположим, есть orders, order_history и refunds. На вашем проекте схема и правила будут другими. Поэтому сначала фиксируем ожидания, потом ищем подтверждения. До POST /orders/42/cancel сохраняю мини-снимок по order_id: статус и сумму, последнюю запись истории, количество и сумму возвратов. Иначе новую запись легко перепутать со старой. После запроса проверяю: 1. GET заказа и запись в БД согласованы с контрактом с учётом допустимой задержки. 2. В истории есть разрешённый переход ACTIVE → CANCELLED. Сумма и состав заказа не изменились без основания. 3. По правилу нашего примера появился ровно один возврат с нужной суммой и ссылкой на заказ. Если возврат асинхронный — отдельно смотрю промежуточное и итоговое состояния. 4. Повторная отмена не создала ещё один возврат. Код ответа на повтор беру из контракта, а не угадываю. Рабочий приём: для каждой связанной сущности записать «было → должно стать» и сравнить разницу. Здесь refunds: было 0, ожидаем +1. Если заказ неоплачен или возврат не предусмотрен, ожидание будет другим. Какую связанную запись вы чаще всего забывали проверить после API-запроса?