- Write a test, ensure that it fails [RED]
- Make the smallest possible change to get the test to work [GREEN]
- Refactor. Simplify the code to eliminate duplication and keep the design clean [REFACTOR]
The biggest mistake that people make when trying to get into test driven developement is to try to write all of the tests up front. This process is all about small error free steps.
The trick is to keep the tests small and focused. Don’t try to test too much with one test. If they are too fragile then you will spend your entire time rewriting your tests. As I write the tests I oftern find myself with a substantial helper object that performs the common tasks for me. The tests end up as documentation for the system.
Another important thing to remember is that this cycle is the formal version akin to the full blown scientific method:
- State Hypothesis
- Design an experiment, then perform it
- Identify whether Hypothesis is true or false
In addition if you have a project covered with automated tests adding new ones becomes simpler. It is especially powerful if you need to maintain several branches of a given codebase. If the helper object can keep it’s interface untouched across the streams then the tests can stay largely untouched.
I have sucessfully used this when porting an application from one database to another, but the technique would work in the same mannerif you were to change langauages. The trick is to create an abstract interface to test against. You write helper objects that implement that interface against the old and new systems. You write the tests against the old system and then implement the new in order to get the tests to build.