Generating Test Coverage Reports
Let's learn how to measure what is and isn't tested, and strive to improve the situation.
We'll cover the following...
Having tests in place, we should somehow measure what's tested and what isn't and strive to improve the situation. It's best to use automated tools that will collect and report this information.
Adding tests to such a small solution isn't incredibly challenging. The real difficulty comes with slightly more advanced and longer programs. Over the years, we have found that as we approach over 1,000 lines of code, it slowly becomes hard to track which lines and branches are executed during tests and which aren't. After crossing 3,000 lines, it is nearly impossible. Most professional applications will have much more code than that.
Code coverage report
To deal with this problem, we can use a utility to understand which code lines are "covered" by test cases. Such code coverage tools hook up to the SUT and gather the information on the execution of each line during tests to present it in a convenient report like the one shown here:
These reports will show us which files are covered by tests and which aren't. More than that, we can also take a peek inside the details of each file and see exactly which lines of code are executed and how many times this occurs. In the following screenshot, the Line data column says that the Calc
constructor was run 4
times, one time for each of the tests:
There are multiple ways of generating similar reports, and they differ across platforms and compilers, but they generally follow the same procedure: prepare the SUT to be measured and get the baseline, measure, and report.
LCOV and Gcov tools
The simplest tool for the job is called LCOV, and it's a graphical frontend for gcov
...