You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
It would be ideal to get branch coverage at Per Function Level in the "List Of Functions" html output. and hence it will be in the json output.
This will help us gate merges at per function level rather than file level.
Describe the solution you'd like
The File level Coverage Report shows Branches Coverage
It would be useful to have it at "Per Function Level" as well. So another Column in the "List of Functions" view
Describe alternatives you've considered
The other Alternative is to scrape the htmls generate by gcovr, find the start of a function, travel to the end of it, find all instance of text like "5/6 branches covered" and add all those up. If there is a better alternative, willing to try it.
Additional context
I was trying to figure out how to add this functionality but couldn't exactly get it. It seem gcovr generates FileCoverage where the "type" for each line is present. Then when the html is being generated for each line, is traversed through and if it has branch coverage data that is summed up.
So the same could be done at the function html generation time but where I got stuck we there is no way to tell the start and end a function (Correction, no way to tell the end of a function. Start is present). And annoyingly even GCOV doesn't seem to output the start and end of a function. Not in its text output at least, only in the json out (if --json-format is provided) but then the json output is missing other important info so its not what should be using.
If anyone can provide suggestion on how to do this, I can try adding this.
The text was updated successfully, but these errors were encountered:
As mentioned in #654 this information can't be gathered from the gcov text output since we've no information to which function a branch or line belongs to.
When the gcov JSON format is supported this information would be present (see #282 (comment)).
Interesting, Could like counting the number of { and } work to figure out function start and end? OR maybe if a _FunctionLine is hit, consider start of function till next _FunctionLine is hit? Or the combination of these 2?
Is your feature request related to a problem? Please describe.
It would be ideal to get branch coverage at Per Function Level in the "List Of Functions" html output. and hence it will be in the json output.
This will help us gate merges at per function level rather than file level.
Describe the solution you'd like
The File level Coverage Report shows Branches Coverage
It would be useful to have it at "Per Function Level" as well. So another Column in the "List of Functions" view
Describe alternatives you've considered
The other Alternative is to scrape the htmls generate by gcovr, find the start of a function, travel to the end of it, find all instance of text like "5/6 branches covered" and add all those up. If there is a better alternative, willing to try it.
Additional context
I was trying to figure out how to add this functionality but couldn't exactly get it. It seem gcovr generates FileCoverage where the "type" for each line is present. Then when the html is being generated for each line, is traversed through and if it has branch coverage data that is summed up.
So the same could be done at the function html generation time but where I got stuck we there is no way to tell the start and end a function (Correction, no way to tell the end of a function. Start is present). And annoyingly even GCOV doesn't seem to output the start and end of a function. Not in its text output at least, only in the json out (if --json-format is provided) but then the json output is missing other important info so its not what should be using.
If anyone can provide suggestion on how to do this, I can try adding this.
The text was updated successfully, but these errors were encountered: