Шестой пост серии. После рефакторинга — архитектурный аудит текущего состояния кода. Новое правило в задаче агенту: каждое утверждение помечать «подтверждено файлом:строкой» либо «вывод без прогона». Разница с прошлым аудитом (GSD, второй пост серии) в одном: там уверенный вывод из имени файла было не отличить от проверенного факта. Здесь — обязали различать.

Сработало ровно так, как задумано: требование маркировки заставило агента лезть в jar’ы ~/.m2 и XML-отчёты тестов вместо того, чтобы опираться на память о прошлых этапах. И именно там нашлись две вещи поважнее самого архитектурного разбора.

Первая: цифра «130 тестов», которую я использовал во всех постах серии, — неверная. Реальных уникальных тестов — 94. 38% прогонов оказались дублями: в проекте всё это время жил забытый JUnit4-сюит — тот самый файл, который во втором посте серии GSD ошибочно назвал smoke-тестом на старте приложения. Он не просто был неправильно описан тогда — он всё это время тихо гонял шесть сервисных тестов повторно, раздувая счётчик, которым я сам гордился в предыдущих постах. Круг замкнулся на файле, с которого всё началось.

Вторая: миграция на Spring Boot 3 (четвёртый пост) оставила четыре поломки в прод-конфигурации, необнаруженные до сих пор. Причина методическая, а не халатность: тесты сознательно изолированы от прод-БД — это правильно само по себе. Но именно поэтому конфигурация, которую тесты подменяют, не покрыта вообще ничем. 100% зелёных тестов на миграции спокойно сосуществовали с четырьмя поломками ровно там, куда тесты просто не смотрят.

Обе находки — не про баги в коде, а про слепые зоны собственного процесса контроля. Правило «зелёный тест = всё работает» верно только для среза, который тесты действительно проверяют. Всё, что тесты сознательно обходят (а изоляция от прод-окружения — обычно осознанное и правильное решение), становится невидимым по конструкции, а не по недосмотру.

Вывод. Метрика «сколько у нас тестов» и статус CI — это не показатели здоровья продукта, а показатели того, что именно вы решили проверять. Стоит периодически спрашивать не «зелёный ли билд», а «что билд физически не может увидеть» — и это тот вопрос, на который у команды редко есть готовый ответ.