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

        • by djberg96 (2603) on 2003.05.22 16:45 (#20431) Journal
          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.