Code Coverage Reports

[andrew.bentley]

I have started using the included CppUTest framework for unit testing in my current project (Linux). I’m pretty happy with the integration of the test framework with VisualStudio, and so moving forward we are looking to expand this throughout our organization.

One issue that has come up is the nature of the Code Coverage reports. What we really want is to know Code Coverage within our own files – not STL or boost, not the CppUTest framework, etc. The filter feature is nice for looking at coverage across a single file, but filtering based on path might be more effective.

Is there an effective way to do this built-in to the reporting? A custom gcov command line might get us partway there as well. Any thoughts you have would be appreciated.

Thanks,
Andrew

• This topic was modified 6 years, 6 months ago by andrew.bentley.

[codex653]

I’m pretty interested in hearing what’s available for this too. I’m nearing a point in my own project where it would be useful to have this kind of information.

[support]

Hi,

We could add an option to specify a list of “system” directory prefixes in the VisualGDB Project Properties and a button in the profiling report pane to hide symbols defined inside those directories. Would that work for you?

[andrew.bentley]

That sounds like a good approach to things.

Once concern I have with it is building and executing tests on a remote server. I haven’t worked a whole lot with gcov, but it appears to produce a separate gcov file for each source file (as opposed to one for each object file). I can see the project gcov files get copied back into the source file directory, but what about gcov output for the corresponding system files, where do those get copied to? I want to make sure the remote use case is covered by whatever solution we come up with.

Thanks,
Andrew

[support]

Hi,

No problem, please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.3.2335.msi

We have added a context menu command to the coverage report viewer to hide files from a given directory (and a corresponding option to the Code Coverage page of VisualGDB Project Properties).

With gcov files, they are created per translation unit, not per source file, so VisualGDB will automatically locate all the relevant files and build a searchable report from them.

[andrew.bentley]

support,

This is very close to what I are looking for. I have a couple of comments.

• While filtering like this makes it much easier to identify which relevant files are being tested, filtering does not allow recalculation of the overall  statistics. I would like to exclude system files from those statistics so we can get a quick summary. If it can recalculate on the fly that would be great, but I would be content even if it required rebuilding and rerunning the test suite.
• I really like being able to right-click and add files. Excellent feature.
• There are an awful lot of files being added to the exclusion list. For example, the boost library contains dozens of different directories. Allowing wildcards to automatically filter subdirectories would shorten this list, although with the right-click feature above perhaps that’s not critical.

Thanks,
Andrew

Attachments:

You must be logged in to view attached files.

[support]

Hi,

Good to know it works. Unfortunately the statistics is currently computed when the report is built (it involves a few advanced cases like multiple sources reporting the same function implemented in a header file), so the filters won’t affect it. We might be able to improve this in the next major release, but we won’t be able to push this into v5.4, sorry.

The entries in the exclusion lists are actually prefixes (e.g. /usr will cover both /usr/local/include and /usr/include). Right-clicking on the files will add the entire directory of this file to the exclusion list, and then you can fine-tune via VisualGDB Project Properties (e.g. exclude the parent directory).

[Author]

Posts