Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

tinman (2063)

tinman
  (email not shown publicly)

tinman spent a few years mucking around industry before going back to school for a Masters. Currently not enjoying the weather in North England..

He wrote Perl that looked suspiciously like C code in 1998, while working as an intern, and has been trying to cure that bad habit ever since.

Journal of tinman (2063)

Tuesday April 13, 2004
08:09 AM

tests ... and assumptions.

[ #18317 ]

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.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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

  • When I run into this, I usually pull the subs out of the main script and put them in a separate library file. Then you can require the library in the script and write a test script that can require it as well. Plus, as a bonus, you can now use the subs from other scripts. This is hard to do if your subs are using global variables, though.