1. Bei Bedarf eine kurze Design-Studie mit dem ProgrammierPartner oder in einem größeren Team abhalten; je nach Vorliebe mit Hilfe von CrcKarten, UmlSkizzen? oder ähnlichem. Dieser Schritt sollte im Allgemeinen nicht länger als zehn Minuten dauern.
2. Den ersten, einfachen TestFall schreiben.
3. Den TestFall (falls notwendig) kompilieren. Nötigenfalls dummy-Implementierungen für neue Schnittstellen einrichten.
4. Beobachten, dass der TestFall fehlschlägt.
5. Den TestFall auf die einfachst mögliche Art und Weise erfüllen. (Das kann für den ersten TestFall einen festen Rückgabewert bedeuten.)
6. Beobachten, dass alle KomponentenTests erfolgreich durchlaufen.
7. Durch CodeRefactoring das bestehende Design verbessern.
8. Beobachten, dass alle KomponentenTests erfolgreich durchlaufen.
9. Den nächsten TestFall überlegen und bei 3. weitermachen. Wenn uns kein sinnvoller TestFall mehr einfällt, sind wir fertig.

• Schreibe einen automatisierten fehlschlagenden Test, bevor Du Produktionscode schreibst.
• Entferne Redundanzen.

1. Schreibe einen automatisierten Test.
2. Lasse alle Tests laufen und beobachte, daß der neue Test (und nur der neue Test) fehl schlägt.
3. Ändere den Produktionscode ein kleines bißchen.
4. Lasse alle Tests laufen und beobachte, daß alle grün laufen. Wenn die Tests rot sind, mache bei Schritt 3 weiter.
5. Refaktorisiere Testcode und Produktionscode.

• TestFirst
• GnadenlosesRefaktorisieren
• EinfachesDesign

/Bücher

Newsgruppen:

• http://groups.yahoo.com/group/testdrivendevelopment/

• TestgetriebenesDesign
• WardsWiki:TestDrivenProgramming
• http://www.testdriven.com/
• http://www.frankwestphal.de/TestgetriebeneEntwicklung.html
• http://www.xprogramming.com/xpmag/testFirstGuidelines.htm
• http://www.objectmentor.com/writeUps/TestDrivenDevelopment
• http://www.ensu.net/
• Aim, Fire
• Artikel von Scott W. Ambler über Extreme Testing