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 ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Wednesday September 18, 2002
02:42 PM

Testing acolyte

[ #7815 ]

Yup. chromatic has forced me to drink the testing kool-aid. I have a large Web site that I maintain and frankly, the code's a pig. It's embarrassing. And it has no tests. We've been asked to make some major changes (of course, they always ask us to make major changes) and it's forced me to renormalize the database. In my estimate, I included a large chunk of time for writing tests for system.

To ensure that my test environment would work, I took what is far and away the most stable module and started writing tests for it. I'm now up to 28 tests, but I discovered something very interesting. My first few tests failed immediately. After a bit of research, I discovered a long standing bug in the code that was causing intermittant failures. I was never able to track the bug, but my fourth test uncovered it immediately!

With supreme confidence garnered through having tests started, I went through and made some sweeping changes in the code and now this "stable" module is even more stable. I love tests :)

Of course, I will never be able to properly forgive chromatic for destroying my carefree idealism.

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.
  • And the best thing is that if you ever reintroduce that bug, you will recatch it as well.

    Test everything. Test your most basic assumptions. Once you write it, it's done, and will be in your employ forever.

    Here's some stuff I wrote yesterday that reads a tree structure of nodes from the DB and makes sure that there are no stray, unlinked nodes:

    #!/usr/bin/perl -w

    use strict;
    use Test::More tests=>5;
    use FLR::DB qw( :sqldo );

    my %nodes;
    my %children;
    my @tops;

    =pod

    This little baby looks at all the nodes

    --

    --
    xoa

    • How useful are you finding embedded POD in your tests? I've been of the opinion that good test names go a long way, but does a little documentation go even further?

      • This example is pretty uncommon, since usually the code behind the tests is pretty obvious. In this case, since I was building up trees and then deleting them recursively, I thought it warranted comments.

        I do always make sure that every test has a name, though. I hate seeing:

        ok 1
        ok 2
        ok 3
        not ok 4
        ok 5
        ok 6
        and then having to count down to test 4 in the code to see what it is
        --

        --
        xoa