-
Notifications
You must be signed in to change notification settings - Fork 240
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: Call coverage #23
Comments
Interesting idea. I haven't given call coverage much thought yet. It appears that gcov provides all the required data when running it with option -b (which LCOV already does for getting branch coverage). I can see the benefit of having this function added to LCOV, though I don't think I will be getting to implement this any time soon, but patches are of course welcome. Let's think the interface through for a moment:
Thoughts and comments on this are welcome. |
The thoughts concerning the interface are really complete. But the part "b) Similar to the "Branch data" column in source code view, there should be another column "Call data" that shows..." can blow up the report. A simple line can have several calls as well as each condition in an e.g. if statement can include calls. My intention for this feature request is to give tester and quality manager an overview of the reached call coverage together with statement and branch coverage at the end of a development / test phase. I expect that the analysis of missing test cases is done on the basis of the statement and branch coverage mainly. If there is a lack of call coverage this can be found in the not covered statements and branches, which should not be that much when we come to the end of the test. So for my intention an implementation of the annotation in the code can be postponed until somebody really ask for this. |
lcov is able to show:
I understand function coverage to which percentage functions are entered and thereby tested.
From my point of view it is very helpful to be able to measure to which percentage calls to function(s) has been tested. The call coverage.
An example for the difference and for the need of this metric. Let's assume we have one function A, which calls another function B. To know that function B is entered (at least once = function coverage) is one side. But when the function B is called from 3 different locations in function A and in each of these calls a mistake can be made e.g. with parameter order there is an additional need to know whether each of the existing calls are applied = Call coverage.
Best regards
MMelzig
The text was updated successfully, but these errors were encountered: