|P is for Practical|
Using HTTP::Recorder to help start building tests with WWW::Mech is smart. Using Test::WWW::Mech is better. But using Test::WWW::Mech inside of Apache::Test is really powerful.
Apache::Test, a subproject of the Apache HTTP Server Project, provides the framework for what web apps need. What do web apps need? Well, a configured web server.
Configuration to determine:
You don't really care about those things when you're testing. You just want to think about the tests.
Apache::Test (A-T) takes care of all of that for you, you just provide the tests.
And A-T works great with CVS (and SVN). Sure you can use test suite build only on Test::WWW::Mech in cvs, but it's often inflexible - the tests are often in a different location that the web server. A-T essentially bundles the httpd.conf with your perl modules and your perl scripts and your tests. Everything you need is in one place. So with A-T you can just check out a copy of your code in a different sandbox and hack away. No need to tweak the httpd.conf files to point to a different location.
A-T, and test suites in general, make maintenance so much easier. Say you have a mod perl 1 app and want to move it to mod perl 2. If you have a test suite (either using A-T or not), you can run the test suite on it. But running the test suite on different version of perl and apache is really easy in A-T. I've seen A-T guru Geoffrey Young quickly and easily run a test suite on different combinations of version of Perl and Apache.
If you develop your web app with care you'll almost always have tests that test things outside of the web app. A-T can handle that for you to.
I'd say the biggest hurdle is setting up A-T, but you only do that once (per server configuration). And there are skeletons to help you do that.
A-T works with perl cgi scripts, Apache::Registry, mod perl and even php.
The docs are helpful - I'd like to help reorganize them but have done nothing at all to help yet.
In reply to Re: Application Testing: Custom Module or Perl Test Files?