Команда DoltHub пишет Dolt на Go уже много лет. Тесты у них есть в огромном количестве, но покрытие кода они никогда не измеряли. Недавно один из инженеров вспомнил, что Go добавил поддержку инструментирования покрытия в обычных бинарниках ещё в версии 1.20, не только в
go test. Решили проверить, что из этого выйдет.Хорошая часть их покрытия приходит на интеграционные тесты, которые запускают бинарник напрямую, а не через go test. В частности, у них тысячи BATS-тестов для CLI, и большая часть кодовой базы проверяется только ими.
Для юнит-тестов достаточно добавить несколько флагов к go test:
go test -cover -coverpkg="$COV_PKGS" ./... -args -test.gocoverdir=/tmp/coverdata/unit
Флаг
-cover включает сбор данных. -coverpkg задаёт список пакетов для инструментирования. Чтобы не перечислять их вручную, используют go list:go list -f '{{if not .Standard}}{{.ImportPath}}{{end}}' -deps . | \
grep dolthub | paste -sd"," - > "pkgs.txt"
export COV_PKGS=$(cat pkgs.txt)Для интеграционных тестов собирают инструментированный бинарник:
go build -cover -coverpkg="$COV_PKGS" ./cmd/dolt/.
export GOCOVERDIR=/tmp/coverdata/integration
Теперь любой запуск этого бинарника пишет данные о покрытии в указанную директорию.
После всех прогонов данные сводятся в один файл:
go tool covdata textfmt -i /tmp/coverdata/unit,/tmp/coverdata/integration -o cov.out
go tool cover -html=cov.out
Получается HTML-файл с построчным покрытием. Проблема в том, что стандартный интерфейс предлагает выбрать нужный файл из выпадающего списка всех 1910 файлов проекта что неудобно.
Команда DoltHub написала свой конвертер поверх стандартного вывода: он разбивает результат по отдельным файлам и добавляет индексную страницу с сортировкой по уровню покрытия.
Что получилось в итоге
Итоговый отчёт охватывал 1910 файлов со средним покрытием 49%. Ниже, чем типичные 70% в Java-проектах. Но результат объясним: в числе проанализированных файлов оказались форкнутые зависимости вроде Vitess, мёртвый код и автогенерированные фичи без тестов.
Когда результаты показали коллегам, реакция была спокойной. Никто не рвался писать новые тесты, чтобы поднять цифры. Всех больше интересовало, какой AI-инструмент помог сгенерировать отчёт.
Три причины, почему покрытие не стало приоритетом:
1. Кодовая база большая: больше полумиллиона строк кода. Понять, с чего начать после восьми лет без покрытия, непросто.
2. Go-код даёт много шума из-за обработки ошибок. Каждый блок if err != nil порождает непокрытую ветку, и требовать её покрытия нереалистично.
3. У команды уже есть наборы тестов, которым они доверяют.
DoltHub решили пока не автоматизировать сбор покрытия: постоянно мигающий сигнал, который все игнорируют, хуже, чем его полное отсутствие. Возможно, позже к этому вернутся и подключат агентов, чтобы автоматически находить участки с низким покрытием и писать для них тесты.
➡️ Источник
📍 Навигация: Вакансии • Задачи • Собесы
🐸 Библиотека Go-разработчика
#GoDeep