I don’t need to test my programs. I have an error-correcting modem.

I don’t need to test my programs. I have an error-correcting modem.
~ Om I. Baud

      Leaving bugs in your programs gives the maintenance programmer who comes along later something interesting to do. A well done bug should leave absolutely no clue as to when it was introduced or where. The laziest way to accomplish this is simply never to test your code.

1. Never Test

   : Never test any code that handles the error cases, machine crashes, or OS glitches. Never check return codes from the OS. That code never gets executed anyway and slows down your test times. Besides, how can you possibly test your code to handle disk errors, file read errors, OS crashes, and all those sorts of events? Why, you would have to either an incredibly unreliable computer or a test scaffold that mimicked such a thing. Modern hardware never fails, and who wants to write code just for testing purposes? It isn’t any fun. If users complain, just blame the OS or hardware. They’ll never know.

2. Never, Ever Do Any Performance Testing

   : Hey, if it isn’t fast enough, just tell the customer to buy a faster machine. If you did do performance testing, you might find a bottleneck, which might lead to algorithm changes, which might lead to a complete redesign of your product. Who wants that? Besides, performance problems that crop up at the customer site mean a free trip for you to some exotic location. Just keep your shots up-to-date and your passport handy.

3. Never Write Any Test Cases

   : Never perform code coverage or path coverage testing. Automated testing is for wimps. Figure out which features account for 90% of the uses of your routines, and allocate 90% of the tests to those paths. After all, this technique probably tests only about 60% of your source code, and you have just saved yourself 40% of the test effort. This can help you make up the schedule on the back-end of the project. You’ll be long gone by the time anyone notices that all those nice "marketing features" don’t work. The big, famous software companies test code this way; so should you. And if for some reason, you are still around, see the next item.

4. Testing is for cowards

   : A brave coder will bypass that step. Too many programmers are afraid of their boss, afraid of losing their job, afraid of customer hate mail and afraid of being sued. This fear paralyzes action, and reduces productivity. Studies have shown that eliminating the test phase means that managers can set ship dates well in advance, an obvious aid in the planning process. With fear gone, innovation and experimentation can blossom. The role of the programmer is to produce code, and debugging can be done by a cooperative effort on the part of the help desk and the legacy maintenance group.

   If we have full confidence in our coding ability, then testing will be unnecessary. If we look at this logically, then any fool can recognise that testing does not even attempt to solve a technical problem, rather, this is a problem of emotional confidence. A more efficient solution to this lack of confidence issue is to eliminate testing completely and send our programmers to self-esteem courses. After all, if we choose to do testing, then we have to test every program change, but we only need to send the programmers to one course on building self-esteem. The cost benefit is as amazing as it is obvious.

5. Ensuring It Only Works In Debug Mode

   : If you’ve defined TESTING as 1
   #define TESTING 1
   this gives you the wonderful opportunity to have separate code sections, such as
   #if TESTING==1
   #endif
   which can contain such indispensable tidbits as
   x = rt_val;
   so that if anyone resets TESTING to 0, the program won’t work. And with the tiniest bit of imaginative work, it will not only befuddle the logic, but confound the compiler as well.

kinnheung@yahoo.com.cn