sf at sfritsch
May 4, 2012, 2:27 PM
Post #1 of 6
(222 views)
Permalink
|
|
Adding unit tests to httpd?
|
|
Hi,
there are some parts of httpd where unit tests would allow easier
testing or more complete test coverage than tests written for the perl
framework. Examples include the ap_pcfg_* functions, the varbuf API,
the regex plus API, and new interfaces that are not yet used by any
module.
Therefore, I am thinking about adding unit tests to httpd. For maximum
usefulness, such unit tests should be able to access functions that
are not exported (including static functions). I could think of a few
ways to achive this:
1) Add some preprocessor magic that exports the required functions
when compiled with a special configure option. Then, put the unit
tests into a separate module that executes them during server startup
(and exits instead of allowing the startup to continue).
2) Put the unit tests into a separate executable using source files
that #include the .c file(s) that contains the tested functions. This
is a very hackish approach and has problems with source file
interdependencies. It would likely require special linking magic.
3) Put the unit tests into the same httpd source files that contain
the functions to be tested. They would only be compiled in with a
special configure option. Httpd would then, if some magic -D variable
is defined, execute the tests during server startup and exit instead
of allowing the startup to continue.
I think option 3) is the least hackish approach. Is it problematic if
the unit tests are compiled into the httpd executable and modules,
increasing their size? Of course, one could also compile everything
twice, once for unit testing and once for production use. Newer gcc
versions also have attribute "cold" that can put functions into a
separate section, which would prevent the unit tests from using
significant memory or reducing cache locality during normal operation.
Any comments?
Cheers,
Stefan
|
