Vorgehensweise von testgetriebener Entwicklung (TDD)?

Hallo, ich hab mich einwenig mit Unit-Test eingelesen, nun gibt es die Testgetriebene Entwicklung, in der zuerst die Tests geschrieben werden und dann der Code.

Ich hab nun ein paar Fragen:

• Ich hab gelesen das im Code die Funktionen eingebaut werden aber ohne irgendwelche Logik, dann wird der Test geschrieben der die Funktion testet, welches dann logischerweise fehlschlägt. Nun muss der Code in die Funktion implementiert werden, stimmt das?

• Ich als Entwickler habe anfangs eine Idee, normalerweise würde man gleich los programmieren, wie sieht es nun mit TDD aus, wo fängt man da an?

Über weitere Infos würde ich mich freuen.

Hallo #coder#,

Zu erst erstellt man ein Design und definiert so die Signatur aller Methoden (besser gesagt die Signatur von allem was man entwickelt, Klassen, Methoden, Assemblies, etc.) und das zu erwartende Ergebniss.

Wenn man diese Angaben hat kann man die Unit-Tests dazu schreiben, ohne vorher die zu testenden Dinge entwickelt zu haben.

Die erste Frage hast du dir ja selbst behandelt. Nur muss man eben drauf achten erst "alle" Unit-Tests für einen Komponente (Assembly, Klasse, ...) geschrieben zu haben bevor man anfängt diese zu Entwicklen.

Gruß
Juy Juka

Hallo #coder#,

• Ich hab gelesen das im Code die Funktionen eingebaut werden aber ohne irgendwelche Logik, dann wird der Test geschrieben der die Funktion testet, welches dann logischerweise fehlschlägt. Nun muss der Code in die Funktion implementiert werden, stimmt das?

ja, siehe auch Testgetriebene Entwicklung

• Ich als Entwickler habe anfangs eine Idee, normalerweise würde man gleich los programmieren, wie sieht es nun mit TDD aus, wo fängt man da an?

Bei einfachen, kleinen Projekten kann man auch einfach anfangen. Bei größeren Projekten sollte man immer erst eine Analyse und ein Design machen, egal ob man TDD einsetzen will oder nicht.

herbivore

Hallo,

Nur muss man eben drauf achten erst "alle" Unit-Tests für einen Komponente (Assembly, Klasse, ...) geschrieben zu haben bevor man anfängt diese zu Entwicklen.

Dem wuerde ich nicht so zustimmen, JuyJuka. Ich wurde nicht einfach "alle" erdenklichen Unit-Tests am Anfang schreiben, sondern nach und nach. Also auch den evolutionären Gedanken bei den Tests einhalten. Ich schreibe den ersten Test, dann entsprechenend dazu die Implementierung. Anschliessend ändert sich der die Implementierung und ich passe den Test an, gegebenenfalls fuege ich einen neuen Test hinzu. Ausserdem kann das TDD Einfluss auf das Interface haben, weil man bei dem Testen merkt, dass die Schnittstelle/das Design nicht ganz optimal durchdacht ist. Somit muesste ich bereits bestehende Tests fuer die es noch keine Implementierung gibt, umschreiben. Deswegen halte ich es fuer ungluecklich alles Test zu Anfang zu schreiben zumal alle gleich fehlschlagen werden. Somit muss ich erst alle Tests erfuellen bis ich mit dem ersten fortfahren kann. Kann sein, dass ich Dich missverstandenhabe JuyJuka, aber dann korrigier mich bitte.

Gruss, DaMoe

Vom Ablauf her sieht es folgendermaßen aus:

Es fehlen noch die Farben bei Dir ,aequitas , sodass wir auch auf das Motto kommen: Red-Green-Refactor 😉

Hallo DaMoe80,

Es handelt sich um ein halbes Missverständniss. Ich hab das "alle" in Anführungszeichen gesetzt, da man eigentlich nie alle möglichen Testfälle abprüfen kann. Und meinen tu ich mit "alle": Alle Testfälle die im momentanen Entwurfszustand bekannt sind.
Wo bei man hier zwischen Entwurf und Implementation unterscheiden muss. Der Entwurf ist/sollte immer das gesammte System sein, dass auch (theoretisch) Funktioniert.

Gruß
Juy Juka

Hallo DaMoe80

Ich stimme dir zwar grösstenteils zu, auch der evolutionären Entwicklung und das TDD das Design im Extremfall sogar erst entstehen lassen kann.

Anschliessend ändert sich der die Implementierung und ich passe den Test an, gegebenenfalls fuege ich einen neuen Test hinzu.

Auch laut YAGNI sollten sich die Tests (Anforderungen) ändern, bevor sich die Implementierung (Lösung) ändert.

So hat man in jedem Fall eine fast komplette Abdeckung und implementiert auch nur das was gefordert ist.

Gruss Peter