8. Building, executing and debugging the tests, analysing the results

8.1. Building and installing the tests
8.2. Creating a test package
8.3. Executing and debugging the tests

8.1. Building and installing the tests

Before building the tests, we need to invoke Autoconf and Automake tools to generate necessary files (configure file, top-level Makefile, etc.). Autoreconf will call these tools with appropriate arguments:

autoreconf --install

Now we can configure our test package:

./configure --prefix ~/some_dir

The tests will be configured to install in ~/some_dir directory.

By default, the value of $CC environment variable is used to determine the compiler. If you need to use a specific compiler for the tests, you can specify it when calling configure:

./configure --prefix ~/some_dir CC=<path_to_some_other_compiler>

Now we can call make to build the tests and then make install to install them to the chosen directory.

8.2. Creating a test package

To create an archive with the distribution of the tests (the package), execute make distcheck or make dist

make distcheck not only creates the package but also checks its validity in several ways.

8.3. Executing and debugging the tests

To run the tests installed to ~/some_dir directory, we can execute


The results of the test run (the execution log) will be in ~/some_dir/example01/results/test.journal

If we execute the tests for GLib Arrays group provided with this manual, we may see that some of the tests have failed and the log file (results/test.journal) contains records similar to the following one:

[Test #14 begins]
    Test target(s):
    Checked requirement: {g_array_append_vals.02}
    Checked requirement: {g_array_append_vals.02}
    The length of the array is 14 (should be 14).
    Checked requirement: {g_array_append_vals.08}
    The element with index 10 has incorrect value.
    Requirement failed:
    Adds len elements onto the end of the array.
[Test #14 ends]
[Result] FAILED

In this case, the problem is in the tests rather than in the functions under test. To debug the tests, we can use the sources that T2C has already generated. But it could be more convenient to prepare a special version of the source file and makefile for the test that contain as little as possible besides the sources of the tests themselves: no special execution framework support, stubs instead of the most T2C API definitions, etc. Just a plain C source file and a simple makefile to build an executable from it.


Such possibility would also be useful when preparing demo-examples for the problems found in the functions under test (for upstream developers, for example), etc.

T2C can do this for us using c_minimal target:

t2c --target=c_minimal example01-t2c example01-t2c/src/glib_arrays.t2c

This will create glib_arrays.c and Makefile in example01-t2c/tests/glib_arrays/.

To build the test from the newly generated sources, change current directory to example01-t2c/tests/glib_arrays/ and execute

make clean && make debug

Now we can execute


to run all the tests defined in glib_arrays.t2c, or

./glib_arrays 14 15 17 10

to execute only the tests with numbers 14, 15, 17 and 10, in this order (the numbering scheme is the same as in the log and in the comments in the generated .c file with the tests).

Let us analyse the test executable with valgrind:

G_SLICE=always-malloc valgrind --log-file=vg001.log ./glib_arrays

Some of the messages output by valgrind to vg001.log are shown below.

==26520== Conditional jump or move depends on uninitialised value(s)
==26520==    at 0x8049E7C: test_3_1 (glib_arrays.c:1371)
==26520==    by 0x805552D: main (glib_arrays.c:8667)
==26520== Conditional jump or move depends on uninitialised value(s)
==26520==    at 0x804A1E0: test_3_2 (glib_arrays.c:1472)
==26520==    by 0x805552D: main (glib_arrays.c:8667)

Valgrind has spotted an error. The tests test_3_1 and test_3_2 are the first two tests generated from the third <BLOCK> in the .t2c file.

It seems, there is a misprint in the source code of the tests (glib_arrays.t2c, line 329 which corresponds to lines 1371, 1472, etc., in glib_arrays.c):

if (g_array_index(ga, TYPE, i) != data[i + old_len])

Plus sign should be replaced with a minus:

if (g_array_index(ga, TYPE, i) != data[i - old_len])

If we fix this misprint and generate, build and execute the tests once again (in c_standalone or c_minimal target) like it is described above, there should be no more spurious failures.