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:
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:
1. Two other examples of coverage issues causing code changes that i've run into:
I recently wrote a snippet of code of this form:
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).sub foo { my $s = shift; if( $s =~ /^(AAA|BBB|CCC)$/ ){ my $foo = $HASH{$1}; my $bar = bar($s); ... } }
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:
or (depending on the innards of the block)if( $s eq 'AAA' || $s eq 'BBB' || $s eq 'CCC' ){ ... }
then it requires tests of foo('DDD'), foo('AAA'), foo('BBB'), and foo('CCC') for full coverage.if( $s eq 'AAA' ){ ... }elsif( $s eq 'BBB' ){ ... }elsif( $s eq 'CCC' ){ }
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 |
Back to
Meditations