in reply to Writing tests when you don't know what the output should be

Trust me. It's worth the time. In four months after you think you've got it working and you make a change, how do you know you haven't broken something far away?

Can you provide more details on your project?

If you don't create all of the possibilities up front, how will you know if your code is doing the right thing?

  • Comment on Re: Writing tests when you don't know what the output should be

Replies are listed 'Best First'.
Re^2: Writing tests when you don't know what the output should be
by nysus (Parson) on May 17, 2016 at 20:28 UTC

    The module grabs the names of the files. Each file is a .pl file. Each file has a data file associated with it, derived from the name of the .pl file, that it stores its data in using storable. Each data file is basically like a little mini database consisting of a keyed hash with objects as values. The objects represent events in the real world. The purpose of this module is to look for duplicate events across the different data files by analyzing the start date, start time, event name and possibly other fields. The data structures are the same across the data files.

    $PM = "Perl Monk's";
    $MCF = "Most Clueless Friar Abbot Bishop Pontiff Deacon Curate";
    $nysus = $PM . ' ' . $MCF;
    Click here if you love Perl Monks

[reply]
[d/l]

In Section Seekers of Perl Wisdom