http://qs321.pair.com?node_id=659535

One of the things a like about testing/tests/test suites/coverage stats is that it can sometimes1 (often?) cause re-evaluation of how you wrote some specific piece of code.

I recently wrote a snippet of code of this form:
sub foo { my $s = shift; if( $s =~ /^(AAA|BBB|CCC)$/ ){ my $foo = $HASH{$1}; my $bar = bar($s); ... } }
While there could easily style/preference (or efficiency) arguments made about this form and use of the regex to match for multiple exact matches, it's nice because it's concise and easy to add an extra case or two (i.e. not an extra line, though obviously adding more than just a couple would be messy).

I found myself wanted to rewrite it, however, for a different reason after starting to compose my test suite. A test suite consisting of a call to foo('AAA') and foo('DDD') is sufficient for Devel::Cover to report 100% coverage. But clearly it's not going after the 'BBB' or 'CCC' of the conditional that's embedded in the regex logic.

If, however, it's rewritten as:
if( $s eq 'AAA' || $s eq 'BBB' || $s eq 'CCC' ){ ... }
or (depending on the innards of the block)
if( $s eq 'AAA' ){ ... }elsif( $s eq 'BBB' ){ ... }elsif( $s eq 'CCC' ){ }
then it requires tests of foo('DDD'), foo('AAA'), foo('BBB'), and foo('CCC') for full coverage.


1. Two other examples of coverage issues causing code changes that i've run into:

Replies are listed 'Best First'.
Re: coverage influencing form
by dws (Chancellor) on Jan 01, 2008 at 22:03 UTC

    There are several alternate ways to structure that code fragment. If you already have %HASH primed to contain keys for the values you're trying to match,

    if (exists $HASH{$s}) { my $foo = $HASH{$s}; ...

    which lets you write a unit test against the initialization of %HASH, in addition to a smaller number of tests of foo(). The risk of that approach is that the link between %HASH and its use in foo() is tenuous from the perspective of the tests. (I.e., how can you prove, via tests, that there's any association between %HASH and the behavior of foo()?)

    Another approach is to move the matching into a separate sub, which lets you write more focused unit tests against the matching subroutine, but which still leaves you with the tenuous link problem.

    One approach to establishing linkage is to use Test::Resub to temporarily replace the search subroutine with a test-only version that records that it has been invoked, and then write a test against foo() to verify the invocation. (We used to call these "plumbing" tests, since their goal is to verify that A calls B without asserting anything about the behavior of B, leaving assertions about B's behavior for other tests.)