I have never been a member of the Unit Testing Cult. That’s not to say that I don’t think tests are a good idea, or that I haven’t used them in the past. Maybe I just haven’t worked on enough XML parsers. Most of the work I have done is in highly interactive applications (video games etc) which I think are hard to test in this way. If you are building an online game the dynamic nature of your problem state makes it extremely difficult to do much in the way of system level automated testing. You can of course use testing on the individual subsystems, but unfortunately that’s not where most of the difficult bugs occur.
All of this leads me to feel about Unit Testing and TDD the way I do about Standardized Testing for students as a way to measure the quality of the education they are getting. Unlike alot of people I know. I don’t reject the idea of standardized tests like the WASL, I just think you have be very careful when you start deciding what the results of the tests mean. If your schools test scores continue to drop every year, that doesn’t necessarily mean that the faculty should all be fired or the school closed, but It does mean its worth looking closer as to why that is happening. Same thing if the scores are going up. If all your tests pass you still might have a problem.
What you need to be sure of whether you are testing 10th graders or matrix libraries is that the tests are evaluating the right things. For simple things this is pretty easy. Can Jonny perform basic math operations? etc. Deciding if Jonny or your code is capable of something more complicated as in Can Jonny Think For Himself ? or Can Your Physics code generate realistic looking motion?, moves us into an area where the test starts to become pretty difficult to construct and evaluate. Its been along time since grad school but I would say its very possible for the test to become much harder to write than the code or even impossible to write.
Two links showed up in my bloglines today. Both from Eric Sink who is an oft-quoted software developer out there. Each one makes a different side of this point in my view. The first is on his blog where he’s raving about how wonderful Code Coverage is. His tests cover 100% of the code he is writing and he’s very happy. The second one is from a guest appearance by him on the Daily WTF where he gives up the reason why in the end that’s not such a great thing after all.
A robust solution to this problem would have taken a lot of time, and I was in a hurry. So I wrote the code you see above, which simply checks 10 points along the interior of the line segment. As soon as it finds any point on the segment which is outside the solid, it returns false.
I was ashamed of myself when I wrote this, but the fact is that it allowed me to move forward and all of my unit tests pass.
Which is to say he just told the teacher what he wanted to hear about Shakespeare’s Othello without bothering to think for himself. That’s not to disparage Mr. Sink. I never really Liked Othello much myself.
As a bonus though. Here’s another nice pair of Eric Sink Links
Aug 18, 2004 – A Primer on Software Pricing
Aug 21, 2004 – An Admission that a product he is selling is priced wrong
In coding, business, and in the 10th grade, regardless of how you test, the best thing is to keep trying to do better.
Leave a Reply