A Detailed Look At Testing A Component

Introduction

An LCFG component is installed by submitting a pair of RPMs, and making relevant entries in profiles and header files. However, before using a component, it's usually a good idea to test it! This can be done using the LCFG Test environment, which is supplied as part of the LCFG component-building mechanism - and is enabled by the presence of 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.

Building A Component

In order to test a component using the LCFG-provided test mechanism (as distinct from installing a component on the local machine and running ad-hoc tests), some component source files need to be included - see 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)/resources
When 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    = /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
For shell components, the variable should be included in the .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").

Installing A Component

Having created our component, two testing/develop RPMs will have been generated - one for the component installation, and one for the server defaults file.

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)

Testing A Component

Normally, to run the tests, you want to do "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:

  1. configure local files (generate files from the .cin versions).
  2. delete & recreate any required ./TESTING directories
  3. run tests in ./test/tests/test001 as invoked by ./test/run
By default, the tests run by ./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.