Coverage.py not reporting complexity metrics in cobertura.xml

[edmondop]

For any of the files in my project, the cobertura.xml contains always a 0 for complexity.

I have hard time in understanding if the value is not computed by coverage.py (and probably we would prefer a NA then) or if my code has really such a low complexity :)

[nedbat]

Coverage.py doesn't measure complexity, so the XML file has no information about it.

[edmondop]

Maybe just updating the docs on the reporter? Why reporting zero then?

[nedbat]

Can you do an experiment for me? If you remove the complexity attributes from the XML file, what will your reporting tool do with it? I don't know if the file will be considered valid.

[edmondop]

It won't be considered valid, if you open a coverage.py generated coverage.xml the first line says

<!-- Generated by coverage.py: https://coverage.readthedocs.io -->
<!-- Based on https://raw.githubusercontent.com/cobertura/web/master/htdocs/xml/coverage-04.dtd -->

but if you open that DTD, you see that complexity is required, but is not a number, is a string. So why not N/A?

If you accept contributions, here that would be my proposal https://github.com/nedbat/coveragepy/pull/1297

[nedbat]

Are you using a reporting tool that reads the XML file? What does it do with "N/A"?

[edmondop]

You are right, although the DTD does not dictate anything around the format of that specific field, making it by contract a free form string, tools probably make assumptions that the number can be parsed.

For example, I am parsing that file via irongut/[email protected] github action which assumes it can be parsed into a double, and if cannot returns a 0.

https://github.com/irongut/CodeCoverageSummary/blob/master/src/CodeCoverageSummary/Program.cs#L170

Maybe we should file an issue to cobertura asking them to convert the DTD into XSD :) In coverage.py we can use a more explicit sentinel value, for example -1 , -99, or a negative large integer? something that obviously is not a valid complexity value

[nedbat]

Wouldn't you say that 0 is obviously not a valid complexity value? :)