Programmer doesn't know what to test, so he just makes something up without much thought. My favorite example was a C program I worked on a while back. A data routine was written which could take a field from a file. If the field wasn't there it'd return null. Now here's the funny bit, as soon as the original programmer got the data file back, he called "V''''''alidateData" on it. V''''''alidateData used strlen to check the size of the string and returned either a 1 or a 0. You know what happens when you call strlen with a null pointer? You java guys aren't safe though. You know what happens when you call .length() with a String that's actually null? Your java program explodes!

Another favorite example of mine was a Java program I worked on a while back. Company had a test-first policy in place. Programmer had written a test where he was checking a date, and I noticed that he'd subtracted 7 hours from the date he was feeding to the test routine. Turns out that due to a GMT offset problem, the data wouldn't actually show up for up to 7 hours in my time zone. Apparently the original programmer didn't find this to be unusual and simply modified his test to get around the problem. Nevermind how many rules of test first THAT violates...

Now I don't now about most programmers in here, but back in high school I had an analysis class, in which we did mathematical proofs for various formulae. In that class we learned to test the minimum range, a number in the middle and the maximum range of whatever we were interested in. Or as my teacher liked to put it, n, n+1 and n+infinity (where n was typically 0.) Infinity was sometimes 2. UnitTest''''''ing needs similar attention to ranges and things that can typically make a function choke (2 delimiter tokens in row in a S''''''tringTokenizer, anyone?)

-- BruceIde

----
More recipes for good test cases are in BrianMarick's book ''TheCraftOfSoftwareTesting''
----
See ZeroOneInfinityRule
----
CategoryTesting