*How* Do I Get Involved?

[Ea]

in reply to How You (Yes You!) Can Get Involved

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

[jplindstrom]

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

[Ea]

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

[chromatic]

There will be a couple of articles on testing published on Perl.com shortly. Skud (from e-smith) is using real-world examples from her job. I don't know the exact status, but she expected to have the first one ready sometime this week.

If there are still questions after that, let me know, and I'll work up another article. (If you have specific questions about a chunk of code, drop me a message and I'll take a look at it.)

Update: Here's one article. I promise I'm not Skud; we've been seen in public in the same room.

[astaines]

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