On 3/28/06, David Cantrell <[EMAIL PROTECTED]> wrote: > Geoffrey Young wrote: > > >> "Only the simplest of designs benefits from pre-coded tests, unless you > >> have > >> unlimited developer time." > > needless to say I just don't believe this. > > Try writing a test suite ahead of time for a graphing library. It's > possible (indeed, it's trivial - just check the md5 hashes of the images > that are spat out against images that you have prepared ahead of time in > some other way) but it would be damnably time-consuming to create those > tests. Consequently, I've not bothered. I throw data at it, and look > at the results. If the results are good I then put an md5 hash of the > image into a regression test.
This is how I built up the tests for Data::Dump::Streamer. Basically when i add a feature I dump a structure that demonstrates the feature, and then C&P into a test file which will also dump the structure and compare it against what i recorded. (For some fairly bizarre domain specific definition of compare :-) Once you have enough of these tests your test coverage ends up being pretty good. While apparently some on this list apparently dont favour this approach, im pretty much at a loss to come with a better way to test the module. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
