Performing Configuration Testing Using HTTPD-Test’s Perl Framework Page 2

Running All the Tests

You can run all the available tests by simply typing:

t/TEST

The above will use the httpd server identified by apxs, if you have it. If you want to specify an alternative server, use the -httpd command line option:

t/TEST -httpd /export/http/apache2/bin/httpd

Even on a relatively fast machine, it will take a while for all the tests to be run on the entire suite and for a summary to be generated. Also, be aware that the first time you run the tests it will probably compile a few modules and create a few tests. Once all the tests have been run, the output will likely be similar to this:

*** setting ulimit to allow core files
ulimit -c unlimited; t/TEST 'modules'
*** root mode: changing the fs ownership to 'nobody'
(60001:60001)
/export/http/apache2/bin/httpd  -d
/export/contrib/build/solaris/httpd-test/httpd-test/perl-framework/t -f
/export/contrib/build/solaris/httpd-test/httpd-test/perl-framework/t/conf/httpd.conf
-DAPACHE2 
using Apache/2.0.44 (prefork MPM)
waiting for server to start: .
waiting for server to start: ok (waited 0 secs)
server localhost:8529 started
server localhost:8530 listening (mod_nntp_like)
modules/access.........ok                                                   
modules/alias..........ok                                                   
modules/autoindex......ok                                 
                  
modules/autoindex2.....ok                                                   
...
modules/include2.......ok                                                   
modules/info...........skipped
        all skipped: cannot find
module 'info'
modules/negotiation....ok                                                   
modules/rewrite........skipped
        all skipped: cannot find
module 'rewrite'
modules/setenvif.......ok                                                   
modules/status.........ok                                                   
modules/vhost_alias....skipped
        all skipped: cannot find
module 'vhost_alias'
All tests successful, 7 tests and 6 subtests skipped.
Files=19, Tests=1086, 104 wallclock secs (57.64 cusr + 9.89 csys = 67.53 CPU)
*** server localhost:8529 shutdown

Note that this is truncated; typical output will be about two pages long.

What you are looking for here is a failure
when running the tests. Therefore, you can generally ignore “skipped” notices, they just
indicate that a required module is unavailable. However, take notice of them if you
thought the module was installed correctly.

If one of the module sets fails, it’s time to start drilling down and running test sets and, ultimately, individual tests.

Running a Specific Test

If you look in the t directory, you’ll see a
number of subdirectories that contain the tests for specific areas. For
example, the standard toolkit incorporates tools for checking the main Apache
setup, the configuration files, and PHP. To select which tests to run, just specify the name of the test on the command line to the TEST script. For example, to run the tests for the additional modules in Apache:

t/TEST modules

To run the tests on the include module:

t/TEST modules/include

The further down you drill, the more likely you are to find the precise location of the problem.

Tracing a Problem

Tracing a problem is actually a bit more
difficult than it at first seems. Even if you can determine which test within a
particular set failed, the only way you are going to find out the reason for
the problem is to check the test scripts and associated documents and determine
where the problem lies. With about 25,000
lines of code and sample documents to work through in the entire set, it’s not a job for faint hearted

You also need to be careful — just because
the script returns an apparently fine execution doesn’t mean there aren’t
problems. It’s always worth checking the error_log generated by Apache, located
in the t/logs directory. Often this can highlight errors raised by the server
that the test harness never picks up. But, always compare it to the test
scripts — you might find that the script is actually testing for a failure, in
which case, an error in the error log really indicates a success, not a
failure!