NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Test what you use. (Score:1)
I like Schwern's "test bugs" philosophy for any sort of maintenance testing.
For new code, I probably wouldn't even write a unit test for reciprocal() -- but I wouldn't have a function for reciprocal() except in a general-purpose math library. And in such a library, yes I would probably have more "silly" tests, but also better diagnostics built into the function.
But for s
dodging the question (Score:1)
I'm probably not doing a good job of answering "what do you test", but that's okay, my test suite gives me a pass [grin].
I'd be worried enough that someone would accidentally throw some code together that uses
reciprocalas an object method (and therefore uses an int-ified string-ified object as the divisor) that I would probably add some parameter validation, and then just test that my validation worked. I wouldn't feel the need to test the/operator.-- Douglas Hunter
A Good Type System (Score:1)
This is one of the cases where a good strict typing system really helps (though I'd want the system to enforce all overloading of the division operator such that mathematic invariants hold).
Don't forget to test ... (Score:2)
Re: (Score:2)
You're just making life difficult :)
easy, be more strict. (Score:1)
You can simply enforce typing:
use Carp::Assert::More;
sub recip {
my ($num) = @_;
assert_nonzero($num);
return 1/$num;
}
Then write one test to make sure that it works:
is( recip(2), .5 );
one to show that it dies correctly:
dies_ok sub{recip(0)};
and your done, any bugs that come up later can be tested then.
benh~