How to properly set up GLib testing framework with autotools

Question

How can I properly set up the GLib testing suite with autotools ? My project already uses GLib. What are the minimal modifications I must do to set up a test suite ? Is there some m4 files to include ? How to launch the tests then ?

Thank you

Answer 1

since GLib 2.38, the recommended way to integrate the GLib test suite with the autotools build system is to rely on the TAP (Test Anything Protocol) driver inside autotools themselves. before 2.38, the test suite was based on a particular brand of nastiness, with a custom set of make rules, and a python script running and coalescing results. it's still possible to use that, and most of the things below apply, but my suggestion is to use the TAP drivers support, as that's what going to be supported from now on.

GLib ships these three files:

• a m4 macro file to handle the command line arguments: https://git.gnome.org/browse/glib/tree/m4macros/glibtests.m4
• a Makefile to be included into the Makefile.am of each test directory: https://git.gnome.org/browse/glib/tree/glib-tap.mk
• a small shell wrapper for launching each test suite using the right options: https://git.gnome.org/browse/glib/tree/tap-test

these files need to be copied from the GLib repository into your own, as they are still moderately new — but in the future they will be installed in the same $prefix as GLib, so projects will be able to rely on their existence, like they already do for the introspection generation macros.

I'm going to assume that your configure.ac has these two directives to set up the macro and auxiliary directories:

AC_CONFIG_MACRO_DIR([build])

so you will have to place the glibtests.m4 inside your $top_srcdir/build directory; the glib-tap.mk file can be in the $top_srcdir, though I do prefer to put everything autotools-related in the same directory; finally, the tap-test launcher needs to be in the $top_srcdir, though you can change its location by modifying the LOG_COMPILER variable inside glib-tap.mk.

you will need to add a GLIB_TESTS directive in your configure.ac. this directive will add the configure options to enable installing tests, as well as an option to enable always building the test suite when building the rest of your project, as opposed to only building it when running make check. the default for both options is disabled.

I'm also going to assume that your test suite is going to be under $top_srcdir/tests, so in the $top_srcdir/tests/Makefile.am you will need to include glib-tap.mk with the correct path:

include $(top_srcdir)/build/glib-tap.mk

then you will need to use the variables defined inside glib-tap.mk to add the test binaries and data. for instance, if you have the following test unit files:

foo.c
bar.c
baz.c
blah.c

some test data that comes with the distributed tarball:

foo.data.txt
bar.data.txt

and some autogenerated data that it's supposed to be rebuilt every time you build the test suite:

blah.data.txt

you will need to declare:

# test binaries
test_programs = \
    foo \
    bar \
    baz \
    blah

# data distributed in the tarball
dist_test_data = \
    foo.data.txt \
    bar.data.txt

# data not distributed in the tarball
test_data = \
    blah.data.txt

and that's it. now, every time you run make check in your build, the test suite will be built and executed, and you'll get a report with the passed and failed test units.

if you don't have, or cannot depend on, a recent version of GLib, then instead of using glib-tap.mk and tap-test you will need to copy glib.mk in your project, and include it in the same way as outlined above. the rules are exactly the same, so you won't need to change them. each unit in the test suite will, in this case, run using the gtester Python script installed by GLib in a system location.

finally, if you want an example of how the GLib testing system integrates with a (small) library, you can look at JSON-GLib: https://git.gnome.org/browse/json-glib/