test.mk
as one of the component source files.
A component consists of a set of files used to generate the run-time script, and there are LCFG tools and templates available to create these scripts and associated files.
lcfg-skeleton
, from where the ./test
directory may be copied (if not already present) which should -
excluding CVS files - give:
./test.mk ./test/log ./test/run.cin ./test/data/test001.log ./test/resources/test001.cin ./test/results/test001 ./test/tests/test001.cin
The test.mk
file is used to configure the testing
environment. If present, this causes the following to be defined by
lcfg.mk
(included from buildtools.mk
,
which is included from ./Makefile
):
TESTING = yes => `test -f ./test.mk && echo yes` TESTROOT = ./TESTING => `pwd`/TESTING TESTCONF = $(TESTROOT)/conf TESTDATA = ./test => `pwd`/test TESTRUNSCRIPT = $(TESTDATA)/run- and the following directly from
./test.mk
:
TESTRES = $(TESTROOT)/resourcesWhen present,
test.mk
also causes buildtools to
automatically define the variable @TESTSHELLV@
(or
@TESTPERLV@
if using Perl). These variables contain local
redefinitions for all the system status and log files used by the
generic component. For example, assuming a test component
"basic
", packaged as "lcfg-basic
":
_LOGFILE =For shell components, the variable should be included in the/src/lcfg-basic/TESTING/basic.log _STATUSFILE = /src/lcfg-basic/TESTING/basic.status _RUNFILE = /src/lcfg-basic/TESTING/basic.run _LOCKDIR = /src/lcfg-basic/TESTING/lock _ROTATEDIR = /src/lcfg-basic/TESTING/logrotate.d _RESFILE = /src/lcfg-basic/TESTING/resources _CONFDIR = /src/lcfg-basic/TESTING/conf _TESTING = yes
.cin
file when sourcing the ngeneric component:
@TESTSHELLV@ . @LCFGCOMP@/ngeneric(when not testing,
@TESTSHELLV@
is null, and the above
just gets expanded to ". /usr/lib/lcfg/components/ngeneric
").
While testing, the make target "devinst
" (which bumps-up
the RPM release number) can be used to build and install the component
RPM if there have been changes (otherwise, just use "rpm
-ivh
" or similar to install the RPM). Note that - even for
general testing - the defaults file needs to be installed on the LCFG
master server (currently pointed to by the lcfg-master
DNS alias).
While testing, the component and version resources need to be added to the profile (once testing is completed, they can be moved to the appropriate header file):
!profile.components mADD(basic) /* test component */ !profile.version_basic mSET(1)
make testall
"
(the "testall" target is defined in
/usr/include/buildtools.mk
, and calls "make
tests
" - defined in the local Makefile
- to
configure the component files and then call "make
runtests
", which is defined back in
buildtools.mk
). This can be done without creating or
installing any RPMs.
When testing, two directories are used: ./test
(which
should exist) and contains the tests to be run, the results to be
compared, and the resources to use when testing, and
./TESTING
(which is created during testing) and contains
results of running the tests. The ./test
directory
initially contains:
log |
empty log file |
---|---|
|
|
run.cin |
LCFG build-file for top-level test-run file |
|
|
data/test001.log |
default log format(?) |
|
|
resources/test001.cin |
proto resources file (used to generate ./TESTING/resources) |
|
|
results/test001 |
sample output to check test output |
|
|
tests/test001.cin |
LCFG build-file for list of tests to perform |
The testing process ("make testall
") is a follows:
.cin
versions).
./TESTING
directories
./test/tests/test001
as invoked by
./test/run
./test/run
are the start,
stop, and configure methods for the component (run in debug mode). The
./test/run
file loads
/usr/lib/lcfg/buildtools/testlib
, which defines a
function useresources()
to generate a resources file,
./TESTING/resources
, using values from the configuration
file in the ./test/resources
directory. The default
tests file is test001
. The results of testing are logged
to files in the ./TESTING
directory:
% ls -1F ./TESTING basic.log basic.log.err conf/ errcount lock/ resources results/ time %Once the tests are run, the results are placed in the
./TESTING
directory, and the output is compared with the
model results in the ./test/results
directory.