Ответ
Главное — понимать, что покрытие тестами (code coverage) — это полезная метрика, но не самоцель. Высокий процент покрытия не гарантирует отсутствие багов, а лишь показывает, какая часть кода была выполнена во время тестов.
Наш подход строится на нескольких принципах:
-
Дифференцированные цели. Мы не гонимся за одинаковым процентом для всего проекта:
- Критически важная бизнес-логика, пакеты с алгоритмами: стремимся к 85-90%+.
- Стандартный код (контроллеры, CRUD): достаточно 70-80%.
- Код, который сложно тестировать (например, интеграции с UI): покрываем юнит-тестами по возможности, основной упор делаем на ручное или E2E-тестирование.
-
Качество важнее количества. Один тест на пограничный случай (edge case) или обработку ошибки ценнее десяти тестов, проверяющих "счастливый путь" (happy path).
-
Автоматизация в CI/CD. Проверка покрытия встроена в наш CI-пайплайн. Пул-реквест не может быть смержен, если покрытие нового или измененного кода падает ниже установленного порога (например, 80%).
# Пример команды для проверки покрытия go test -coverprofile=coverage.out ./... go tool cover -func=coverage.out # Вывод может выглядеть так: # ok project/pkg/utils 0.002s coverage: 85.2% of statements -
Прагматичный подход к легаси. Мы не ставим задачу покрыть тестами весь старый код сразу. Но любое изменение или исправление бага в легаси-коде обязательно сопровождается написанием тестов для затрагиваемой логики.
Важное дополнение
Мы не стремимся к 100% покрытию, так как это часто экономически нецелесообразно (закон убывающей отдачи). Гораздо важнее иметь осмысленные интеграционные и E2E тесты, которые проверяют работу системы в целом, даже если они не влияют на метрику покрытия unit-тестами.
Ответ 18+ 🔞
Давай разберём эту тему про покрытие тестов, а то народ иногда такую хуйню несёт, что уши вянут. Слушай сюда, но без фанатизма.
Покрытие кода тестами — это как градусник, сука. Он температуру показывает, но не лечит. Высокий процент — не индульгенция от багов, а просто цифра, которая говорит: "Вот этот кусок кода хоть раз запускали, а не просто так нахуярили".
У нас подход простой, без истерик:
-
Цели разные, как жопы у людей. Нельзя ко всему подходить с одной меркой, это же пиздец.
- Ядро, где алгоритмы или деньги считают: тут без вариантов, 85-90%+. Это святое, тут любая ошибка — это волнение ебать и потеря доверия.
- Обычный код, типа контроллеров: 70-80% — нормально. Главное, чтобы основные сценарии работали.
- Код, который с UI или внешним миром ебётся: если юнит-тесты писать — тот ещё геморрой, то не заморачиваемся до посинения. Лучше один толковый интеграционный или ручной прогон, чем десять кривых моков.
-
Качество, а не циферки. Один тест, который ловит хитрый пограничный случай — это золото. А десять тестов, которые гоняют один и тот же "счастливый путь" — это просто мусор, который создаёт иллюзию работы. Пизда с ушами получается.
-
Всё в конвейер. У нас в CI/CD стоит автомат, который этот процент проверяет. Если ты новую фичу пишешь и покрытие просело ниже порога (скажем, 80%) — всё, приехали. Пул-реквест не пройдёт, иди и допиливай. Вот команда, которая всё решает:
go test -coverprofile=coverage.out ./... go tool cover -func=coverage.outА вывод тебе такое может выдать:
coverage: 85.2% of statements. Красота. -
С легаси-кодом — без геройства. Мы не бросаемся сломя голову покрывать весь старый говнокод. Это овердохуища работы. Но! Если ты в этом легаси лазишь и что-то чинишь или меняешь — будь добр, прикрой это место тестами. Правило простое: тронул — отвечай.
Самое главное, что все забывают
Гнаться за 100% — это мартышлюшка. После 85-90% каждая следующая десятая процента стоит как крыло от самолёта, а пользы — ноль ебать. Чаще всего это тесты ради тестов, которые ломаются от любого чиха.
Гораздо важнее иметь пару толковых интеграционных или E2E тестов, которые проверяют, что вся система в сборе не разваливается, как карточный домик. Они в эту метрику покрытия могут и не входить, но пользы от них — просто пиздец. Вот так-то.