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
Hits per line #3
Comments
As far as I know coverage.py does not provide hits per line stats, that's why they're not submitted to coveralls. Does not matter if branch coverage is enabled or not. If I'm not correct, you're welcome to prove me wrong ;) |
Right, it does not. I'm just suggesting that you should use the branch coverage statistics to provide additional information. Right now, you do something like the following.
Instead, if branch coverage is enabled (and both branches are covered), you should be doing this instead.
|
I'm not a fan of hits per line report, so I'm not inerested in making this feature myself. However, I'm willing to merge that if anyone submits a tested pull request. |
Just to clarify, do you mean you are not interested in branch coverage? (Because what you support right now is hits per line.) |
I'm interested in branch coverage, but not the way it is displayed on coveralls right now. I'd rather see uncovered branches and/or branch coverage in percents. But I support the idea of providing extra info if that's the only current option. |
Ah, I agree. Hits per line is quite inadequate. I actually posted an issue (lemurheavy/coveralls-public#31) on the Coveralls repository earlier |
I'll wait on trying to implement anything until I hear back from the Coveralls guys. (I'd much prefer the branch coverage to be reflected in the overall percentage than try to implement the hack I described previously.) |
Feel free to reopen when and if branch coverage will be available on coveralls |
I find this feature useful in my C++ project because it gives me a good idea of how well a given line of code is actually tested. If the line of code is run only once, then I know there is only one test that executes it and this is suboptimal test coverage. If a line of code is run 24,000 times, then I know we've got far better testing of it (It's probably safe to assume that the tests aren't calling the exact same thing many times over). |
I noticed that the line coverage result is binary (0 or 1) even if branch coverage is enabled. Is there any reason for not incrementing the number of hits for lines that are covered by more than one branch?
Of course this is not an exact mapping to the hits per line that Coveralls wants. But it seems better to me than a strict binary hit status (which shows less information than Ned's HTML reports).
The text was updated successfully, but these errors were encountered: