cmd/cover: go test -cover counts statements in init() as covered even if there aren't any tests #35289
Comments
In the preprocessing step, the builtin tool Say there's a simple code like: package main
import (
"fmt"
"time"
)
func init() {
var _ = 1 + 1
}
func main() {
fmt.Println("hello world")
} After being processed the original source code would possibly become: //line /Users/wei.wu/repos/go/bin/dave.go:1
package main
import (
"fmt"
"time"
)
func init() {
GoCover_0_313465376561633966613762.Count[0]++
var _ = 1 + 1
}
func main() {
GoCover_0_313465376561633966613762.Count[1]++
fmt.Println("hello world")
}
var GoCover_0_313465376561633966613762 = struct {
Count [2]uint32
Pos [3 * 2]uint32
NumStmt [2]uint16
}{
Pos: [3 * 2]uint32{
8, 11, 0x2000d, // [0]
13, 16, 0x2000d, // [1]
},
NumStmt: [2]uint16{
1, // 0
1, // 1
},
} |
I feel like code in init function is in fact exercised by the tests, as supposedly it generate global state that the tests might use. Coverage is only about code being exercised, not about its results actually mattering. |
@FiloSottile From https://blog.golang.org/cover
To me, a coverage report of anything greater than 0 implies that at least one test was run. This isn't a huge issue, but it can be misleading when coverage data is collected into a reporting system. I came across this issue while evaluating several code coverage reporting systems. If there is at least one test, then I have no problem with the code in an init function being counted. But if there are no tests, how can test coverage be anything other than 0? |
In
I haven't looked yet at what would need to be changed to keep the instrumentation, but to zero out the coverage percentage if there are no tests. |
|
@straightdave If there are no tests, do you want to see a code coverage greater than zero, then? |
In the classic view, yes, code-coverage is related to testing. If no tests to run, there's no coverage. |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
What did you expect to see?
What did you see instead?
The purpose of test coverage is to ensure that all statements in a module are exercised by tests.
Statements that are run regardless of tests are usually ignored by test coverage. This includes global variable, constant, and type declarations.
I would argue that statements in an init function should be ignored by code coverage as well since users can't directly call the init function.
The text was updated successfully, but these errors were encountered: