So how do you automate the testing of your software?
I spent considerable time, in my youth, working with various automation technologies because - let's be honest - I'm too lazy to check my changes by hand. What tools does a former autotest expert reach for to verify his own software?
stdout and diff.
Because, most of the time, that's all you need.
If I'm going to be testing one of my units (which tend not to be GUI components), the simplest thing that can possibly work is to work with at the console - write a console app that invokes an instance of my object. When I discover that I need to modify the implementation, I simply add the calls that I need to main(), and output the resulting state.
I could, of course, use NUnit in one of its flavors. But most of the time, I'm refactoring, which means that I'm making behavior preserving changes to the implementation. So I don't generally care what the right answer is, so long as I can verify that I'm still getting the same answer after each change.
David Feintuch, in Midshipmen's Hope, wrote of computers with sufficiently sophisticated parsing that the Dosmen could work with plain text files on a regular basis. We're close enough to that time to do much the same thing, without the parsing. Just get the data and compare it byte for byte with the previous run.
In those cases where parts of the data are dynamic (newly generated GUIDs, time stamps, and the like), I'll stick a masking filter in front of diff, to normalize the data, but the end result is really the same.
What about test suites? Mine all tend to have the same general form - for each file over here, process the input and compare it to the result over there. In some sense, this is perhaps less efficient than generating test data dynamically, but disk space is free, and the test machine is over there, chugging along while you surf the web.
Of course, all those input files are being generated automatically. Don't be silly.
January 21, 2003 12:03 PM
| TrackBack