Chapter 8: TESTING TIMES The Black Art of Testing Code

• Test everything. Keep what is good.
• The single most important rule of testing is to do it.
• Testing is not debugging. Don’t get the two confused. They require different skills. Make sure you know when you’re testing and when you’re debugging.
• Testing can only discover the presence of faults. It can’t prove the absence of faults. Don’t be led into a false sense of security by code that passes a suite of inadequate tests.
• It is a programmer’s responsibility to test the source code he or she writes.
• You must test every piece of code you write. Don’t expect anyone else to do it for you.
• Effective code testing starts early, so you catch bugs when they’re least harmful. You can write tests before writing code!
• For each piece of code you write, immediately write a test. Or write the test first.
• Write a test for every fault you find.
• Run your tests as often as you can.
• It’s very easy to trust the code you read and to believe that it’s correct. When you’ve just written some code, you’ll read what you intended to write, not what you actually wrote. Learn to look twice—read all code cynically.
• Write a comprehensive suite of tests, each one exercising a different aspect of the code. Fifteen tests that demonstrate the same fault over and over are less useful than fifteen tests that show fifteen different faults.
• Test randomly generated sets of input data to avoid guesswork. This is a surprisingly effective test strategy.
• Design your code for easy testing. When you structure code for testability, you will be structuring it in a sensible, understandable, and main-tainable way. You’ll reduce component coupling and increase cohesion. You’ll make it more flexible, easy to use, and easier to wire up in different configurations. Your code will be better. (Testable code is a well designed code - Ottó)
  • Make each section of code self-contained, without undocumented and tenuous dependencies on the outside world.
  • Don’t rely on global variables
  • Limit the complexity of your code; break it into small, comprehensible, bite-sized chunks that can be individually tested.
  • Make the code observable, so you can see what it’s doing, query internal state, and ensure that it’s operating as expected.

• Automate your code testing as much as possible. It’s quicker and easier than running tests by hand, and it’s far safer: The tests are more likely to be run regularly.
• Run unit tests automatically as a part of your build process.