Next: , Previous: Autoconf macros, Up: Writing modules


4.7 Unit test modules

A unit test that is a simple C program usually has a module description as simple as this:

     Files:
     tests/test-foo.c
     tests/macros.h
     
     Depends-on:
     
     configure.ac:
     
     Makefile.am:
     TESTS += test-foo
     check_PROGRAMS += test-foo

The test program tests/test-foo.c often has the following structure:

The body of the test, then, contains many ASSERT invocations. When a test fails, the ASSERT macro prints the line number of the failing statement, thus giving you, the developer, an idea of which part of the test failed, even when you don't have access to the machine where the test failed and the reporting user cannot run a debugger.

Sometimes it is convenient to write part of the test as a shell script. (For example, in areas related to process control or interprocess communication, or when different locales should be tried.) In these cases, the typical module description is like this:

     Files:
     tests/test-foo.sh
     tests/test-foo.c
     tests/macros.h
     
     Depends-on:
     
     configure.ac:
     
     Makefile.am:
     TESTS += test-foo.sh
     TESTS_ENVIRONMENT += FOO_BAR='@FOO_BAR@'
     check_PROGRAMS += test-foo

Here, the TESTS_ENVIRONMENT variable can be used to pass values determined by configure or by the Makefile to the shell script, as environment variables. The values of EXEEXT and of srcdir, from Autoconf and Automake, are already provided as environment variables, through an initial value of TESTS_ENVIRONMENT that gnulib-tool puts in place.

Regardless of the specific form of the unit test, the following guidelines should be respected: