On 3/28/06, David Cantrell <[EMAIL PROTECTED]> wrote: > 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.
There are things you can do though. For example you can make draw take a canvas argument. Normally the canvas object would end up producing a gif but when testing, you pass in a canvas which just records all the requested operations. You can then make sure that draw() tried to draw the right number of points, lines, circles, squares etc, that it didn't try to draw outside the boundaries, that it tried to put labels close to the things that were being labelled etc etc. If you were graphing a mathematical function you can check that for each (x, y) that was rendered that abs(f(x)- y) < epsilon for some acceptable epsilon you can also make sure that there was an x for each point visible on the x-axis. Tests like these (particularly the mathematical function graphing tests) can definitely be written in advance, F > > -- > David Cantrell >
