Testing Modules

ajt on 2004-01-22T21:07:19

For the last week I've been working on the back end of a "Who's Who" tool for the company intranet. To this end I've releaced one configuration module onto CPAN, suggested patches to others, and developed a third module to augment CGI::Carp.

Today I started work on the main utility module that will provide the guts of the code for the application. At the moment it adds the application specific layers to the more general modules, and includes well tested code from an earlier project.

We have some sensible coding standards, and I'm doing my best to stick to them. Code so far is fully documented and tested with a battery of tests. Though some of the tests are a bit artificial and I know will pass okay, there are brilliant for regression work as you tinker with things. It's funny at first, writing and testing in such a closed loop, but after a while, one becomes conditioned to "build", "test" and "smile" when All tests successful appears at the bottom of the screen.

The "Who's Who" application won't get released, it's probably too specific an application, but I will try and release as much as possible to the world. My boss doesn't understand open source, and will probably not like it, but I find it very helpful.

When I released Config-Trivial I got quite a bit of feedback just from cpan-testers, which helped remove several bugs. Even if no one else in the whole world uses the code, or sends in a patch, I do get some feedback which is always useful. Like money I'd like more feedback, but I can't complain when compared to others.

My next quandry is on the fate of CGI::Whinge. It's not that revolutionary really, and I'm sure everyone has written their own error handler of their own - so does this offer anything new or useful? The idea is that you have debug, warn and error, and each can send messages to a log file and/or the screen, and you can send different messages to the screen and log. So when your application is "live", if the user sees an error it tells them what they need to know, but logs a different more useful and technical detailed rich error in the logs. You can't use it to replace CGI::Carp, it's really an extension to it.