If you're writing a module you must have some idea of what you want it to do and how you are going to call its functions/methods/procedures. From that point its just a matter of painting a picture as it were. So for instance I knew for Data::BFDump that I was going to implement the Data::Dumper interface, but with different output. So I sat down and wrote a bunch of tests. Something like this:

use Test::More qw(noplan);
use Data::BFDump;

is(Data::BFDump->Dump([1..10]),"( 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 )","Ba
+sic list");
is(Data::BFDump->Dump([\1]),"\do{ my $t=1 }","Scalar Ref");
[download]

TODO:{
  local $TODO="Not implemented yet";
  is(Data::BFDump->Dump([1..10]),"( 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 )","
+Basic list");
  is(Data::BFDump->Dump([\1]),"\do{ my $t=1 }","Scalar Ref");
}
[download]

Oh, a little note: Some changes you make will break every test that you came up with. Thats ok. Just go through and make sure the results are what you want and change the expected results. But keep the tests. The more the better.

Yves / DeMerphq
---
Writing a good benchmark isnt as easy as it might look.

A good start would be the excellent article chromatic wrote: An Introduction to Testing

Chris
M-x auto-bs-mode