The pragmatic shortcut to the second point is to define a range of valid inputs, and to only ensure that the code works for that range.

So, for your example, a reasonable initial definition would be "$a, $b are numbers". If the input does not comply with the specified criteria, then the user gets what they deserve (such as Argument "hello" isn't numeric in multiplication (*), if they've got warnings enabled.)

That way, the developer doesn't have to waste time testing that behaviour, and possibly more importantly, the code doesn't have to waste time sanity checking its inputs. Of course, if it turns out that the function is frequently called with nonsensical parameters, then it does become worth guarding against. But in this specific case, it's reasonable to realise that the arguments should not be strings. Obviously, there are case where it's not so intuitive.

Next you'll realise that I've reduced your test cases back down from 49 to 1. Hooray! Except that I'm wrong: large numbers will still cause potential problems. There are now two intepretations of this though: either there's an error in the code, or there's an error in the specification. In this case, it's probably easier to change the specification, to include the restriction that abs($a)<some value (such that the operation works). Then, when this condition is broken, the function is again free to do whatever it wishes. And it probably will :-) (This is a case, however, where it's probably worth the function actually checking it's inputs, so the specification can be extended with "and if these values are exceeded, then the function dies, in order to locate the erroneous call" unless part of the requirement is a low overhead.) By ensuring that $a and $b are treated symmetrically, we only have to add one test case. At least until we reach the point where both values are "quite large" so that the overflow happens at the addition stage, rather than multiplication.


As for your bonus question, no, there's no guaranteed database available. Instead, you should look at DBI->available_drivers and DBI->data_sources to find out what's around.

In reply to Re: Unit Testing and Perl Module Development by tommyw
in thread Unit Testing and Perl Module Development by Masem

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.