Re: Testing Non-module code

The reason the tests in examples use the modules is simple: that way, the tests can be in a separate file, and not in the main program file.

The one thing you don't want to do is to be testing a copy of your routines: sooner or later (probably sooner) you would forget to update the testing copy from your current copy, and you would be wondering why the tests aren't affected by the changes you made. Using the same modules from the test program as well as from the program you're developing neatly avoids that.

But there is an alternative. You could use Test::Simple (or any of the other test tools) from within the target application itself, probably only when it was called with a specil parameter like --run-tests.

When such a parameter was given, you would simply run a testing procedure instead of the regular run procedure.

I hope this makes things a bit clearer. Happy testing!

Comment on Re: Testing Non-module code Download Code

Replies are listed 'Best First'.
Re: Re: Testing Non-module code by paulbort (Hermit) on Mar 16, 2004 at 18:59 UTC
I also have a lot of procedural code, some modules, and some subroutines. The (partially implemented) plan here is: 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!	[reply]
Re: Re: Re: Testing Non-module code by grantm (Parson) on Mar 17, 2004 at 08:39 UTC
Use WWW::Mechanize in a test script to test the CGI If you're using Apache, you might like to check out Apache::Test. I've found it to provide a very usable framework.	[reply]
Re: Re: Testing Non-module code by pboin (Deacon) on Mar 16, 2004 at 14:23 UTC
I see what you're saying -- it directly addresses one of my questions, and that is: how to separate testing behavior from 'real' operation. To some extent I'm already doing that, I have a sub called 'dbg' that prints the tell() and the passed message, but only when debug is turned on via getopt. I could easily do the same type of thing, but with testing. Thank you (both) very much. I work alone from home, and I love it, but the one thing I really miss (and it's a big negative) is peers. I can get pretty far down the 'wrong road' sometimes w/o someone to call me on a dumb idea.	[reply]


Keep It Simple, Stupid
	PerlMonks