Closed
Description
Currently, coverage profiles include coverage for functions that cannot ever run (func _() { ... }
). These sorts of functions are commonly used to generate compile-time checks that aren't expected to actually execute. For example, code generated by stringer
:
// Code generated by "stringer -type=accessLevel -trimprefix=level"; DO NOT EDIT.
package bot
import "strconv"
func _() {
// An "invalid array index" compiler error signifies that the constant values have changed.
// Re-run the stringer command to generate them again.
var x [1]struct{}
_ = x[levelUnknown-0]
_ = x[levelEveryone-1]
_ = x[levelSubscriber-2]
_ = x[levelModerator-3]
_ = x[levelBroadcaster-4]
_ = x[levelAdmin-99]
}
const (
_accessLevel_name_0 = "UnknownEveryoneSubscriberModeratorBroadcaster"
_accessLevel_name_1 = "Admin"
)
var (
_accessLevel_index_0 = [...]uint8{0, 7, 15, 25, 34, 45}
)
func (i accessLevel) String() string {
switch {
case 0 <= i && i <= 4:
return _accessLevel_name_0[_accessLevel_index_0[i]:_accessLevel_index_0[i+1]]
case i == 99:
return _accessLevel_name_1
default:
return "accessLevel(" + strconv.FormatInt(int64(i), 10) + ")"
}
}
Could have a coverage profile of:
github.com/hortbot/hortbot/internal/bot/accesslevel_string.go:7.10,17.2 7 0
github.com/hortbot/hortbot/internal/bot/accesslevel_string.go:28.38,29.9 1 23
github.com/hortbot/hortbot/internal/bot/accesslevel_string.go:30.24,31.80 1 21
github.com/hortbot/hortbot/internal/bot/accesslevel_string.go:32.15,33.29 1 2
github.com/hortbot/hortbot/internal/bot/accesslevel_string.go:34.10,35.64 1 0
Note the first line, which says 7.10,17.2 7 0
, i.e. the _
function has zero lines covered.
I propose that coverage data should be omitted for these _
functions. My rationale:
- Because these functions show up in coverage profiles, they "fool" commonly used coverage visualization / tracking systems into reporting a lower-than-true percentage. Here's my profile example on coveralls: https://coveralls.io/builds/27776643/source?filename=internal/bot/accesslevel_string.go
- These functions cannot run; their benefit is already gained at compile time.
- Due to the simplicity of the coverage profiles (just line info, no context), it's not straightforward to post-process coverage data to get this behavior without changing
go test
itself.
I'm not sure if this is a proper "proposal", but I didn't think it was exactly a "bug" either. Feel free to retitle as needed.