For mod_pagespeed <http://code.google.com/speed/page-speed/docs/module.html>we do 2 of the 3 testing modes discussed.
We have the majority of our code running independent of Apache so it can be aggressively unit-tested with googletest<http://code.google.com/p/googletest/> . We also have automated system-tests with our module running inside of Apache. They are pretty painless once it is set up. We use 'wget' for control and observation. This doesn't have nearly the functional coverage of the unit tests but does check that stuff is hooked up and working in the system: http://code.google.com/p/modpagespeed/source/browse/trunk/src/install/system_test.sh <http://code.google.com/p/modpagespeed/source/browse/trunk/src/install/system_test.sh>We also have stress tests that work in a similar way. http://code.google.com/p/modpagespeed/source/browse/trunk/src/install/stress_test.sh Our development flow integrates the system-test into the pre-submit checks; it really doesn't take very much time at all. It does require that every developer has a debug instance of Apache into which they can automatically copy modules and restart servers. We have talked about writing a 'fake<http://en.wikipedia.org/wiki/Mock_object>' Apache so that we could properly unit-test all of our code. But given the speed of automated system testing, it seems unlikely we'd focus on this anytime soon. Hope this helps, -Josh On Mon, Nov 22, 2010 at 5:05 AM, Edgar Frank <ef-li...@email.de> wrote: > 2010/11/11 Sorin Manolache: > >On Thu, Nov 11, 2010 at 08:11, Edgar Frank <ef-li...@email.de> wrote: > >> I've written a handful of modules for httpd. I'm now looking for a way > to setup some unit tests. We have continuous integration running, so I want > to supply some tests, starting from compiling against httpd to basic > functionality to more elaborate feature tests. > >> > >> I wonder how to unit-test this, as the prerequsites are rather > complicated. The tests would have to setup a httpd, provide a config, > compile and install the modules. As you don't want to modify the modules > themselves, you have to run a bunch of requests and monitor expected output > - maybe measuring coverage or running valgrind on the way. > >> > >> I see no way to run "real" unit tests as you would have to emulate httpd > and run your modules against it, as most of the code is httpd or at least > highly APR dependent. I see no point in emulating httpd as you would have to > implement every little detail - httpd specific behaviour (e.g. in version > bumps) is one important thing to test IMHO. > >> > >> So, has anyone some experience with this, some suggestions, howtos or > tutorials? Any help would be greatly appreciated. > > > >In our group we unit test only parts of our modules. We unit test the > >callbacks and their sequence (a sort of poor-man's emulation of > >httpd). We populate a request_rec structure and then we pass it to the > >various callbacks. > > > >Our callbacks are mainly wrappers around bigger functions that are > >httpd-independent. The apache filters are tested in this way. > > > >The part that needed more code in order to emulate httpd was the > >subrequest infrastructure. > > Thanks for your reply. Unfortunately this is the way we're trying to avoid > if possible. > > Has anyone else some hints or best pratices, besides emulating httpd? Is > there even another way? > > Regards, > Edgar >
