Unit testing is great, code coverage is great and continuous integration servers are great; but what isn’t great is combining all three into something useful!
If you are coding in Java then code coverage is fantastically simple but what if you use C++ and GoogleTest and want the same level of graphification? Luckily it is also simple if you know how – so you’re in the right place.
The scenario here is that you have a C++ project being built on a Jenkins/Hudson continuous integration setup and you also use Google Test for your unit tests. The software required for this is GCC 4.7 which should contain a tool called gcov, this will create the actual coverage files for your executable but will require some additional linker and library options to be added to your build scripts or make files. The final piece of software required is called gcovr, this is a Python script that is designed to read the output files from gcov linked executables and convert it into an XML format that can be read by the Cobertura plugin in Jenkins/Hudson.
It is a good idea to add a separate make target for coverage as it requires the executables to be built with no optimisation and a lot of debug symbols, so not very useful for production environments.
Add the following to your CPPFLAGS –
-fprofile-arcs -ftest-coverage -O0
And this to your LDFLAGS
So for example you could have a section in your makefile that looks like this (assuming the test target builds your unit test.) –
coverage: CPPFLAGS += -fprofile-arcs -ftest-coverage -O0
coverage: LDFLAGS += -lgcov
After you have run the coverage build target you then have to run the test executable, this generates .gcov files that describe which lines of code are covered and by what functions.
Then ensure that you can access the gcovr script and run it with the following arguments –
chmod a+x ./gcovr
./gcovr --gcov-exclude=".*gtest.*" -x -d > coverage.xml
The –gcov_exlcude will remove any unnecessary parsing of files from the GoogleTest framework. The output is placed into the coverage.xml file which can then be accessed from Jenkins by adding a new Post-Build Action from the job configuration page.