Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign uptesting: exclude unreachable code in test coverage #31280
Comments
This comment has been minimized.
This comment has been minimized.
Flagging statically-unreachable code seems like a useful signal to me, and whether the compiler is able to determine statically that it is unreachable is an implementation detail. 100% code coverage is usually not an appropriate goal for Go projects. Can you give some more detail as to why this particular behavior is important? |
This comment has been minimized.
This comment has been minimized.
I am not targeting for 100% coverage. the code coverage numbers does not reflect expected ones. the html report generated shows all tracing code as red. so when seeing reports, I have to mentally discard all those tracing lines of code highlighted in red. currently I am doing a workaround of enable trace variable but do not generate any trace during tests suing build tags. this keeps code coverage track those lines. |
This comment has been minimized.
This comment has been minimized.
I was looking for a similar feature, not so much to reach 100% coverage, but because when reviewing coverage to determine if uncovered lines should be covered, its useful to have an annotation that says "not reachable, expected to be red". I guess I could literally put such a comment in my code, but I think it'd be pretty nice to get a report that said "92% covered, 6%uncovered, and 2% marked unreachable". I think of uncovered code a bit like lint output or compiler warnings. Developers shouldn't have to reevaluate every time they checkout a project and run lint if the output is relevant. If its been decided that it is irrelevant, its handy to suppress it with in-line markup, and then nobody has to see the output again and then go look to see if its valid. |
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
Outputi have code like this in my project:
because
trace
isfalse
, the coverage reports the tracing code asnot covered
can such code be shown as "not tracked"
I enable
trace
if we are debugging some issue in our code using build tagsI can enable trace during coverage generation, but tracing output is large and it takes significant time.
I have seen
types
package from stdlib also usesif trace
so may be this can be taken as enhancement