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
an endless discussion thread about what features to include.
-- Jarkko Hietaniemi
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 specific project code, I tend to focus tests at a level about halfway between the highest-level API and unit tests. I do this because fine-grained unit tests turn into makework when you're evolving an architecture/API -- and they create too much momentum against change. If you're testing functions at about 1-2 levels above something like reciprocal(), you still get adequate coverage and your test code looks a lot like the code you plan to use in production.
I guess it comes down to a matter of abstraction-size, so I would say "test the problem you're trying to solve". If you're breaking the problem into sub-problems, test those solutions. Or: anything that took you more than a few minutes to think through.
Reply to This