Code / Appnel Solutions 

On Testing

A recent thread on the cgi-app mailing list discussed testing that is really worth noting.

The key statement came from Jason Purdy when he said:

My advice would be to factor your code such that the code is separated into a testable module.

I admit to being slow to developing tests for my work once I did I came to realize that this statement above to be very true. Once writing tests where introduce in to my development process it changed how I wrote the code, not only to make writing tests easier and more thorough, but for the betterment of the code.

I’ve yet to break the habit of writing code and then the tests. (Testing advocates suggest you write tests upfront.) This one has been harder for me because often start from existing code, experimenting and capturing ideas that slowly gets molded into working code. On a few occasions I had a written a piece of code before I realized I was doing it.

I’m strange though and this is not an argument or excuse to follow good form.

Bill Costa concurs and expands on Jason’s statement:

This is excellent advice. Try and write your ‘back end’ modules so that a browser is not needed to exercise them. Then for testing you write a simple script that can be executed from the command line to fully test all of the services provided by your module. It then becomes a much simpler matter to create a test script that probes all of the expected operations as well as the boundary conditions and even pathological cases. In other words, don’t assume that service will always be given sane data from the front end. Test for possible inputs that “should never happen”.

The book cited earlier will help you write those command line test scripts in a very efficient manner using well established and vetted test harness modules.

“The book” here is Perl Testing: A Developer’s Notebook by Ian Langworth and chromatic. Like others in the thread, I recommend it if you really want to learn about testing in Perl.

Bill continued:

An added benefit to this approach is, when you later have to make a change to one of these modules, you can run your tester to make sure you didn’t accidentally break something else in the process.

In this way testing the final app itself should be more about usability testing with humans rather than actually trying to test the correct functioning of lower level functions through the app’s web interface.

Agreed. It’s an ideal that all developers should aspire to achieve. It’s easier said then done, but I do believe it pays dividends the closer you get to this ideal.

After starting to write tests for my CPAN modules I decided that I wanted something for my MT plugins — especially the big and involved ones like Feeds.App and Tags.App. I ended up creating my own testing framework for MT that has a lot of room for improvement, but works pretty well and gets the job done. The framework was written for MT3 systems and then quickly hacked to support both MT3 and MT4. It’s available under the Artistic License like Perl. Contributions are always welcome.