Next: testing shell, Up: testing [Contents][Index]
A useful way to organise a test suite is to split it into a set of files: one for each module to be tested.
The file libmbfltest.sh must be sourced at the beginning of each
test file. This means that the variables that you set may interfere
with the ones in the library; this should not happen because the test
library prefixes variable names with mbfl_ or dotest_, but
one exception is TMPDIR: do not set it in your script, use
dotest-echo-tmpdir() to access that value. Handling files in tests.
To understand how the library works lets examine a bare bones example.
The function dotest should be invoked at the end of each module
in the test suite; each module should define functions starting with the
same prefix. A module should be stored in a file, and should look like
the following:
# mymodule.test --
source libmbfltest.sh
source module.sh
function module-featureA-1.1 () { ... }
function module-featureA-1.2 () { ... }
function module-featureA-2.1 () { ... }
function module-featureB-1.1 () { ... }
function module-featureB-1.2 () { ... }
dotest module-
dotest-final-report
### end of file
the file should be executed with:
$ bash mymodule.test
To test just "feature A":
$ TESTMATCH=module-featureA bash mymodule.test
Remember that the source builtin will look for files in the
directories selected by the PATH environment variables, so we may
want to do:
$ PATH=path/to/modules:${PATH} \
TESTMATCH=module-featureA bash mymodule.test
It is better to put such stuff in a Makefile, with GNU Make:
srcdir = ...
builddir = ...
BASH_PROGRAM = bash
MODULES = moduleA moduleB
testdir = $(srcdir)/tests
test_FILES = $(foreach f,$(MODULES),$(testdir)/$(f).test)
test_ENV = PATH=$(builddir):$(testdir):$(PATH) \
TESTMATCH=$(TESTMATCH)
test_CMD = $(test_ENV) $(BASH_PROGRAM)
.PHONY: test-modules
test-modules:
@$(foreach f,$(test_FILES),$(test_CMD) $(f);)
Next: testing shell, Up: testing [Contents][Index]