Тести в CI та розбір падінь

Тести в CI — стандартизований доказ

Локальні тести дають швидкий feedback, а CI повторює ключові припущення у чистому стандартизованому середовищі. Типовий backend job може поєднати unit або service tests, integration/API checks, build JAR і smoke health endpoint.

Назви задач і потреба в тестових сервісах залежать від проєкту. Важливо, щоб workflow використовував ті самі базові команди, що й README та локальна розробка.

Як читати червоний job

1. Знайдіть step, який завершився помилкою.
2. Відшукайте перше змістовне повідомлення про збій.
3. Відокремте первинну помилку від каскадних повідомлень.
4. Зіставте failure зі зміненими файлами та конфігурацією job.
5. Повторіть тільки повʼязаний job після мінімального виправлення.

Класифікація failure

Падіння тесту не доводить автоматично, що зламано продукт. Можливо, функціональність змінилася свідомо й застарів тест. Порівнюйте assertion із бізнес-правилом і evidence з логу.

Claude як діагност, а не автоматичний ремонтник

1. Передайте лише релевантний лог і список змінених файлів.
2. Попросіть відрізнити symptom, hypothesis і підтверджений факт.
3. Перевірте гіпотезу локально або повторним вузьким job.
4. Зробіть мінімальний fix після підтвердження.
5. Не приймайте AI-висновок без первинного доказу.

Input: failing job log and changed-file list
Return:
- failure category
- probable root cause
- evidence from the log
- smallest verification command
- next action
Do not edit files, disable tests, or hide the failure.

Flaky-тести, rerun і evidence

Один успішний rerun не доводить, що проблема зникла. Він лише показує, що тест може проходити нестабільно. Зафіксуйте частоту, умови, логи та свідоме рішення щодо ізоляції або виправлення.

Тимчасове вимкнення тесту робить pipeline зеленим, але прибирає сигнал регресії. Замість цього відокремте code, test, environment, dependency, flaky або infrastructure причину.