Тест ожидает одно уведомление, а получает два. Запрос «сделай сборку зелёной» допускает слишком много результатов: исправить повторную отправку, изменить ожидание, пропустить проверку. Цвет сборки одинаковый, последствия разные.
Возьмём учебный пример приложения с уведомлениями о смене статуса задачи. Причина падения пока неизвестна. В этой ситуации полезно ограничить способы изменения проверки, но опасно заранее объявить тест неприкосновенным: неверным может оказаться и его ожидание.
Сначала назовите условие, которое нельзя потерять
Ограничение должно защищать понятное поведение. Например: одно изменение статуса не должно создавать две независимые заявки на отправку одному получателю. Это ещё не обещание ровно одной доставки письма при любых сбоях транспорта. Границу между постановкой в очередь и фактической доставкой придётся проверить отдельно.
Теперь понятно, зачем запрещать случайный пропуск теста: он скроет нарушение выбранного условия. Сам по себе запрет «не трогай тесты» этого не объясняет и помешает исправлению неверной тестовой подготовки.
Разберись, почему тест получает две заявки на отправку вместо одной.
Пока не меняй ожидание и не отключай проверку.
Покажи действие, которое запускает каждую отправку, и место в коде.
Проверь, не создаёт ли повторное событие сам тест.
Если ожидание противоречит согласованному поведению, объясни расхождение.
После подтверждения причины предложи минимальное исправление.Перечисляйте обходы, относящиеся к этой задаче
Здесь уместно попросить не добавлять пропуск теста, не ослаблять проверку количества и не скрывать исключение ради успешного запуска. А запрет менять любой таймаут во всём проекте уже не связан с наблюдаемым дефектом.
Слишком общий список увеличивает вероятность противоречия. Например, «не меняй поведение» плохо сочетается с задачей исправить неправильную отправку. Лучше указать, какое поведение сохраняется: набор получателей, формат письма, права доступа. Ошибочную повторную постановку, наоборот, нужно изменить.
Известные риски можно назвать до первой ошибки агента. Не требуется ждать третьего повторения, чтобы запретить разрушительную команду на рабочей БД. Но список должен обновляться вместе с задачей: старое ограничение из другого модуля не становится полезным от копирования.
Текстовое требование не заменяет ограничение доступа
Фраза «не записывай файлы» задаёт ожидание от работы, но сама по себе не блокирует запись. Если исследование должно быть технически отделено от изменения, нужен режим или окружение, в котором запись действительно недоступна. Возможность и границы такого режима зависят от используемого инструмента.
Учитывайте все доступные каналы. Запрет отдельного редактора файлов не означает запрет записи, если исполнитель может вызвать командную оболочку с теми же правами. Аналогично локальное окно инструмента не доказывает, что данные обрабатываются только на вашем компьютере.
Для учебного примера достаточно отдельной рабочей копии без доступа к production и без настоящих ключей почтового сервиса. Для рабочего проекта границы определяются действующими правилами команды. Не выдавайте агенту дополнительные полномочия только для того, чтобы исчезли запросы разрешения.
Дайте способ пересмотреть правило
Предположим, выяснилось: тест дважды вызывает обработчик, а приложение создаёт одну заявку на каждый вызов. Теперь вопрос состоит в том, обязано ли повторное событие подавляться. Если такой гарантии нет, простая замена ожидаемой единицы на двойку всё равно преждевременна — сначала надо согласовать смысл проверки.
Полезный ответ агента содержит конкретный выбор: сохранить проверку повторного события и добавить защиту либо исправить подготовку теста, если сценарий задумывался как однократный вызов. Человек выбирает требование. После этого исполнитель может продолжить реализацию без нового подтверждения каждой строки.
Если ограничение мешает обоснованному исправлению:
— назови конкретное правило;
— покажи противоречие с требуемым поведением;
— предложи изменение границы и проверку последствий.
Не обходи правило молча и не останавливай несвязанную разрешённую работу.Проверьте результат ограничения
В итоговом diff важно увидеть не только исправленный обработчик, но и изменения тестовой конфигурации. Если проверка исчезла из набора или начала сравнивать другое условие, успешная команда потеряла первоначальный смысл.
Попросите указать, какая проверка обнаружит возврат дефекта. Для нашего случая это сценарий, который воспроизводит именно источник второй заявки, а не тест существования страницы. Затем разберите оставшийся риск: фоновые повторы и сбои доставки могут требовать отдельной задачи.
Хорошее ограничение можно объяснить без слов «так надёжнее»: оно защищает определённое свойство, допускает проверяемое исключение и имеет техническую границу там, где одной договорённости недостаточно.
