Guidelines for test first design

Guidelines for test first design:

• The name of the test should describe the requirement of the code
• There should be at least one test for each requirement of the code. Each possible path through of the code is a different requirement
• Only write the simplest possible code to get the test to pass, if you know this code to be incomplete, write another test that demonstrates what else the code needs to do
• A test should be similar to sample code, in that it should be clear to someone unfamiliar with the code as to how the code is intended to be used
• If a test seems too large, see if you can break it down into smaller tests
• If you seem to be writing a lot of code for one little test, see if there are other related tests you could write first, that would not require as much code
• Test the goal of the code, not the implementation
• One test/code/simplify cycle at a time. Do not write a bunch of tests, and try to get them working all at once
• Keep writing tests that could show if your code is broken, until you run out of things that could possibly break
• When choosing an implementation, be sure to choose the simplest implementation that could possibly work
• If you are unsure about a piece of code, add a test you think might break it
• A test is one specific case, for which there is a known answer
• If all of the tests succeed, but the program doesn't work, add a test
• Tests should be as small as possible, before testing a requirement that depends on multiple things working, write a test for each thing it depends
• Tests should not take longer than a day to get working, typical test/code/simplify cycles take around 10 minutes
• Don't test every single combination of inputs. Do test enough combinations of inputs to give you confidence that the any code that passes the test suite will work with every single combination of inputs
• Do not write a single line of code that doesn't help a failing test succeed. (Clarification for GUI's, some aspects of GUI's are impossible to test automatically, so it will have to be an acceptance test that drives you two write some GUI code. Use automated testing whenever possible)
• Do not fix a bug until you have written a test that demonstrates the bug

What is the simplest code? (Paraphrased from the "Extreme Programming" series of books)

• All of the tests run
• There is no duplicate code (any given code segment or structural pattern should appear "once and only once")
• Clarity. The code and tests communicate the intent as clearly as possible
• The code is minimal (no classes or methods unnecessary to get the tests to pass)

The Test-Code-Simplify cycle (Quoted verbatim from "Extreme Programming Applied", p159)

• Write a single test
• Compile it. It shouldn't compile, because you haven't written the implementation code it calls
• Implement just enough code to get the test to compile
• Run the test and see it fail
• Implement just enough code to get the test to pass
• Run the test and see it pass
• Refactor for clarity and "once and only once"
• Repeat

 (From:    http://xprogramming.com/xpmag/testFirstGuidelines.htm)