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.
  • Q: How do you know your tests aren't buggy? Do you write tests for your tests? Har har!

    A: No, I write my tests first. I make sure they fail. Then I write code to make them pass. The tests test the code and the code tests the tests.

    • Do you _always_ do this?

      Don't you sometimes write something that is so complicated that you can't really predict the outcome (which is why you wrote code to compute it in the first place), and just use whatever you get as the baseline output for future regression tests?

      Don't you sometimes find that the API spec of a method evolves in a good way as you go from caller (tests) to method API design to implementation of the method?

      I know I cheat. Sometimes a lot.
      • When I cheat, I get caught and I feel stupid, so I tend to cheat a lot less as time goes on.

        I can't remember the last time I worked on something so complicated that I couldn't attack it in small chunks. That's another nice benefit of test-first: you have to work in baby steps. My most recent project [perl.org] has methods of three to ten lines apiece. The longest method is 19 lines, and it has the only if-else block in the whole program.

        Granted, it's not a complicated problem, but it's a surprisingly small am

        • I can't remember the last time I worked on something so complicated that I couldn't attack it in small chunks. That's another nice benefit of test-first: you have to work in baby steps. My most recent project has methods of three to ten lines apiece. The longest method is 19 lines, and it has the only if-else block in the whole program.

          Indeed, I consider this to be the best side effect of test-first. It leads to better code design, because you break things down into easily testable methods.

  • Re: Complexity (Score:3, Interesting)

    by jplindstrom (594) on 2003.05.22 13:39 (#20425) Journal
    Your experience match my own very closely.

    And it was Perl (CPAN modules) that introduced me to the concept in the first place. Before that I had _never_ encountered tests, and I majored in CS. I can't believe it's not more touted as a basic, mandatory practice.

    Ok, it takes a little longer, but when you stop coding you're most likely actually done and don't have to go back to fix mistakes. Thinkos, sometimes yes, but never typos (which often goes beyond "it compiles").

    And once you've been saved by the safety net a couple of times you see the light and can't go back. I'm sure I can't, it seems plain irresponsible and stupid. And, I'm too much of a coward and make too many mistakes to not have a safety net anyway, so I don't have a choise :)