ugh.
Folks who read my last post seem to think that I was saying: "Make your programs so they can't break, and you don't have to test them."
Well, that's half right ...
If you break your functions down far enough, but not quite to the absurd, you can understand the entire function at a glance. Then, you can know they work correctly because you can completely follow the logic of the entire function.
Military strategists got it right with the idea of span of control - it's hard for most people to keep track of more than about seven things at once. When functions get too complex, something falls out ... and that something can all to easily be the limit of a loop index, or an "else" at the end of a long conditional.
By keeping functions small enough that they can't break, we can avoid all that.
Does that mean we shouldn't test?
CERTAINLY NOT! Check the comments on my last post for plenty of reasons why you should test even things you think can't break.
In fact, in his presentation Testing Large Systems in Perl, Andy Lester suggests that you should test things that can't possibly break anyway.
1) Writing the test takes all of 2 minutes
2) It's automated - running the test is nothing.
3) Things may change.
4) You might have been wrong.
Again - my point - sure - test early, test often, test always. But minimizing the number of things that could possible break is still a good thing.
