Generating The Test Driver

Building an efficient and extendable testsuite is an essential part of the project.

Hooking your testsuite to the build system

The build system should allow you to run tests from it. To do this you will need to add a rule to the Makefile.am which is located in the tests folder.

check-local:
        ./testsuite.sh

In the makefile check-local is an automake directive that allows you to add steps to the check rule defined in the Makefile.am at the root of the project. The doc of automake for this part is here.

You are free to implement your test suite in the technology you prefer.

Warning

The commands that are run in the check-local rule only run after the unit tests so if the unit tests fail the check-local rule will not be run.

Hooking your unit tests to the build system

Unit tests are already given in the given code. They allow you to unit test certain parts of TC, and are notably used in lib/misc.

You can easily add them for that you just have to add a C++ file which contains the different tests, then add them in a make file.

By convention on TC the unit tests are next to the tested features. For example in lib/misc the tests for the Symbol class are defined in test-symbol.cc. Unit tests can be registered in the build system thanks to the check_PROGRAMS variable.

check_PROGRAMS += %D%/test-symbol

This registers test-symbol.cc as a unit test program. The variable check_PROGRAMS and a global variable that contains all the files compiled as test files. It is defined in Makefile.am, the build system root.

Here is an example of C++ test code.

using misc::symbol;

int main()
{
  const symbol toto1("toto");
  const symbol toto2("toto");
  const symbol titi1("titi");

  // Checking symbol.
  //<< Testing set size.
  assertion(symbol::object_map_size() == 2);
  //>>
  assertion(toto1.get() == "toto");
  ...
}

Maintaining multiple builds using autotools

Unless your whole test infrastructure is embedded in a single file (which is not a good idea), we advise you to generate any script used to run your tests so that they can be run from a directory other than the source directory where they reside. This is especially useful to maintain several builds (e.g. with different compilers or compiler flags) in parallel (see the section on VPATH Builds in Automake’s manual) and when running make distcheck (see the section on Checking the Distribution), as source and build directories are distinct in these circumstances.

The simplest way to generate a script is to rely on configure. For instance, the following line in configure.ac generates a script tests/testsuite from the input tests/testsuite.in, while performing variables substitutions (in particular srcdir and similar variables):

AC_CONFIG_FILES([tests/testsuite], [chmod a=rx tests/testsuite])

The template file tests/testsuite.in can then leverage this information to find data in the source directory. E.g., if tests are located in the tests/ subdirectory of the top source directory, the beginning of tests/testsuite.in might look like this:

#! /bin/sh
# configure_input

# Where the tests can be found.
testdir="abs_top_srcdir/tests"

# ...

Another strategy to generate scripts is to use make, as suggested by Autoconf’s manual (see the section on Installation Directory Variables).