http://www.perlmonks.org?node_id=117895

So you want to become a better programmer? Perhaps you'd like to give back to the community? You may not feel worthy, you may not have a brilliant module idea, but you still would like to do something. If only you knew where and how to start...

Run tests. Write tests. It's that simple.

Seriously. Programmers like tests about as much as documentation, but they can be fun and just as challenging. Think of it like a game -- how much can you test? Can you test something thought "untestable"? Can you get 100% coverage of all the paths?

Start by looking at Test::Simple. It comes with a document called Test::Tutorial. The basics are really very simple. Either something is okay or it isn't.

From there, pick a module you like. Start with something small, just one function. Write a few tests that prove it works.

If you're exceptionally lucky, you may discover a bug. Write a test that proves it's a bug, then write a patch to fix it. All of a sudden, you're not just a hero for testing, but you're a superhero.

If you're capable of using modules, you're capable of writing tests. It's that easy. It's that valuable. Hop to it.

Update: fixed link per converter's suggestion.

Replies are listed 'Best First'.
*How* Do I Get Involved?
by Ea (Chaplain) on Oct 11, 2001 at 17:52 UTC
    Alright - I already have written some gitzy little tests for the tiny, first module I wrote 3 months ago. And it felt great, too! But now the feeling is a little hollow. All I've done is one test per sub, testing the numbers I give it yield the answer I expect. I mean, for me the only way a test should fail is if the module isn't there. (or perhaps, if I go and change the checksum algorithm in a drunken stupor, the tests would bail me out) I somehow feel there should be more to it.

    So my question is - and it's quite newbie - How do I write a test? Forgive me for being pedantic, but there's not a lot out there. Test::Harness is briefly described in the Camel book (Amelia, to some ;) and there's the nodes Writing tests and perlman:Test::Harness. Does make test run all of the tests that it finds in the t directory automatically?

    Another question - How would you write tests for a program? The same as you would for a module? (but those are run with make test)

    For added entertainment, I'll throw in my "test suite". (Comments very welcome - snigger if you like ;)

    # Before `make install' is performed this script should # be runnable with `make test'. After `make install' it # should work as `perl test.pl' ####### We start with some black magic to print on failure. # Change 1..1 below to 1..last_test_to_print . # (It may become useful if the test is moved to ./t # subdirectory.) BEGIN { $| = 1; print "1..7\n"; } END {print "not ok 1\n" unless $loaded;} use Local::Barcode::Protocol; $loaded = 1; print "ok 1\n"; ######################### End of black magic. # Should tighten test code, should use Test::Harness # do some sanity checking on values # $testcode = '123456789/12345/1'; @decoded = decode_string($testcode); if (scalar @decoded == 3) { print "ok 2\n"; } else { print "not ok 2\n $decoded[0],$decoded[1],$decoded[2]\n"; } $one = '123456789'; $two = '12345'; $three = '1'; $result = encode_string($one, $two, $three); if ($testcode eq $result) { print "ok 3\n"; } else { print "not ok 3 ... encode_string Wanted $testcode Got $result\n"; } $result = generate_checksum($one, $two); if ($three eq $result) { print "ok 4\n"; } else { print "not ok 4\n $result\n"; } $result = is_valid_student($one); if (defined $result) { print "ok 5\n"; } else { print "not ok 5\n $result\n"; } $result = is_valid_assignment($two); if (defined $result) { print "ok 6\n"; } else { print "not ok 6\n $result\n"; } $result = assign_belongto_student($one, $two); if (defined $result) { print "ok 7\n"; } else { print "not ok 7\n $result\n"; }
    Good topic!

    Ea :wq

    Edit Masem 2001-10-11 - Code Tags

      Writing tests are good for (well... at least) two reasons.

      1. You think about what you do, how your code is to be used. You consider (and maybe discover some) boundary conditions and make sure your code doesn't break on them. It forces you to think about your interfaces and make them explicit (because otherwise, how do you know how the tests should succeed or fail?).

      2. Tests, even the simplest one, is encoded documentation of what works _now_. So what? If you later change something that breaks even the simplest thing, your test suit will tell you. This is regression testing. This is tangible confidence during maintenance.

      /J

        I suppose I'm looking for a Dick and Jane guide. I've only tested one value and I should test boundary conditions, but I feel I should also be trying to break it in other ways and look at the results. Looking at it right now, there's no validity checking on the input. I only feed it numbers, but there would be nothing stopping someone from feeding it characters. Well, perhaps that's the Right Thing to do, instead of restricting someone else's use of the code. It comes down to the difference between broken code and "creative" use yielding unexpected results.

        Cheers,
        Ea :wq

      Nice illustration. Most tests are as simple as those you have shown. Tests are meant to be very simple. Test the value of a function, test the type of the class prodcued by your constructor, test that your function breaks nicely for stupid inputs - by feeding it stupid inputs and looking at the results.

      Take a look at some of the test code on CPAN - the few that I've looked at consist of strings of simple tests. The hardest tests are those which depend on something outside your module.

      -- Anthony Staines
Sign up to be a CPAN tester
by petdance (Parson) on Oct 11, 2001 at 18:57 UTC
    The other part of that is to be a tester for the CPAN. Check out http://testers.cpan.org and sign up to be a CPAN tester. You'll get an email each time a module is uploaded to the CPAN. Try to install a module, and send the results to the CPAN with a handy-dandy little script. It adds a few seconds after each time you install a module, and it helps the authors know what works and doesn't.

    I've been doing it for about a year now. It's certainly not as useful as Chromatic going and writing up bunches of tests for key modules, but then again, if people don't run those tests, what good are they?

    xoxo,
    Andy
    --
    <megaphone> Throw down the gun and tiara and come out of the float! </megaphone>

      Actually, testing those bits on the CPAN is more useful. There's a lot of stuff in the core, but it gets a lot of attention from a lot of smart people on a lot of platforms. It's not 100% tested yet, but it's getting there.

      Some CPAN modules are used a lot, and they're tested... but there's a lot of stuff that's genuinely useful. A little feedback now and then is really helpful for authors. (It's especially nice when someone says, "This didn't work on my platform. Here's a patch!")

Re: How You (Yes You!) Can Get Involved
by converter (Priest) on Oct 10, 2001 at 06:58 UTC
      And here's the latest (and hopefully permanent) link to Test::Tutorial on MetaCPAN.
Re: How You (Yes You!) Can Get Involved
by Elliott (Pilgrim) on Oct 11, 2001 at 05:41 UTC
    Write a few tests that prove it works.

    Nice idea. But it can't be done. Sadly, the best you can do is fail to find the bugs.

    I've got a big collection of testing quotes somewhere if anyone's interested. (Once upon a time I was managing editor of Software Quality Management and testing was my speciality.)
      Hopefully one of those quotes is something like, "I'd rather have some tests that prove that some things work in some configurations than no tests, just guesses that everything works." :)