TestDrivenDevelpment

[Guest]

Hallo,

habe mir gerade einige Eclipse/Java Tutorials von sourceforge angesehen. Was ich nicht verstehe (bei den JUnit Tests) Wieso ist es sinnvoll erst einen Test zu schreiben der eine noch nicht exisitierende Methode prüft und dann erst die Implementierung vorzunehmen? Ist es nicht sinnvoller erst zu programmieren und dann zu testen und wenn nein, wieso nicht? Ich muss mir doch in beiden Fällen erst überlegen was die Methode leisten soll.

Viele Grüße

alex

 

[maki]

Klingt komisch, ist aber so

Bei TDD ist Testen eine Designtätigkeit, keine reine Verifikation wie beim klassischen Modell (Klasse -> schreiben -> tests schreiben bzw. Klasse schreiben -> keine Zeit für Tests -> bugs suchen anstatt zu refactoren).

Nachtrag: Kent BEck hat ein imho sehr gutes Buch dazu geschrieben, Test Driven Development by Example.

 

[tfa]

Der Vorteil ist, dass auf jeden Fall ein Test zu dem Code existiert, den du schreibst (weil der Test ja zuerst da ist). Umgekehrt könnte man schnell einen Test vergessen oder verschlampen - wie maki schon gesagt hat.
Das heißt, deine Testabdeckung bleibt theoretisch immer maximal - wenn du das wirklich so durchziehen kannst.

Du interessante Frage ist: Wer arbeitet tatsächlich nach diesem Test-First-Ansatz? Also jetzt wirklich in der Praxis, abgesehen von eigenen Spielprojekten, Tutorials und Seminaren.

 

[ARadauer]

Wer arbeitet tatsächlich nach diesem Test-First-Ansatz?

ich nicht.
ich muss gestehen, ich arbeite oft nach dem "es läuft also feierabend" paradigma.....

 

[maki]

Du interessante Frage ist: Wer arbeitet tatsächlich nach diesem Test-First-Ansatz? Also jetzt wirklich in der Praxis, abgesehen von eigenen Spielprojekten, Tutorials und Seminaren.

Seit ein paar Wochen so oft wie möglich.

Ist natürlich schwer, wenn man Erweiterungen für bestehende Systeme schreibt, die weder annähernd genug Tests haben bzw. in denen das gewachsene Design schwer bis gar nicht vernünftig zu testen ist.

Bei gutem Design kann man tests sehr einfach schreiben (exlipizite anstatt implizieter abhängigkeiten, interfaces statt klassen, etc. pp.), TDD fördert gutes Design.
So kommen sog. "Trainwrecks" (obj.getRef1.getRef2.getRef3.setSomething(something) ) nicht mehr vor, denn das würde nie passieren, wenn man weiss wie diese Property zugegriffen wird, das Paradigma dazu heisst "tell, don't ask".
"lean development" ist ein weiterer positiver nebeneffekt (nur das programmieren was wirklich gebraucht wird), Refactoring ist Dank der Tests nicht nur möglich, sondern gehört zum festen Zyklus:
Red/Green/Refactor
"make it work, make it clean" eben.

Die Tests bei TDD sind übrigens nicht annähernd so ausführlich wie beim klassischen Testen, anstatt 60-100 Unittest pro komplexer Klasse gibt es max. 6-10.

Das beste aber ist das gewonnene selbstvertrauen, ich kann die komplett Kiste umbauen, ohne das etwas schiefgeht, man muss eben nicht mehr mit den Fehlern der Vergangenheit eben, aber eben nur, wenn TDD konsequent angewendet wurde.

Und es macht wirklich Spass..

 

[foobar]

Schreibst du für jede Klasse einen Unittest? Also bei einer Springanwendung ist es ja durch das Dependency Injection sehr einfach Unittests und Mockobjekte zu erstellen aber für einen Dialog habe ich noch nie einen Unittest geschrieben.

 

[maki]

Für Dialoge kann man oft keine Unittests schreiben, im Webbereich müssen das schon Integrationtests sein, sehr aufwändig, langsam und deswegen imho nicht für TDD geeignet.

Aber man kann natürlich Unittests für die Domainklassen schreiben, ohne die Infrastruktur (Persistenz, Präsentation, etc. pp.) haben zu müssen, so kann man auch sehr scchnell Prototypen entwickeln.

"Dependency Injection" ist immer eine gute Sache, auch ohne Spring, siehe meinen obigen Kommentar zum Thema expliziter Abhängigkeiten.

TDD und Spring passen übrigens sehr gut zusammen ("Interface discovery" ist eine der Designaktivitäten beim TDD.), da ist EJB mal wieder aussen vor und ein bisschen zurückgeblieben, naja, zumindest sind die Entitäten nun POJOs und damit "Unittestbar", gilt natürlich nicht für Sessionbeans.

Man muss halt über seinen Schatten springen und sich die Praktiken aneignen, zuerst den Test schreiben hört sich halt schräg an aber funkioniert sehr gut.