I am trying to make a coverage report using clang's llvm-cov on Mac. I'd like all instrumented files (ie all files in my build) -- not just files touched by my unit test -- to be included in the coverage report. Any files not touched at all by the tests should be marked 0%.
I've used lcov on Linux to do this in the past. You start with a 0% baseline coverage by running run lcov --capture --initial -- this creates coverage data file that contains zero coverage for every instrumented line of the project, as explained here. You then merge this baseline with a coverage report generated while running your tests. Unfortunately, I cannot find an equivalent to this command for llvm-cov.
Does anyone know if providing a 0% baseline coverage for a whole project is possible with clang?
You can specify the path to the symbol library
llvm-cov report xxx.so -instr-profile=xx.profdata
Related
I'm using meson and ninja as build system in my C++ project and I've configured catch2 as testing framework.
I was wondering how to perform code coverage with the tests that I've written.
I read this page, https://mesonbuild.com/Unit-tests.html but seems pretty unclear to me, can anybody help?
You should use one of coverage related targets: coverage-text, coverage-html, coverage-xml as described here. Or just coverage that tries all of these if possible:
$ ninja coverage -C builddir
Results are written to ./builddir/meson-logs directory.
Note that to produce html coverage reports you need lcov and genhtml binaries which are installed by lcov package.
I need to generate a report with coverage for just the new lines of code added with in each sprint. Other than using comments is there a way to do that using the gcov/lcov tool.
I have to do unit test coverage analysis on a large project with hundreds of c++ sources. It can be built only on Linux with an .sh script, and it doesn't compile the sources with gcov in mind, and it has multiple makefiles. I know this isn't very much info, but what would be a good approach to this?
I'm generating clover coverage reports (using Clover's maven plugin), and I'd like to exclude a certain package from the coverage reports (specifically, because it's UI code that intentionally isn't covered by my unit tests, but the reason doesn't really matter.)
I can see how to exclude that package from being instrumented (using in the plugin configuration), but I can't see how to exclude it from the report. The intended solution appears to be to use a Context; however, there is no package-level context available (only block, method, and statement.)
As far as I know, excluding classes from instrumentation should exclude them from the report as well. Answers to the question #9 of this thread seem to confirm this:
9) Are their independent options for filtering at both the instrumentation level and at the reporting level?
Yes. The clover-setup takes a fileset of files to instrument. All clover-report tasks also take a fileset of sources to report coverage on. The clover-maven2-plugin provides includes/excludes at instrumentation time and full Ant fileset support for filtering at report time. Ant filesets give you all the power of fileset selectors to determine which files to include/exclude.
Could you try to do a full clean build (delete all previously compiled classes and all files in the Clover DB) to ensure that previously instrumented versions of your UI classes are removed and check again.
If this doesn't work, please run you build with the debug option (mvn -X > output.txt) and attach the output and your pom.xml to this question.
Is it possible to use gcov for coverage testing of multi-threaded applications?
I've set some trivial tests of our code-base up, but it would be nice to have some idea of the coverage we're achieving. If gcov isn't appropriate can anyone recommend an alternative tool (possible oprofile), ideally with some good documentation on getting started.
We've certainly used gcov to get coverage information on our multi-threaded application.
You want to compile with gcc 4.3 which can do coverage on dynamic code.
You compile with the -fprofile-arcs -ftest-coverage options, and the code will generate .gcda files which gcov can then process.
We do a separate build of our product, and collect coverage on that, running unit tests and regression tests.
Finally we use lcov to generate HTML results pages.
Gcov works fine for multi-threaded apps. The instrumentation architecture is properly serialized so you will get coverage data of good fidelity.
I would suggest using gcov in conjunction with lcov. This will give you great reports scoped from full project down to individual source files.
lcov also gives you a nicely color coded HTML version of your source so you can quickly evaluate your coverage lapses.
I have not used gcov for multi-threaded coverage work. However, on MacOS the Shark tool from Apple handles multiple threads. It's primarily a profiler, but can do coverage info too.
http://developer.apple.com/tools/sharkoptimize.html