|Perl: the Markov chain saw|
I do the following:
If the tests pass I check the changes into cvs.
To install, on the prod server I do make install (more or less).
It's easy to develop web apps this way when you use Apache::TEST (A-T). You can have an highly customized apache config run your tests. And A-T track dependencies too. All in cvs.
My current problem seems to be that I'm stuffing too many tests in it. Testing business rules for base tables, for example. Maybe every city in the city table for some web app must have at least one row in the apartments table. It's easy for me to make a test that checks that, only that test is not really related to the web app, other than it makes sure the data is as we expect.
I started checking the data (every city must have an apartment) using the web app (Test::WWW::Mechanize running inside of A-T), but checking the module that pulls the data makes more sense.
So what I'm working on now is having a subdir in the test dir, t/, that holds these back end tests. At night I'll run all the tests, and during the day, I'll run only the tests that are directly related to the web app before checking in during the day.
Apache-Test really allows you to carry your custom httpd.conf with your perl modules and your perl scripts and your tests suite in cvs (or subversion). It's not that hard to test things using A-T. I even have a test that does html validation and link checking for my static pages - all my static pages are in cvs (and all are build using ttree from Template Toolkit). For logging I use Log::Log4perl, btw.