Как игнорировать сгенерированные файлы из покрытия Go test - PullRequest
0 голосов
/ 27 апреля 2018

У меня есть сгенерированный файл в моем пакете с DO NOT EDIT сверху. Я запускаю тесты для моего пакета с go test -coverprofile=cover.out <package>. Это создает профиль покрытия и показывает общий процент покрытия. Но он также включает в себя сгенерированные файлы при расчете покрытия. Есть ли способ игнорировать сгенерированные файлы при расчете покрытия?

Ответы [ 3 ]

0 голосов
/ 04 мая 2018

Вы можете удалить сгенерированный код из профилей обложки:

go test . -coverprofile cover.out.tmp
cat cover.out.tmp | grep -v "_generated.go" > cover.out
tool cover -func cover.out

В зависимости от используемых инструментов это может быть легко реализовано в конвейере / изготовителе.

0 голосов
/ 21 февраля 2019

Следуя путям, которые я мог решить эту потребность.

Исключая dirs / pkgs

Поскольку для запуска теста и создания обложки вы указываете pkgs, где команда go test должна искать файлы из этого pkg, автоматически игнорируется. По примеру

project
|_______/pkg/web/app 
|_______/pkg/web/mock -> It will be ignored.

# Command:   
$go test -failfast -tags=integration -coverprofile=coverage.out -covermode=count github.com/aerogear/mobile-security-service/pkg/web/apps

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

Используя "_test" в определениях имен

Если вы хотите игнорировать файлы, которые используются в тестах, имеет смысл использовать _test в конце имени. Например, my_service_mock_test.go. Файлы с _test в конце имени будут игнорироваться по умолчанию.

Сняв с обложки файл следующим образом

go test . -coverprofile cover.out.tmp
cat cover.out.tmp | grep -v "_generated.go" > cover.out
tool cover -func cover.out

PS .: Я не смог найти комментарий или тег, который бы исключил их.

0 голосов
/ 27 апреля 2018

Большинство инструментов Go работают с пакетами, потому что сам пакет образует единицу , которая может быть полезна во всей своей полноте. Исключение файлов из пакета может легко «сломать» пакет: исключенный файл может содержать (крайне важный) код инициализации пакета или даже может привести к невозможности компиляции оставшихся файлов пакета.

go test не является исключением: он также работает с пакетами. Нет поддержки из первых рук для исключения файлов из пакета.

Если ваш пакет может быть скомпилирован и протестирован без сгенерированного файла, вы можете выбрать создание файла в другом пакете, и тогда он не будет включен в тест вашего пакета (покрытия) естественным образом.

Еще один способ справиться с этим - по-прежнему генерировать его в том же пакете / папке и использовать специальные теги сборки в сгенерированных файлах, которые вы можете исключить при запуске теста покрытия. Подробнее о тегах сборки можно прочитать здесь: Ограничения сборки и здесь: Как правильно подходить для инкапсуляции кода, специфичного для платформы, в Go?

Если сгенерированный файл необходим для компиляции / тестирования пакета, тогда у вас все еще есть возможность: использовать внутренний пакет для сгенерированного файла. Внутренние пакеты доступны только для дерева пакетов с корнем в папке internal, что означает, что вы можете экспортировать любые идентификаторы во внутренний пакет, компилятор гарантирует, что они не будут использоваться «непреднамеренными» сторонами. Подробнее о внутренних пакетах можно прочитать здесь: Могу ли я разработать пакет go в нескольких исходных каталогах?

Также рассмотрите возможность написать или сгенерировать тест для сгенерированного кода, что может быть хорошей практикой, так что вам не придется использовать хитрости, чтобы исключить их из тестов покрытия.

...