Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unintuitive behavior when using -coverpkg #23786

Closed
F21 opened this issue Feb 12, 2018 · 2 comments
Closed

Unintuitive behavior when using -coverpkg #23786

F21 opened this issue Feb 12, 2018 · 2 comments

Comments

@F21
Copy link

F21 commented Feb 12, 2018

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

1.10 RC2

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

Windows 10 64-bit (latest release + updates)

What did you do?

Code is available here: https://github.com/F21/coverpkgtest.git

I have a project arranged like so:

coverpkgtest (package at the root)
- somepkg
  - dontcover
    - some generated files
  - some tests
- some tests

This uses Ben Johnson's standard layout where the domain model is in the package root.

dontcover represents things like protobufs or other generated code that I don't want to include in the coverage report.

I want to run my tests for the package and all other subpackages and get a coverage report excluding packages containing the generated code.

What did you expect to see?

This runs all tests in all packages (expected).

$ go test -coverpkg=./... -coverprofile=cover.out -v ./...
=== RUN   TestSomething
--- PASS: TestSomething (0.00s)
PASS
coverage: 0.0% of statements in ./...
ok      github.com/F21/coverpkgtest     1.157s  coverage: 0.0% of statements in ./...
=== RUN   TestSomePkg
--- PASS: TestSomePkg (0.00s)
PASS
coverage: 0.0% of statements in ./...
ok      github.com/F21/coverpkgtest/somepkg     2.896s  coverage: 0.0% of statements in ./...
?       github.com/F21/coverpkgtest/somepkg/dontcover   [no test files]

This only runs tests in somepkg. The ./... at the end of the go test command being ignored is also surprising. In addition, go list lists all packages, so it was also surprising that tests in the root package was skipped

$ go test -coverpkg=$(go list ./...) -coverprofile=cover.out -v ./...
=== RUN   TestSomePkg
--- PASS: TestSomePkg (0.00s)
PASS
coverage: 0.0% of statements in github.com/F21/coverpkgtest
ok      github.com/F21/coverpkgtest/somepkg     1.581s  coverage: 0.0% of statements in github.com/F21/coverpkgtest
?       github.com/F21/coverpkgtest/somepkg/dontcover   [no test files]

This runs all tests. Adding a space between the equals and the packages to test runs all tests. I am not sure why the space makes a difference

$ go test -coverpkg= $(go list ./...) -coverprofile=cover.out -v ./...
=== RUN   TestSomething
--- PASS: TestSomething (0.00s)
PASS
coverage: 0.0% of statements
ok      github.com/F21/coverpkgtest     1.370s  coverage: 0.0% of statements
=== RUN   TestSomePkg
--- PASS: TestSomePkg (0.00s)
PASS
coverage: 0.0% of statements
ok      github.com/F21/coverpkgtest/somepkg     2.652s  coverage: 0.0% of statements
?       github.com/F21/coverpkgtest/somepkg/dontcover   [no test files]

This does what I need, by add a space between the equals and the packages to test:

$ go test -coverpkg= $(go list ./... | grep -v dontcover) -coverprofile=cover.out -v ./...
=== RUN   TestSomething
--- PASS: TestSomething (0.00s)
PASS
coverage: 0.0% of statements
ok      github.com/F21/coverpkgtest     0.156s  coverage: 0.0% of statements
=== RUN   TestSomePkg
--- PASS: TestSomePkg (0.00s)
PASS
coverage: 0.0% of statements
ok      github.com/F21/coverpkgtest/somepkg     0.255s  coverage: 0.0% of statements

This works as expected:

$ go test -coverpkg=github.com/F21/coverpkgtest,github.com/F21/coverpkgtest/somepkg -v ./...
=== RUN   TestSomething
--- PASS: TestSomething (0.00s)
PASS
coverage: 0.0% of statements in github.com/F21/coverpkgtest, github.com/F21/coverpkgtest/somepkg
ok      github.com/F21/coverpkgtest     2.923s  coverage: 0.0% of statements in github.com/F21/coverpkgtest, github.com/F21/coverpkgtest/somepkg
=== RUN   TestSomePkg
--- PASS: TestSomePkg (0.00s)
PASS
coverage: 0.0% of statements in github.com/F21/coverpkgtest, github.com/F21/coverpkgtest/somepkg
ok      github.com/F21/coverpkgtest/somepkg     1.545s  coverage: 0.0% of statements in github.com/F21/coverpkgtest, github.com/F21/coverpkgtest/somepkg
?       github.com/F21/coverpkgtest/somepkg/dontcover   [no test files]

What did you see instead?

See above

@ianlancetaylor
Copy link
Contributor

This has nothing to do with Go. It's all just because of how the shell behaves. When you write

go test -coverpkg=$(go list ./...)

you didn't quote the $(), so it generates multiple arguments. In effect you are passing one package to -coverpkg, and the remaining output from go list becomes arguments to go test.

@vangent
Copy link

vangent commented Nov 16, 2018

-coverpkg requires comma-delimited packages anyway, so quoting (-coverpkg="$(go list ./...)") won't work. Something like

-coverpkg=$(go list ./... | grep -v dontcover | tr '\n' ',')

might do what you want.

@golang golang locked and limited conversation to collaborators Nov 16, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants