Easily debug unit tests with GDB

A while ago I developed an ANSI C based unittest framework that gives me the same comfort as the Qt’s unit test framework in C++, but small and portable for embedded ANSI C applications.

You can find the framework here on github: http://gergap.github.io/unittest

This framework also supports data-driven tests, which means you write one test case and can execute the same test n times with different data sets. When something goes wrong you need to debug this. Therefor you can pass the name of the testcase as commandline argument, which means only this testcase gets executed. If it’s a data-driven test this still gets called n times, so there is a second command line argument which contains the dataset name. Now the testcase gets executed only one time with the data set causing the problem.

This is already quiet cool and worked good. But I’m lazy. I didn’t want to open the correct file in the debugger, set the breakpoint, start the application with the correct arguments and let it run to the problematic line. So now I automated also this.

Now you can simply invoke the test with the option “-g” (like debugging in GCC), nothing more. Then the test will abort on the first error and creates a file called ‘test.gdb’ with all instructions necessary to debug this problem.
Then you start GDB with this file and you are there where you want.

Here is an example of the unittest output:

When you run the cgdb as shown in the output you jump right into the debugger with one breakpoint set at the start of the test case and one breakpoint at the error location. You can decide if you want to step to the error or if you simply hit ‘c’ (continue) to run to the error location. Sometimes it also helps to start history recording before pressing continue, so you can use reverse-stepping if you have missed an important line.

The generated test.gdb file which does the magic for you only contains three lines:

break test_strtouint16
break ../src/test/utiltest/strtoint.c:277
run test_strtouint16 padding

This new feature is not yet on github, but I’ll upload it soon.
I think it’s a really useful and simple feature.

It would be cool to see this in other unit test frameworks too in the future.