Stories
Slash Boxes
Comments
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Adding in all of the other "silly" tests would likely be a waste of time, but not if you're writing software to control a nuclear reactor.

    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.