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 ]

Shlomi Fish (918)

Shlomi Fish
  shlomif@iglu.org.il
http://www.shlomifish.org/
AOL IM: ShlomiFish (Add Buddy, Send Message)
Yahoo! ID: shlomif2 (Add User, Send Message)
Jabber: ShlomiFish@jabber.org

I'm a hacker of Perl, C, Shell, and occasionally other languages. Perl is my favourite language by far. I'm a member of the Israeli Perl Mongers, and contribute to and advocate open-source technologies. Technorati Profile [technorati.com]

Journal of Shlomi Fish (918)

Tuesday July 10, 2007
09:23 AM

Test::Run Regression Bug

[ #33770 ]

After I released Test-Run version 0.0111, and made some related Test-Run-CmdLine releases, I noticed that Test-Run-CmdLine got broken. As it turned out, a regression was introduced into Test-Run which, due to inadequate testing in the core distribution, was only discovered in the Test-Run-CmdLine tests. I could have discovered it on my machine, if only I had ran my script to build all the Test-Run-related distributions.

Namely, in my continuous work on converting the legacy GPL and (original) Artistic code that I inherited from Test::Harness to an MIT-X11 Licensed code, while refactoring it in the process, I broke the "leaked directory" (which indicates which files inside it were leaked). After I added a regression test for it in the core Test-Run distribution, I found out that I had about three bugs in the new code, which was about 20 lines. (Reminds of "How to fit 3 bugs in 512 bytes of security code"). After I fixed them, Test-Run-CmdLine did not complain.

There are several lessons here. One is that one should also test modules that are based on the core module before releasing it. The other is that if bugs are discovered by testing a derived module, then regression tests should also be added to the test of the core module. And finally, that it is a good idea to have a good test coverage before refactoring.

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.