WIP, ENH: add docstring cov to html #808
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
One of the items on the wishlist for testing docstrings in NumPy / SciPy is the ability to report "coverage" for those docstrings that are probed by doctesting infrastructure. In particular, I had in mind the idea that labels in the html coverage reports that one often finds as part of the CI for large OSS scientific projects might be expanded to include hits on docstrings.
This lead to me to a simple example on StackOverflow by @rhettinger, which really got me excited even more. However, I noticed that executing the exact same code and trying to display with
coverage html
effectively ignores the docstring using both stable and master branch ofcoveragepy
. I dug a little deeper and noticed thatcoverage annotate
actually has a much shorter / simpler loop for doing the labelling vs. html, and I figured I'd take a look at the html assignment of lines to label classes, and see if I could get it to do what I want.This PR has a draft of what I had in mind that I initially thought was working, but actually seems to be not quite right yet. There are probably various ecosystem considerations & things like trying to fuse these results with results that don't have docstrings labelled, etc. But if I I can't get this "simple" case to work, the prospects for expanding the "feature" usage to large packages wouldn't be great.
With this feature branch and my
.coveragerc
initially looking like this:with the original example code from StackOverflow we get the docstring now highlighted along with the source itself that was ultimately executed by doctest:
and with a doctest SKIP directive added in to Raymond's example, another design question comes up--would it be possible / worth the trouble to have a separate highlight color / category for docstring examples that are not executed? (notice that the source proper is still correctly marked as not executed, since the docstring didn't get executed, although the docstring was "considered but skipped" so perhaps technically "covered"):
So, as I was writing this up, I thought "hey this is working just like the annotate case so must be good," but then I commented out the doctest execution and it seems the docstring lines are just getting labelled as a fallback, not because the tracing infrastructure knows that they are getting executed:
Ok, so maybe I got excited a little too early. That got me curious about Raymond's original example with annotate. If I turn off the docstring execution there by commenting out the
doctest.testmod()
line I get a result suggesting that docstring hits are not actually meaningful results fromcoveragepy
tracing / interpretation infrastructure:This suggests to me that there may be another "meta" level to the tracing if we want to handle
doctest
probing of those string lines as "hits." That might be split into two categories:exec(compile())
run by doctest or subclassed doctest infrastructure in a library like NumPy / SciPy?