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
