The other day my dad showed me a copy of my BSc. dissertation that he's had in a folder somewhere since 1992. I remembered vaguely that it was about drawing trees and plants using L-Systems to describe the structures and Logo to render them, but had no strong memory of what I actually did.
Flipping through it, I saw that I learned enough C, yacc, lex, and Postscript to cobble an implementation together and that the trees, although only greyscale line drawings, could model aspects of natural growth patterns in a convincing way.
A pleasant trip down memory lane, for sure, until a what the ...? moment as I came across a (short) section on testing.
I have no recollection of learning testing at university and there are no testing resources in my bibliography. Did I just make it up as I went along? Well, as we all know, anyone can test, so I thought I'd look at what approaches the anyone who was the callow me tried.
I pulled out evidence from the brief text, trying not to over-interpret or give myself too much credit for what might realistically have been five minutes of last-minute panic effort, something copied from a friend's dissertation, or simply made up:
Traditional oracle: ... entering many L-systems of which the results were known and comparing these to the output produced.
Integration test; comparative oracles: The output was displayed in X and on Ghostscript [and] checked to make sure that they gave consistent results.
Simplification: The number of iterations can be decreased (down to 0 or 1) to help find the problem.
Regression testing: ... a random selection of previously OK L-systems were run again to make sure that fixing one problem has not introduced a host of new ones.
Instrumentation: ... various stages in the execution the state of the system would be output ... This allowed the flow of execution to be followed and checks to be made on the variables used.
Fuzzing: Garbage data was entered ... For example running ... on [its own] source code ... caused it to crash out quite quickly.
Minimal step tests: ... hand-code Logo files ... to make sure that the orientation of the turtle is correct ... It is very easy to check the 3D capabilities ... in this manner ...
Superimpose on the output: ... it is helpful to plot a set of co-ordinate axes at every end of line ...
White box testing: the location of errors can be pin-pointed or predicted ... when one can follow the execution of a program.
Decomposition: ... not drawing the results but sending the results to a file [at each step] ...
Tooling: ... limited use was made of dbx ...
User acceptance testing: ... letting users loose on the system with a manual full of examples and a free reign on what they could do ...
All of which look like things I would and still do today. Ironically, given that this was a graphics project, I find myself unsure what conclusions to draw.
Comments
Post a Comment