Тесты в CI: гонки, покрытие и Testify

Ядро go тесты ci — одна команда: go test -race -coverprofile=coverage.out ./... Троеточие берёт все пакеты модуля, а не только тот, что меняли, -race включает детектор гонок, -coverprofile пишет профиль покрытия в файл. Про -race честно: детектор не бесплатный — по документации память может расти в пять-десять раз, время исполнения в два-двадцать. Для юнит-тестов это копейки, и они дешевле ночной гонки в проде: детектор ловит конкурентный доступ к памяти, который горутины устраивают молча, а механика этих горутин — отдельный урок в go-advanced. Провал любого теста — ненулевой код выхода: именно на него смотрит CI, всё остальное — раскраска лога.

Профиль покрытия считает операторы: какая доля строк исполнилась под тестами. go tool cover -func=coverage.out печатает процент по каждой функции и итог, -html рисует карту файла, где зелёное исполнялось, а серое — нет. Теперь честно о цифрах: сто процентов не цель. Покрытие говорит «строка исполнилась», но не «результат проверен»: можно вызвать функцию и не сравнить ничего — процент вырастет, качество нет. Осмысленная цель — держать высоким критичный путь: деньги, доступы, парсинг внешних данных, ветки ошибок. Вспомогательная обвязка и типовые геттеры в процентах не нуждаются. Смотреть на total и радоваться — самообман; смотреть, какие именно строки остались серыми, — работа на десять минут, которая находит мёртвые ветки быстрее любого ревью.

Testify в CI не нужен отдельный мост. Провал ассерта — это t.Errorf внутри: тест помечается проваленным, go test печатает FAIL: TestXxx с вашим diff, а на выходе процесс уходит с ненулевым кодом. assert после провала тест не прерывает: остальные проверки кейса отработают, и в отчёте соберутся все провалы разом — иногда это экономит итерацию отладки. require рвёт тест на первом провале — правило выбора разобрано в уроке про assert и require. А будет ли в логе CI понятная строка или загадочное not equal, решают сообщения — стиль msgAndArgs отрабатывали в уроке про сообщения. CI видит всё это без спецобработки: FAIL и код выхода — стандартная реакция testing, testify просто наполняет её содержимым.

go test кэширует результаты: если пакет и его зависимости не менялись, повторный прогон печатает ok (cached) и не исполняет ничего. У себя на машине это скорость; в пайплайне с прогретым кэшем сборщика — риск взять старое зелёное. Флаг -count=1 отключает кэш: каждая попытка честно исполняется, а -count=5 запустит тест пять раз подряд — быстрый способ вылова flaky без всего пайплайна. Для длинных тестов есть вилка testing.Short: внутри теста if testing.Short() { t.Skip(...) }, а короткий прогон с -short идёт на каждый коммит, полный — по расписанию или перед релизом. И тонкость про testify: медленный тест со sleep кэш не волнует — он останется медленным в любом профиле, и лечить его надо не флагами, а ожиданием факта.

Flaky-тест краснеет без причины и зеленеет при повторе. Первое желание — retries: перезапускать красный до зелёного и наслаждаться тишиной. Это затычка: ретрай не чинит причину, а прячет — под шум проползает настоящий баг, у которого тоже «иногда краснеет». Честный путь — убрать недетерминизм: sleep перед проверкой горутины заменить на ожидание факта через Eventually — механика в уроке про Eventually, — общий срез в параллельных сабтестах на канал или мьютекс, как в уроке про мьютексы, зависимость от сети — на заглушку. Ретрай допустим как временная мера с тикетом и датой сноса. Правило простое: зелёный со второго раза — это красный, который вам пока повезло не увидеть.