So make tests that just run the scripts and then examine the outputs. If
there are unwanted side effects you can't undo from the test then you need
to modify the script in some way.
Is this where 'do' comes into use?
This is why writing the tests *before* writing the code makes life so much
easier. Still, that's hindsight.
um... I have one problem with that.
I often don't know what the script is supposed to actually do until I'm
already writing it. Most of these are variations on a theme of log
analysis or data mining.
Could this be addressed by an iteritive approach of:
find a "feature" you want to identify.
classify that "feature" as a good/bad/ugly feature.
create a test script which at least identifies the input string
("feature") and the expected classification ("too many cooks") via a
function (maybe only one function?)
example:
my $inputstring = "WARNING something goes here";
is( disposition($inputstring), "UGLY", "disposition" );
my $inputstring = "INFO successfullly finished doing...";
is( disposition($inputstring), "GOOD", "disposition" );
my $inputstring = "ERROR something went wrong";
is( disposition($inputstring), "ERROR", "disposition" );
and then back to the modules to get the function disposition() to
properly identify each of these conditions..
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
