All the Perl that's Practical to Extract and Report
use Perl Log In
petdance (2468)
andy@petdance.com
http://www.perlbuzz.com/
AOL IM: petdance (Add Buddy, Send Message)
Yahoo! ID: petdance (Add User, Send Message)
Jabber: petdance@gmail.com
I'm Andy Lester, and I like to test stuff. I also write for the Perl Journal, and do tech edits on books. Sometimes I write code, too.
A testing story with a happy ending
perlop man page mentions: Binary "x" is the repetition operator
... repeated the number of times specified by the right operand.
It should mention what about if the right operand is negative, e.g.,
print '-' x -80
I figured I could make a quick documentation fix, and maybe even add some automated tests to the Perl test suite.
The x operator in Perl does repetition on a scalar or list, as
appropriate. For example:
$a = "abc" x 2; # $a = "abcabc";
@a = ("abc") x 2; # @a = ("abc","abc");
If the right-hand operator is 0, then you get an empty scalar or list, as appropriate. If the right-hand operator was negative, it was the same effect as having it be zero. As the bug said, the man page didn't say anything about it.
I added a little sentence to the paragraph describing the operator, and then I added some tests. If it's worth documenting, it's worth testing. Documentation and tests are as much a part of the code as the code itself.
t/op/repeat.t already had a lot of tests in it, like:
is('-' x 5, '-----', 'compile time x');
is('-' x 1, '-', ' x 1');
is('-' x 0, '', ' x 0');
So I added the obvious add-ons:
is('-' x -1, '', ' x -1');
is('-' x undef,'', ' x undef');
And then went to add them to the list-related sections:
@x = qw( a b c );
is(join('', (@x) x -14), '', '(@x) x -14');
Before I sent the patch in, I ran a full make test and found that
the last test didn't pass. In fact, it caused a Panic in Perl, and the
program died. I boiled it down to a simple:
perl -e'@x=(1);@y=(@x)x-1'
Turns out that that case of a negative or zero operand wasn't handling the stack correctly (in the bleadperl only, fortunately). A quick patch made it all better.
Some morals to this story:
- Never underestimate the power of one little test.
- There is no such thing as a dumb test.
- Your tests can often find problems where you're not expecting them.
- Test that everything you say happens actually does happen.
- If it's worth documenting, it's worth testing.
--Larry Wall in stab.c from the perl source code
May I quote you? (Score:1)
I want to get automated tests going in our shop, and I'd like to frame your points 1 and 2, and put them on the wall.
Re:May I quote you? (Score:2)
Heck, I'll come talk to your user group about testing, if you want...
--
xoa
Re:May I quote you? (Score:1)
Oh well. I'm preaching to the converted.
a few more (Score:1)
I'll add a few (for what it's worth - after spending some time writing test code today) to the list (and a few q's)
btw I'm coming from a python [python.org]
testing pov so I'm curious how testing approachs differs for perl.
*automate where possible
-write automated test tools to generate test code stubs from source code
to save time, effort and concentrate on thinking about tests.
*make tests pass by default
-lots of talk about failing code by default. the reverse is faste
bootload [netspace.net.au], groking softwa
When to write tests? How many? (Score:2)
Short version:
--
xoa