Bugfix-loop: від відтворення до regression evidence

Зникнення помилки саме по собі не доводить, що дефект усунуто. AI може перехопити виняток надто широко або приховати симптом. Надійний fix спирається на встановлену першопричину, regression test і фактичні результати перевірок.

  1. Відтворіть дефект і зафіксуйте точний input та результат.
  2. Опишіть root cause, а не лише зовнішній симптом.
  3. Створіть regression test, який падає на старому коді.
  4. Внесіть мінімальну зміну в причину дефекту.
  5. Запустіть targeted checks.
  6. Перевірте сусідню функціональність.
  7. Перегляньте diff вручну.
  8. Збережіть regression evidence у PR або EVIDENCE_LOG.md.

Червоний до fix, зелений після fix

Тест, написаний лише після виправлення, не доводить, що він виявляв початковий баг. Сильніший доказ — один і той самий сценарій, який падає на старому коді з фактичним 500, а після мінімальної зміни проходить з погодженим 400.

На HTTP-рівні regression test має перевіряти HTTP-статус і відповідне тіло відповіді, а не лише внутрішній exception у сервісі.

Структура regression evidence
Before fix: empty-cart test failed; actual status 500
Root cause: empty input reached unsafe total calculation
After fix: the same test passes; expected status 400
Adjacent checks: valid order remains successful
Diff review: only approved files changed

Мінімальний fix не переробляє весь модуль

  • Не змінюйте інші endpointʼи без окремої вимоги.
  • Не створюйте загальну систему validation лише для локального бага.
  • Не додавайте залежності без потреби.
  • Не перейменовуйте DTO та не перебудовуйте checkout architecture паралельно.
  • Не виправляйте неповʼязані проблеми в тому самому diff.

Що записати в regression evidence

ДоказНавіщо він потрібен
Назва тесту до fixПоказує, що сценарій справді виявляв дефект
Стара відповідьФіксує фактичний початковий симптом
Результат після fixПідтверджує очікувану нову поведінку
Суміжні тестиПоказують відсутність очевидної регресії
Ручний сценарійПідтверджує відтворюваний endpoint або команду
Змінені файли та root causeЗʼєднують доказ із конкретною зміною

Роль Claude в bugfix-loop

  1. Попросіть створити regression test без змін production-коду.
  2. Перевірте, що тест падає на старому коді.
  3. Попросіть мінімальний fix у межах approved scope.
  4. Запустіть targeted і суміжні перевірки.
  5. Попросіть скласти перелік фактично підтверджених результатів.
  6. Звірте кожне твердження з diff і виводом команд.

Канонічне джерело уроку · JavaRush

Відкрити матеріал JavaRush