Support for showing contexts

[spookylukey]

A cool thing you can do with coverage and pytest-cov is dynamic contexts, which results in a neat feature in the HTML report, where you can see the tests that executed a line of code.

Obviously it would be cool to have this directly from my editor in some way. Seeing that this package is already overlapping with this functionality, I thought this might be a good place for it. Would you be interested in having a feature like that?

I'm aware it's a lot of work, so it's something I might tackle myself, before doing so I just wanted to know what your thoughts on that becoming part of this package. I'm not a brilliant elisp hacker but this is probably a good project for me to take on at my level, and it certainly scratches an itch for me.

There are some significant issues. The contexts data is not exported to coverage.xml as far as I can see, so that is a bit of a blocker.

However, another way to get the data is directly via the .coverage data file, which is an SQLite file (since version 5, 2018 - https://coverage.readthedocs.io/en/coverage-5.5/changes.html#version-5-0a2-2018-09-03). This file doesn't have a fixed schema, but it does have an easy way to check the schema version: select version from coverage_schema; So you know if it is different from what you expect and you can support multiple versions probably fairly easily for our needs.

If you switched to using the SQLite data directly, you get an additional advantage - there is no need to run coverage xml as an extra step first. There would probably be other advantages too in terms of more powerful querying of the data. It may also have performance benefits if you have a large .coverage file - using coverage.xml requires you to parse the whole XML file every time to get just the data you are interested. Would you be open to switching from coverage.xml parsing to using the SQLite file?

Thanks!

[wbolster]

hi 👋🏼

only seeing this now – turned out i wasn't even watching my own repo, so didn't get notified before. 🙈

the XML parsing and transformation stuff was quite tricky to get working, and while it seems to work robust enough for my use cases, it's indeed quite slow and complex.

i'm open to making changes here, especially if those come with added benefits like new features or better performance.

[spookylukey]

As mentioned on the PR, it turns out that, compared to reading the SQLite file, XML parsing the coverage.xml file produces much better results for coverage overlays, due to additional processing that coverage.py does regarding whitespace and docstrings etc. So it looks like you'll need both methods, which is what my PR does.