Better class coverage reporting in xml?

[nedbat]

Originally reported by Anonymous

---

I'm running coverage (via django-jenkins, but that's irrelevant) and using the XML report with the cobertura plugin to generate reports. I have to say it's incredibly handy.

One niggle, though, is that the xml report treats the whole of a module as the source of a single "class" (so my coverage reports claim: "classes 1/1"). It looks from a very cursory glance that the parser is spotting the start of class definitions, but not necessarily their corresponding ends.

Does coverage.py currently gather enough information to (conceptually, at least) produce a class-by-class breakdown in the XML report? If not, what additional support in the parsing is going to be required to help make this work?

Cheers.

---

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/158

[nedbat]

The problem with trying to map the code to Cobertura more closely is that Cobertura is based on the structure of Java code, where every line of code is part of some class. In Python, there are functions and even just plain statements outside of classes. If we map Python classes onto Cobertura classes, then we have to figure out where to put the non-class code. And that's even before we get to the question of how to actually parse it all out.

Patches welcome! :-)