-
Notifications
You must be signed in to change notification settings - Fork 17.5k
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
cmd/go: test -cover reports 100.0% without full coverage #39168
Comments
Workaround for the issue using
|
Isn't this just floating point rounding for an extreme corner case? Even if it printed 2 digits after the decimal point, you might still get 100.00%, depending on exactly how many statements are not executed. I don't see a good solution, and don't feel the problem is important enough to do something special. The shorthand report makes no guarantees but there are other output forms that might help. |
It's not pretty, but a simple hack |
Maybe something like this?
Output:
|
I agree with @robpike. If you want to analyze coverage down to the exact line, I would expect that you could build a standalone tool for that on top of the |
That's true of course. I've been thinking about the default experience, this is how it went for me:
Yes, but it also means that the output cannot be reliably used to check for full coverage if the package is slightly bigger. I've just checked, only 2000 lines! The code above increases the precision around 100.0% but it still stays in the high school mathematics. There's another simpler solution which I use for progress reports (I hate seeing 100% when the software is not done):
|
I'd be in favor of For context, we have a script which parses that output to check that a pkg's coverage meets a specified threshold (which is often 100%). I understand we could (and perhaps should) be parsing some other, more robust output, but I think between our use-case and the general use-case of a CLI or editor/IDE user seeing 100% when it's not really (and having expectation that 100% means every-line-is-covered), that it's worth making this rounding exception. |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes (1.14.3)
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
The problem came up while developing a binary protocol library with many generated functions.
Generate many tests with a script:
Run test coverage:
What did you expect to see?
99.9%
or something similar.Reducing
n
to1000
produces99.9%
on my machine.What did you see instead?
100.0%
(which implies full coverage, not true!)The text was updated successfully, but these errors were encountered: