Приведите пример улучшения процессов тестирования в команде

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

Инициативу и то, как вы обращаетесь с тестами в Go на практике. Интервьюер хочет услышать боль, решение и способ убедиться, что стало лучше, а не пересказ курса про пирамиду тестирования.

Как отвечать

Возьмите одну конкретную боль и разверните её. Что обычно рассказывают про Go-проекты:

• десятки почти одинаковых тестов свели в табличные с подтестами t.Run, добавление кейса стало строкой в слайсе;
• в CI включили go test -race ./..., и гонки стали видны до прода, а не в виде плавающего инцидента;
• заменили ручные заглушки на httptest.Server и интерфейсы вместо конкретных клиентов, тесты перестали ходить в сеть;
• медленные тесты с базой вынесли за build tag, быстрый прогон вернулся в секунды;
• прибили нестабильные тесты: убрали time.Sleep из ожиданий, закрыли ресурсы через t.Cleanup, дали каждому тесту свою схему в базе.

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

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

Делают целью покрытие. Цифру в Go легко накрутить тестами на конструкторы и геттеры, а сложная ветка с ошибкой так и останется непроверенной. Покрытие полезно как подсказка, где смотреть, а не как план.

Молчат про нестабильные прогоны. Плавающее красное убивает доверие быстрее, чем отсутствие тестов: команда привыкает перезапускать и перестаёт читать отчёт. Разбор причин тут ценится выше рассказа про количество тестов.

Приносят цифры вроде «ускорили тестирование вдвое», взятые из воздуха. Уточняющий вопрос о том, что и чем замеряли, закрывает тему. Лучше честно сказать, что смотрели по времени прогона в CI.