Well I dont have links but I can make some suggestions.
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");
And so on. Thus you put down what and how you'd like to call a routine and what youd like it to return. If you dont actually have the functionality then you wrap it in a TODO like so:
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");
}
As you build up more an more tests you also build up more and more functionality.
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. |