I also have a lot of procedural code, some modules, and some subroutines. The (partially implemented) plan here is:
in reply to Re: Testing Non-module code
in thread Testing Non-module code
- Use normal module testing for all the modules
- Ditto subroutines
- Use WWW::Mechanize in a test script to test the CGI
- For all of the other programs, have the test script build a proper environment (set inputs and such) and then qx// the script to be tested. Then use the Test::More functions on the results. (If the program was supposed to create file '/tmp/foo', then do ok( -e '/tmp/foo' ).)
An example of the last: the application I'm developing here has a series of Perl scripts that create and setup the initial database. The test script can test these by making sure there is no database of that name, then running the scripts in qx//, and checking to see if the database exists and has the right tables.
(Quick aside: Always generating your db from a re-runnable, extendable script comes in handy later.)
This will also work for scripts that are just supposed to read from one queue in the database and write to another: Set up something in the DB for the script to do, run the script, see if the output is good.
Spring: Forces, Coiled Again!