Нестабильные тесты

Что это за сервис

Дашборд нестабильных тестов для разработчиков, платформенной команды и тимлидов. Нестабильный тест падает случайно: на одном и том же коммите он то проходит, то нет. Дашборд считает долю таких падений по каждому тесту, отправляет худшие в карантин с владельцем и сроком и показывает, сколько времени команда теряет на перезапусках.

Без него инженеры по несколько раз в день перезапускают пайплайн из-за одного-двух случайно падающих тестов и ждут по сорок минут. Никто не отличает нестабильный тест от реально сломанного, и настоящие поломки прячутся за «просто перезапусти». Интеграционный тест неделями стоит сломанным, потому что ни одна команда не считает его своим. Со временем команда перестаёт доверять тестам и добавляет ручные проверки перед выкаткой.

Что он делает

Хранит историю прогонов. Каждый результат теста записывается с коммитом, веткой, числом попыток и итогом, поэтому доля случайных падений считается автоматически.
Отличает нестабильный тест от сломанного. Тест, который на одном коммите и проходил, и падал, считается нестабильным; стабильно падающий — сломанным.
Отправляет в карантин. Тест выше порога нестабильности помечается или переводится в карантин: он продолжает выполняться, но его падения не блокируют несвязанные изменения.
Назначает владельца. Каждый набор тестов закреплён за командой, нестабильные тесты попадают в её очередь.
Показывает тренд и потери. Графики по наборам и сервисам показывают, улучшается ли ситуация, и сколько деплоев задержали случайные падения.

Нюансы и особенности

Дашборд CI не заменяется. CI показывает, прошла ли текущая сборка. Этот дашборд отвечает на другой вопрос: почему сборки падают время от времени и кто должен это чинить. Многие CI уже умеют находить нестабильные тесты, например встроенная аналитика в GitLab, CircleCI или Buildkite Test Engine. Если её хватает, отдельное приложение не нужно; своё оправдано, когда пайплайнов несколько и нужен общий список с владельцами.
Окно расчёта важно. Долю считают за скользящие 30 дней: исправление быстро отражается в цифрах, а история не теряется. Порог попадания в карантин, например 10%, задают в настройках.
Карантин не должен становиться вечным. У карантина есть срок, например 14 дней. После него тест эскалируется руководителю команды-владельца, а не остаётся отключённым навсегда.
Считают все уровни. Модульные и интеграционные тесты тоже бывают нестабильными и тратят время пайплайна, поэтому их учитывают наравне со сквозными.
Без владельца — блокирующее предупреждение. Нестабильный тест без команды выводится отдельно и обсуждается на планёрке, иначе его никто не возьмёт.
Данные из отчётов CI. Результаты приходят в JUnit XML или JSON после каждого прогона; повторная загрузка того же прогона не создаёт дублей.
Перезапуск — тоже данные. Если CI делает автоповтор, записывайте все попытки, а не только финальный результат: иначе нестабильность становится невидимой.

Как сгенерировать через ИИ-агентов

Промпты рассчитаны на AI-агента (Claude Code, Cursor и аналоги) в Laravel-проекте с установленным Filament 4.x. Отправляйте их по одному и проверяйте результат каждого шага.

1. Данные и модели

Создай модели и миграции для учёта нестабильных тестов: Team (название,
руководитель), TestSuite (название, сервис, уровень: модульный,
интеграционный, сквозной; команда), TestCase (набор, имя, статус: активен,
нестабилен, в карантине; дата попадания в карантин, текущая доля
нестабильности), TestResult (тест, прогон, коммит, ветка, попытка, итог,
длительность), PipelineRun (внешний id, коммит, время ожидания, задержан
ли деплой). Добавь фабрики с реалистичными случайными падениями.

2. Приём результатов

Добавь эндпоинт для загрузки отчётов JUnit XML с проверкой токена.
Сохраняй прогон идемпотентно по внешнему id и записывай все попытки
каждого теста, а не только итоговую. Прогон с тем же коммитом и разными
итогами одного теста отмечай как случайное падение.

Проверьте на демо-данных, что тест, который стабильно падает, не считается нестабильным.

3. Расчёт и карантин

Сделай задачу по расписанию, которая считает долю нестабильности каждого
теста за скользящие 30 дней и переводит тесты выше порога из настроек
в «в карантине» с датой. Тесты в карантине дольше 14 дней уведомляют
руководителя команды-владельца. Тест выходит из карантина вручную
или после 30 дней без случайных падений.

4. Таблица и очередь команды

Сгенерируй Filament-ресурс для TestCase. В таблице покажи набор, уровень,
команду, долю нестабильности, статус и дни в карантине; фильтры
по команде, уровню, статусу и «Без владельца». В карточке выведи историю
результатов по коммитам. Добавь действие «Вернуть из карантина»
с обязательным комментарием.

5. Роли и тренды

Настрой роли: команда меняет статус своих тестов, платформенная команда —
всех, остальные видят только чтение. Добавь виджеты: тренд доли
нестабильности по неделям по сервисам, число задержанных деплоев
и суммарное время ожидания из-за перезапусков за месяц.