in reply to Unit testing OS rich code

Essentially all you are testing is:

if( TRUE ) {
    # comes here
}
...

[download]

And:

if( FALSE ) {
    ...
}
else {
    # comes here
}

[download]

It is tests like these that show up testing for the sake of numbers -- in this case, coverage statistics -- as the meaningless time-wasting exercise it so often is.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^2: Unit testing OS rich code
by chromatic (Archbishop) on Oct 12, 2011 at 23:45 UTC

    The interesting part isn't the if part. It's the expression.

    If that's not worth testing, so be it—but I've fixed enough bugs in file-handling code that I don't assume that relative paths are correct just because they look like constant expressions.

    Improve your skills with Modern Perl: the free book.

[reply]
[d/l]

      I would agree, if he was actually performing the file test:

      sub file_exists
{
        my ($filename) = @_;
        #return (-f $filename);
        return 1;       
}

      [download]

      But once he's mocked that up along with rename which can perform differently on different platforms, and touch, which may well not exist on many machines, all that's left is can perl: a) iterate a hash and b) take the correct branch in the if statement.

      Which is a pointless exercise that serves only to achieve a "100% coverage" statistic. S'no wonder development gets ever more expensive while error rates remain constant.

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
[reply]

In Section Seekers of Perl Wisdom