Skip to content

cmd/go: write empty coverage report when there are no tests #18909

@jspiro

Description

@jspiro

tl;dr

  • go test -cover should output coverage for packages with .go files that lack tests to accurately report that there is no test coverage for that package
  • go test should have a flag that causes it to fail if a package is found without any tests, and/or should fail if a .go file is found without associated _test.go

It (sort of, out of lazy convenience) makes sense that go test ./... succeeds if it finds a package with at least one .go file, but without tests, skipping it. But the same behavior doesn't make sense for coverage -- negative coverage reports should be created for packages without a single test but with go files.

The problem: Say you have 100 packages of Go code (each has approximately the same number of statements), and only one has tests, and those tests cover 100% of that package's code, then coverage for the repo will be 100% (only one coverage report is created). But it's really 1% coverage.

If you add an empty _test.go file to each package, you'll suddenly get negative coverage reports for every package, and your coverage will be correct. This is silly, you shouldn't have to remember to do this everywhere to get accurate coverage reports.

Proposal
Either (or both)

  • Add a flag to go test that will fail if a package is discovered without tests (alerting us to the problem so we can add a test, and always get proper coverage)
  • Have go test -cover output negative coverage repots even if no tests are found (or add a flag that will do this)

Nice to have

  • A go test flag that fails if any .go file doesn't have an accompanying _test.go -- I'm sure some people would welcome this level of strictness

Up for debate

  • Whether package main files must also have _test.go -- not sure how prevalent it is to have tests for these. I noticed that go test seems to try running these files if a test file exists; this causes my tests to fail since main packages tend to be commands that fail without input.
  • Another caveat is that generated code like protobufs and mocks generally don't come with tests, so having a way to exclude a package might be necessary. Or maybe you just need to test your code!

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

go version go1.7 linux/amd64

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions