Unit Test Driven Development

See the ''Test Driven Development'' books.

By the book, write failing Programmer Tests, and briefly make them pass. Then refactor to improve maintainability; testing every few edits, to ensure all tested behaviors stay the same.

• Locate the next missing code ability you want to add
• Write a test that will only pass if the ability is there
• Run the test and ensure it fails for the correct reason
• Perform the minimal edit needed to make the test pass
• When the tests pass and you get a Green Bar, inspect the design
• While the design (anywhere) is low quality, refactor it
• Only after the design cleaner, proceed to the next ability.

This cycle puts the easy part first; test code is obvious and desposable. And it does the hard part, designing, after adding the feature and ensuring passing tests now defend that feature from refactoring. The cycle permits programmers to only think of one detail of the code, to fully express that thinking as new abilities and improved design, while forgetting all the other code details. Previous tests defend those. TDD automates your red light; the best way to go very fast is to be able to stop instantly.

StoryTestDrivenDevelopment requires programmers' test buttons to also run the current set of StoryTest?''''''s.

Databases are hard to refactor, while GUIs are hard to test and too easy to refactor. Scott Ambler (?) researches the first problem, while the TestFirstUserInterfaces initiative reseaches the latter.