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.
  • It's not so difficult [perl.com].

    Personally, I don't have the time not to test -- writing a Slash plugin for an article due next week, I'd have caught several bugs sooner if I'd written my test cases first. I caught them only after investing more debugging time than I would have liked.

    • I wasn't clear, and I apologize.

      First, I don't quite understand *when* testing needs to be done, where it happens, etc., like knowing basically what a transmission does but not realizing how it's actually applied within the mechanism of the whole car.

      Second, I am woefully bereft of any experience installing modules. (Although I'm going to the link you supply after I post this clarification to see if I can rectify the situation.)

      Believe me, when I *saw* the testing explained in the advent calendar, I

      --

      ------------------------------
      You are what you think.
      • Easily enough explained (and no apology is necessary).

        Test Continually. Test before you add a feature. Test when you think you've added that feature. Test after you make any change. Test when you return to the program in the morning. Test, test, test.

        If you test every feature sufficiently, if you refuse to accept anything less than complete test success, and if you run the tests after sufficiently small changes, you will have more confidence in your code, spend less time debugging, and be free to m