Что делали с упавшими тестами из-за ошибок

Что проверяют

Отношение к красному прогону. Водораздел простой: человек ищет причину или гасит симптом перезапуском и пометкой skip. Заодно смотрят, умеете ли вы отличать сломанный код от устаревшего теста и от нестабильного теста, который врёт в обе стороны.

Как отвечать

Опишите разбор по шагам, на примере из своей практики:

• воспроизвести: pytest --lf -x, тот же порядок и тот же seed, при подозрении на зависимость от порядка запуск в обратном;
• классифицировать падение: сломался код, устарел тест, испортилось окружение или данные, тест нестабильный;
• если падает только в CI: собрать артефакты, поднять подробность вывода через -vv и полный трейс, сравнить версии зависимостей и переменные окружения;
• чинить причину нестабильности: время фиксировать (freezegun), сеть подменять (responses, respx), состояние изолировать фикстурами с откатом транзакции, внешние сервисы поднимать контейнерами;
• не прятать молча: если чинить прямо сейчас нельзя, тест помечается xfail со ссылкой на заведённый тикет, а не выключается навсегда;
• красная основная ветка блокирует мерж: откат ломающего коммита быстрее, чем починка на ходу.

Где спотыкаются

Ставят автоматический перезапуск упавших тестов на весь проект и считают вопрос закрытым. Ретраи прячут настоящую гонку в коде, и тот же дефект однажды приезжает на прод, где перезапуска не будет.

Правят тест под новое поведение кода, не разобравшись, кто из двоих прав. Тест, подогнанный под фактический вывод, перестаёт быть проверкой и просто фиксирует текущее состояние, включая баг.

Отвечают процентами вместо разбора: «доля успешных прогонов выросла на тридцать процентов». Первый же уточняющий вопрос о причине падений оставляет кандидата ни с чем. Гораздо сильнее звучит один разобранный случай: тест падал через раз из-за datetime.now() на границе суток.