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 ;)

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.

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.

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.

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.