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

use Perl Log In

Log In

[ Create a new account ]

heusserm (4461)

heusserm
  (email not shown publicly)
http://www.xndev.com/
AOL IM: MatthewHeusser (Add Buddy, Send Message)

Matt Heusser is JAPH and an XP-Er [xprogramming.com]. (The Methodology, not the Operating System.) Right now, he's doing a lot of Test Driven Development in Perl.

Journal of heusserm (4461)

Thursday September 11, 2003
12:22 PM

My last post

[ #14656 ]
    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.
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.
  • If you write your code test first then the tests should break at least once before you implement the functionality. And if you write your test clearly you just documented the interface.