-
-
Notifications
You must be signed in to change notification settings - Fork 274
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
Knowing what tests executed a line #207
Comments
Wow, how nice!! I use OpenCover, just tried this and it's great! Sorry I didn't find that before, now I found the info in your blog and I see it's a feature since Nov. 4 2012... In the other hand, don't you think it would be nice to be able to do the opossite, instead of clicking a test to see its coverage, clicking a line to see what tests execute it. So you if you are interested in a specific line, you don't have to go selecting all the tests one by one to see which ones execute that line. I don't know if that's feasible to do, but I think it would be a nice feature. |
It should be possible to add this feature. I will consider adding this in the next release. |
Please have a look at the latest version 4.0.13. |
Great! Thanks for taking this feature into account! I have a comment though, it happens that if you have more test methods in "Coverage by test methods" that what can fit the screen, and you want to see the highlighting for the non visible test methods, since the highlighting is produced by hovering the line, you loose the highlighting when going to scroll the list. So to keep track of the all the test methods for a line you have to go back and forth between the line and the scroll bar. IMHO, it would be better to click the line to select it, and leave the tests highlighted as long as the line is selected. |
I changed the behavior. |
Now that's excellent! |
I think it would be very useful to be able to know what tests executed a line of code, more than the count of times the line was executed. Would it be possible to add this feature?
It's possible to know that information by placing a breakpoint in the line that we want, then executing the tests and look at the Call Stack Window each time the debbuger hits the breakpoint, but that is far more work than just having the info in the report.
The text was updated successfully, but these errors were encountered: