go test fails when providing -coverpkg parameter

Question

I'm trying to get the test coverage across all packages in my project.

tests are getting executed successfully and report the coverage when I execute the following command.

go test -cover ./...

but all the tests are failing when I execute go test with coverpkg=./... parameter

go test -cover -coverpkg=./... ./...

This is the sample output of the command

srimal@srimal-pc:~/projects/myproject$ go test -v -cover -coverpkg=./... ./...
go build a.abc.com/path/to/module/e2e: no non-test Go files in /home/srimal/projects/driver-selection-handler/e2e
?       a.abc.com/path/to/module      [no test files]
?       a.abc.com/path/to/module/app  [no test files]
?       a.abc.com/path/to/module/constrain    [no test files]
FAIL    a.abc.com/path/to/module/directionalhire [build failed]
?       a.abc.com/path/to/module/domain       [no test files]
FAIL    a.abc.com/path/to/module/durationmatrix [build failed]
FAIL    a.abc.com/path/to/module/durationmatrix/etaservice [build failed]
FAIL    a.abc.com/path/to/module/durationmatrix/roadmatrix [build failed]
2021/04/22 17:23:07 go-util/log: Cannot open config file  open config/logger.yaml: no such file or directory
testing: warning: no tests to run
PASS
coverage: 0.0% of statements in ./...
ok      a.abc.com/path/to/module/e2e  (cached)        coverage: 0.0% of statements in ./... [no tests to run]
?       a.abc.com/path/to/module/events       [no test files]
FAIL    a.abc.com/path/to/module/finance [build failed]
?       a.abc.com/path/to/module/internal     [no test files]
?       a.abc.com/path/to/module/internal/config      [no test files]
?       a.abc.com/path/to/module/internal/logger      [no test files]
?       a.abc.com/path/to/module/internal/metrics     [no test files]
?       a.abc.com/path/to/module/internal/profiling   [no test files]
?       a.abc.com/path/to/module/internal/schema      [no test files]
?       a.abc.com/path/to/module/internal/stream      [no test files]
FAIL    a.abc.com/path/to/module/location [build failed]
?       a.abc.com/path/to/module/logger       [no test files]
?       a.abc.com/path/to/module/metrics      [no test files]
FAIL    a.abc.com/path/to/module/selection [build failed]
FAIL    a.abc.com/path/to/module/store [build failed]
FAIL    a.abc.com/path/to/module/stream [build failed]
?       a.abc.com/path/to/module/stream/reg   [no test files]
FAIL    a.abc.com/path/to/module/weighted [build failed]

I'm using go version 1.15.6

Is there any way to find the reason for the build failure?

Answer 1

Is there any way to find the reason for the build failure?

Build (or test) the package individually.

Answer 2

I don't have a direct answer, but I was having a similar issue and perhaps my process can help you solve your problem.

First, go help is your friend. The Go documentation, reference, and just Go in general is about making you productive. So the Go team puts a lot of effort into explaining things well.

go help test is a good place to start to get info about flags, but it doesn't list -coverpkg. It does however point to go help testflag:

The test binary also accepts flags that control execution of the test; these flags are also accessible by 'go test'. See 'go help testflag' for details.

go help testflag has this to say about -coverpkg:

-coverpkg pattern1,pattern2,pattern3
    Apply coverage analysis in each test to packages matching the patterns.
    The default is for each test to analyze only the package being tested.
    See 'go help packages' for a description of package patterns.
    Sets -cover.

Emphasis on "The default is for each test to analyze only the package being tested," Meaning if I depend on a package init() function I might have issues if I am working package by package.

If you want to follow the advice of running each package individually with coverpkg you can use go list ./... in your module's root directory to a get a list of all your packages and then use some shell scripting to iterate through them.

Ultimately, in my case I deduced that -coverpkg was testing each package one by one and therefore probably loading packages one by one. So I was able to narrow down my issue to a package's init() function. No idea why it was causing the problem, but moving a few lines out of the init() function that could go into the main() function fixed my issue.

(I was also lucky that the error message was easy to google and I knew it had something to do with CLI flag parsing. See Using kingpin in test files)