DseWiki: TestgetriebeneEntwicklung

Veränderung (zum vorhergehenden Autor) (Änderung, Korrektur, Normalansicht)

Hinzugefügt: 16a17,33

In TestDrivenDevelopmentByExample stellt KentBeck das sehr viel einfacher dar, als oben beschrieben:
* Schreibe einen automatisierten fehlschlagenden Test, bevor Du Produktionscode schreibst.
* Entferne Redundanzen.

Um diese beiden Regeln einzuhalten, führt der TestInfizierte folgende Schritte iterativ aus:
# Schreibe einen automatisierten Test.
# Lasse alle Tests laufen und beobachte, daß der neue Test (und nur der neue Test) fehl schlägt.
# Ändere den Produktionscode ein kleines bißchen.
# Lasse alle Tests laufen und beobachte, daß alle grün laufen. Wenn die Tests rot sind, mache bei Schritt 3 weiter.
# Refaktorisiere Testcode und Produktionscode.

Testgetriebene Entwicklung hat weitere XP-Techniken integriert:
* TestFirst
* GnadenlosesRefaktorisieren
* EinfachesDesign

TestgetriebeneEntwicklung basiert auf der Idee, die Implementierung der Software im wesentlichen von KomponentenTests steuern zu lassen. Eine EntwicklungsAufgabe? wird dabei in kleinen Schritten realisiert:

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.
Den ersten, einfachen TestFall schreiben.
Den TestFall (falls notwendig) kompilieren. Nötigenfalls dummy-Implementierungen für neue Schnittstellen einrichten.
Beobachten, dass der TestFall fehlschlägt.
Den TestFall auf die einfachst mögliche Art und Weise erfüllen. (Das kann für den ersten TestFall einen festen Rückgabewert bedeuten.)
Beobachten, dass alle KomponentenTests erfolgreich durchlaufen.
Durch CodeRefactoring das bestehende Design verbessern.
Beobachten, dass alle KomponentenTests erfolgreich durchlaufen.
Den nächsten TestFall überlegen und bei 3. weitermachen. Wenn uns kein sinnvoller TestFall mehr einfällt, sind wir fertig.

Eine solche Mini-Iteration sollte im Allgemeinen nur wenige Minuten lang sein. Ist man länger als zehn Minuten mit der Realisierung eines Testfalls beschäftigt, so empfiehlt es sich, den aktuellen Testfall zu verwerfen und in mehrere kleinere zu zerlegen.

In TestDrivenDevelopmentByExample stellt KentBeck das sehr viel einfacher dar, als oben beschrieben:

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

Um diese beiden Regeln einzuhalten, führt der TestInfizierte folgende Schritte iterativ aus:

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

Testgetriebene Entwicklung hat weitere XP-Techniken integriert:

/Bücher

Newsgruppen:

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

Siehe auch:

KategorieXp KategorieTesten