[internal] Make missing arc fragments useful to more report generators · Issue #1850 · nedbat/coveragepy (original) (raw)
Navigation Menu
- Explore
- Pricing
Provide feedback
Saved searches
Use saved searches to filter your results more quickly
Appearance settings
Description
This is following on from the discussion near the end of #1846. parser.py
has a sophisticated algorithm for characterizing branch arc destinations - ordinary if statement, exiting the function, exiting a with
clause, etc. - but the way it's presently implemented, it is only useful to the HTML report generator. To make it useful to more reporters, I'd like to ask for the following:
- A new
FileReporter
API, analogous to the existingmissing_arc_description
function, that tersely describes the destination of an arc without any leading text about whether it was or wasn't executed. For ordinaryif
destinations, it'd be most useful to get just "line {lineno}". For function returns, "return from {self.name!r}". And so on. - Similarly, an exposed API that describes the circumstances where an arc would fail to have been taken - the existing "condition on line {lineno} was never {true/false}", "pattern on line {lineno} {always/never} matched" texts - in isolation, without the rest of the missing_arc_description verbiage, would be useful (not directly to the LCOV reporter, but I bet someone will want it eventually).
And finally, an exposed API that tells you whether an arc should be ignored, whether or not it was ever taken or not taken. This is for things like(Split to [internal] Generator-expression exit arcs aren't always filtered out of executed_branch_arcs #1852.)if any(pred(x) for x in xs)
, where the uninteresting exit arc from the generator expression gets filtered out of the HTML report by (it seems) always getting executed, but a reporter like LCOV that needs to talk about all the arcs has no good way to tell.