You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
...There were no code changes, so there were no coverage changes, of course. But why does test_pydot.py staying at 93% coverage get a green badge, while classes.py staying at 96% gets an orange badge? Something fishy there.
Possible it has something to do with the branch coverage, though I don't think so.
(Although, speaking of branch coverage, having it included does make those summaries a bit "off". For example, 384 ÷ 402 is actually 95.5%, not 93%. 93% is the correct coverage value, because missing branches lower the total coverage for the file... but it means that displaying both the percentages and the lines-of-coverage fractions is a bit confusing/misleading, since one doesn't directly correspond to the other.)
The text was updated successfully, but these errors were encountered:
I seemed to recall that we weren't supposed to display lines that weren't modified, I wonder why this didn't work (at least for lines with absolutely no changes) (maybe it's a branch coverage issue too)
Yeah, I think the issue is that branch coverage makes it less clear what exactly the displayed number is. That said, I think there's more value in seeing if 93% is 93/100 or 9300/10000 than seeing more digits.
Finally: I don't understand how the PR change even impacts branch coverage.
Just noticed this on a recent PR run:
Coverage report
(new stmts)
This report was generated by python-coverage-comment-action
...There were no code changes, so there were no coverage changes, of course. But why does
test_pydot.py
staying at 93% coverage get a green badge, whileclasses.py
staying at 96% gets an orange badge? Something fishy there.Possible it has something to do with the branch coverage, though I don't think so.
(Although, speaking of branch coverage, having it included does make those summaries a bit "off". For example,
384
÷402
is actually 95.5%, not 93%. 93% is the correct coverage value, because missing branches lower the total coverage for the file... but it means that displaying both the percentages and the lines-of-coverage fractions is a bit confusing/misleading, since one doesn't directly correspond to the other.)The text was updated successfully, but these errors were encountered: