Get coverage per test
See original GitHub issueUsing coverlet.core
, is it possible to get a “parent line” for a specific hit, to determine the call stack of the covered line?
I want to use that to figure out which tests ran through a specific line.
Issue Analytics
- State:
- Created 3 years ago
- Reactions:2
- Comments:19
Top Results From Across the Web
How to get coverage per test in SonarQube? - java
I'm having difficulties to set up my project in a way so SonarQube reports test coverage per test. During the analysis with Sonar...
Read more >Test Coverage Tutorial: Comprehensive Guide With Best ...
To calculate coverage of your tests, divide the total number of lines in a software application by the number of lines covered by...
Read more >Test coverage overview - SonarQube Docs
Test coverage reports tell you what percentage of your code is covered by your test cases. Test execution reports tell you which tests...
Read more >Run with coverage - IntelliJ IDEA
To collect code coverage statistics for tests, select the Enable coverage in test folders checkbox.
Read more >Obtaining Coverage per Test Case. - CQSE GmbH
This thesis presents an algorithm for selecting and prioritizing test cases for Java applications based on a set of changes that have been...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I’ve been curious about getting per-test coverage reports since the file formats tend to support it, but it would require a fair bit of redesign of the hit collection and a challenge to do it efficiently. Right now there is a single
int[]
per module that the hits are recorded into.My rough idea of what’s necessary to do to create this is that you have to change how methods are instrumented so that on entry they locate the unit test (if any). This would be done by traversing the callstack up, and then cache the result in an
AsyncLocal
so it doesn’t have to be done by every nested instrumented method. A hit array is created for each unit test, and used in the instrumented code instead of the static array that’s currently injected.When the test is done all these hit arrays would have to be transferred over to the coverlet process. This is already a time critical operation that is only stable when using the vstest collector driver, so moving potentially thousands of hit arrays would only be feasible in that driver, excluding the standalone and msbuild drivers as it stands now.
Finally the coverlet core will need to collate these hit arrays to get per-test statistics.
You could do this by scripting your test runs.
dotnet test -t
lists the tests in a project and iterate over them in a script, and then your script can run test by test by runningdotnet test --filter "$testname" --other-parameters-as-needed-to-get-coverage
. This will not be very efficient, of course.