Могут ли LLM находить flaky-тесты по коду? Исследование говорит нет

Flaky-тесты — это тесты, которые иногда падают, иногда проходят, без видимой причины. Они ломают CI/CD, заставляют переделывать работу и подрывают доверие к автотестам. Исследователи решили поручить эту проблему LLM: может, нейросеть разберётся в коде и найдёт подозрительные тесты? Результаты разочаровали.

Почему flaky-тесты враг хуже Ненадёжный тест — это не просто баг.

Когда тест падает в случайные моменты, инженеры перестают ему верить. Переделывают работу, перезапускают пайплайн, тратят часы на отладку. Классический баг можно воспроизвести, flaky-тест воспроизводится только в понедельник в 3:43 утра.

Это убивает скорость разработки. Источники flaky-тестов разнообразны и часто скрыты: Race conditions и timing issues Зависимости от состояния БД или файловой системы Плохо изолированные тесты, влияющие друг на друга Асинхронный код без правильных waits * Жёсткие таймауты, которые не переносят перегруз сервера ## Как исследователи проверяли LLM Команда взяла несколько LLM и спросила простую вещь: вот код теста, он flaky? Модели смотрели на исходный код, пытались узнать паттерны (retry-логика, sleep, слабую изоляцию), и выдавали вероятность проблемы.

На контролируемом датасете результаты выглядели отлично: модели достигали 85%+ точности. Precision и recall были хорошие, графики выглядели как обычно в успешных ML-проектах. Казалось, проблема решена.

Но вот парадокс: когда исследователи применили те же модели к реальным тестам из других проектов, эффект почти испарился. Точность упала, false positives выросли. Модель явно не поняла природу flaky-поведения.

Почему метрики не равны пониманию

Это классическая ловушка machine learning, которую забывают между чтением статей о новых моделях и реальной работой. Модель может выучить корреляции в датасете, но это не значит, что она поняла причину. Например, если в тренировочном датасете все flaky-тесты содержали `Thread.sleep()`, модель отметит любой тест с этой функцией как подозрительный — даже если sleep там правильно использован для синхронизации. Для flaky-тестов проблема острая: каждый проект имеет свои паттерны нарушений. То, что ломается в микросервисной архитектуре, может быть совершенно нормально в однопоточном приложении. Модели обучались на одном срезе данных и не видят контекста среды, версий фреймворков, особенностей инфраструктуры.

Хорошие метрики на тестовом сете — это необходимое, но не достаточное условие.

Нужна реальная валидация на боевых примерах.

Что это значит LLM — мощный инструмент, но он не волшебство.

Для специализированных проблем вроде поиска flaky-тестов нужно либо больше контекста (история падений, метаинформация об окружении, информация о нагрузке), либо гибридный подход (LLM + статический анализ + мониторинг падений в боевых условиях). Мораль простая: не полагайтесь только на метрики. Специфичные задачи требуют специфичного подхода.