Geoffrey Young wrote:
David Cantrell wrote:
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.
well, ok, I'll agree with you if you look at it that way. but I think tdd
ought to happen at much lower level than that - certainly there's more to
test than just spitting out an image? you're probably calling several
different subroutines in order to generate that image, each of which can be
developed using tdd, and each of which gets more and more simple as you get
deeper into the application I'd suspect.
There are lots of bits which *can* be tested and which are (or will be
anyway once the design has settled down in my head), but they're all to
do with wrangling the data that the user supplies into nice structures.
Frankly, they're the easy bits. Those internal methods and those data
structures are not for public consumption. In fact, the only methods
for public consumption that return anything useful are the constructor
and the method which spits out an image. All the other methods will
either silently consume data or will die if you pass them a recipe for
pie instead of a list of numbers (for example).
Unfortunately, the draw() method is the one that's the hardest to write,
the one that is the most prone to error, the hardest to debug, and the
one where it's hardest to write tests in advance.
--
David Cantrell
