How to Test Code Coverage Using gcov Command on Linux

Figuring out how to test code coverage using gcov command in Linux can be the saving grace for any coder. Here’s how you can make the most of it. 

Dead Code: The Basics

When writing bigger programs, we often leave a good chunk of code that isn’t being used. This is referred to as “dead code”. Dead codes introduce a bunch of problems, from increasing complexity and runtime footprint all the way to being a huge security risk.

We might end up having dead code in our program for many reasons. Dead codes can appear by inheriting them from another codebase or by simply creating them on purpose in the first place for later use.

One such reason for creating dead code on purpose is getters and setters. Often we implement all the getters and setters at once but then end up not using some of them at all. Sometimes it is also possible to have dead code active during testing but not in production. Therefore developers don’t consider removing it.

What is Code Coverage Analysis?

Simply put, code coverage analysis aims to figure out how many lines of your code are being executed during testing.

Using this information, you can improve your test suite by modifying your existing test to increase the overall coverage or by implementing new ones. That’s why we’re here today to talk about gcov, an open-source code-coverage tool that lets us analyze how much each line of our code is being used.

How to use gcov in Linux

We’re here today to talk about gcov, an open-source code-coverage tool that lets us analyze how much each line of our code is being used. Using gcov is rather simple. It comes as a standard utility with the GNU Compiler Collection (GCC) suite.

We first need to specify a few flags when compiling our C/C++ code using GCC or g++. Once done, several are generated that allow gcov to analyze the lines of code being used.

Example of Using gcov to Analyze a Simple C Program

In this example, we will analyze the code coverage of a simple C program that runs the function foo() ten times.

We can compile our code using the following command:

$ gcc -Wall -fprofile-arc -ftest-coverage main.c

The flags listed in the command do the following:

• -Wall – tells the compiler to enable all warning messages (i.e. unused variables)
• -fprofile-arcs – tells the compiler to generate information indicating how many times each program branch is taken. It is meant to be used together with other flags such as -ftest-coverage or -fbranch-probabilities
• -ftest-coverage – uses the information provided by our previous flag and generates a .gcno file, which can be used by gcov to produce human-readable .gcov files, which calculate how many times each line of code is being executed.

$ ls

Aside from generating our a.out file, you can see that we also have a new file called a-main.gcno.

Now before seeing our code, the coverage we first need to run our program.

$ ./a.out

After running our program another file is generated, a-main.gcda.

Now we can run the gcov command:

$ gcov a-main.gcda

We can see that 100% of our code was executed, and if we look at the newly generated .gcov file, we can see how many times each line was run.

$ cat main.c.gcov

As expected our function foo() was run ten times.

Now we can try adding another function bar(), but we won’t be calling it.

If we repeat the steps from before, we will get the following output from our .gcov file.

$ gcov a-main.gcda

As you can see only 70% of our code was executed.

$ cat main.c.gcov

 We can see that our function bar() wasn’t executed and that is represented by the ####.

When discussing what percentage of coverage should be aimed for, it’s hard to give an exact answer as it varies from situation to situation. You might have a high rate of coverage, but certain critical parts of your program might not be properly tested. 

On the other hand, trying to reach a high code coverage. Or even 100% for that matter, could waste a lot of time and money when it might not have been necessary in the first place. With everything said, the general rule is that you should aim for anywhere between 80% and 95% coverage. 

As we’ve already mentioned, dead code can not only lead to having your program contain excess unused code. Which will increase your program size. And in some cases, even affect performance, but it can also be a security risk. 

Hence, we’ve discussed in detail how to test code coverage using gcov command on Linux OS. Why it is essential, and how you can effectively use it. 

If this guide helped you, please share it.