Slash Boxes
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.
More | Login | Reply
Loading... please wait.
  • It's not so difficult [].

    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 was all for it. If I understand it properly, I've been doing it the whole time the hard way when problems came up. "...doesn't seem to bring a value over...well, I'll print the variable name and the variable...oh, and this doesn't seem to match properly...I'll dump the keys and mark them as coming from %inventory..." That kind of thing.

      If I'm off base on my concept of it, please, any clarification is welcomed. I'll be doing more research on it as I go anyway, because it looks very helpful.


      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