Two separate notes, for the price of one.
I decided to try the Perl testing frameworks with one of my scripts which badly needed refactoring. I wanted to move the messy textfile configuration into a SQLite database and make some general cleanups and speedups.
Read Test::More, it seemed like overkill, so went into Test::Simple. What the ?! It wants you to test a module ? the hell you say. This isn't a module, this is a script.I want to test the different subroutines, to make sure they're passing tests. Err.. you can't do that ? How strange. Is testing only for module authors or am I missing something ? What's Mr. Hack-A-Lot, who's never done test driven development using Perl, and doesn't want to write a module to replace his script, supposed to do ?
The other note: if I didn't know about not designing and coding before inspecting the data, I do now. Tried to make a mapping table, used a HashMap. Then I look at the actual data and discover that some fonts actually represent the same character in different ways, depending on how it's used. So, one unicode character can be two separate character values in a custom font. That pretty much puts my HashMap idea into the dustbin, where it belongs. I can't keep track of the context without using a different structure.
You have several options. I usually prefer to turn scripts into modules, because that's just me -- I find it leads me to better designs.
Another option is to put a caller() block at the top of your script, so you'll execute the main subroutine only if called directly. That'll let you require the script from a test script.
You could put the test code in the script and run it based on the presence of a command-line or environment variable.
You could treat the whole script as a black box, opening it in a separate process, giving it known input, and checking the output.
Those are in order of my preference.
