We use assertions to enforce things like pre-conditions.
Only the ‘happy’ code path should be executed so the branch coverage is reduced wherever an assertion is used.
Is there a good way to suppress branch coverage for this case?
I think this is a general question however I am using C++ & gcovr
At the moment the only solution I can think of is to pre-process the coverage xml report sent to sonar.
This would require grepping for lines containing assertion(.*) and removing the branch coverage attributes from the XML.
Is there is a better way of approaching this?
I’ve added the
cfamily tag to this in case one of the language experts wants to correct / override me. But no, I don’t see a better way other than lobbying your coverage tool provider to take this into account natively.
Is it possible to configure different targets for line and branch coverage for the quality gate independently? I do not currently have admin privileges for our projects so I cannot check this directly (though I will raise it with our admin).
Almost 100% line coverage is achievable but this kind of issue makes higher levels of branch coverage unobtainable.
I would be interested in how other tools for other languages handle this issue If you or anyone else knows.
Another point occurs to me.
Something like the new attributes in C++20 likely & unlikely might be worth looking into from the sonar side. They could perhaps be automatically interpreted as ‘exclude branch coverage’. This is not possible from the gcovr side as it does not parse the source code (and likely never will).
Using gcovr --exclude-lines-by-pattern ‘.*assert.*’ handles this case nicely for me.
Looks like you found a nice solution. Just wanted to mention another possibility that you might want to explore. Since you are talking about
assertion you can collect the coverage information from a build that skips them, i.e., with the
It has the downside of having to run the compilation and the tests twice, which is wasteful. Your solution looks more efficient.