Не начинайте с просьбы «почини тесты»
Падение нескольких тестов может иметь одну причину. Сначала запустите конкретный тест локально и убедитесь, что он падал именно после последнего изменения. Сохраните команду запуска, версию зависимостей и первый информативный фрагмент ошибки. Если среда не воспроизводится, нейросеть будет угадывать. Не передавайте ей секреты из логов и снимки реальных пользовательских данных. В гайде по функции расчёта показано, почему тесты и граничные случаи важнее красивого рефакторинга.
Сопоставьте сбой с правкой
В учебном примере после смены округления цена заказа стала 1 199,99 вместо 1 200. Дайте модели функцию расчёта, diff и текст теста; попросите перечислить две-три проверяемые гипотезы с конкретной строкой кода. Хороший ответ объяснит, на каком шаге появляется дробная копейка и почему старое ожидание могло быть верным. Плохой предложит просто заменить ожидаемое число или отключить тест. Отдельно спросите, какие другие сценарии зависят от того же округления: скидка, возврат и налог могут проявить проблему иначе.
Проверьте минимальную правку
Исправьте одну причину, снова запустите упавший тест и ближайший набор. Если тест зелёный, добавьте пример на границе: нулевая сумма, половина копейки, несколько позиций. Не сливайте в один коммит изменение бизнес-правила, форматирование и обновление зависимостей. Так ревьюеру будет видно, что именно исправлено. Если ИИ предлагает обновить все снапшоты, сначала вручную посмотрите расхождения: массовая перезапись способна скрыть настоящую регрессию. Сравните поведение до и после на том же наборе данных: иначе зелёный результат может объясняться изменившейся средой, а не исправлением.
Похожая ловушка при импорте
Если тест стал падать после обновления входного файла, проверьте преобразование данных до изменения функции расчёта. В разборе отладки импорта показано, как отделить неисправность входа от ошибки логики.
Результат и вопросы
Финальный артефакт — небольшой патч, тест, объяснение причины и ссылка на задачу. Нейросеть здесь помогает сузить поиск, но решение принимает разработчик. <strong>Можно ли доверять объяснению стека?</strong> Только после воспроизведения. <strong>Когда менять сам тест?</strong> Если изменилось утверждённое требование, а не потому, что текущий код выдаёт другое число. <strong>Что делать с нестабильным тестом?</strong> Сначала отделите проблему времени, сети или случайного порядка от изменения логики.
Короткая проверка
- Понятны цель и человек, который примет результат.
- Исходники очищены, их версия и дата сохранены.
- Факты, числа и ограничения сверены вручную.
- Неудачный пример записан вместе с причиной.
- Есть измеримый следующий шаг и путь назад.