TDD: String Calculator Kata In Python



  • Hallo,

    da ich mich im Moment über "test driven development" informiere, bin ich über folgendes Video gestolpert: http://vimeo.com/8569257 .

    Ich versuche gerade zu verstehen, was der Sinn jedes Schrittes im TDD ist. Was ich bis jetzt nicht verstehe ist, wieso es explizit erwünscht ist, den neuen Test mit einem Hack bestehen zu lassen bevor man den Quelltext refactort. Das sieht man sehr oft in der Kata im Video, z.B. wenn "return 3" an bestimmten Stellen eingefügt wird. Soll es lediglich die Schwächen des neuen Tests aufzeigen?

    ❤



  • Erst durch einen funktionierenden Test kann man sinnvoll refactoren.

    1. Man erstellt den Test
    2. -> Fail
    3. Man erstellt die Klassen/Methoden und returniert das gewünschte Ergebnis
    4. -> Pass

    Wenn mehr conditions notwendig sind wiederholt man 1 bis 4. Erst sobald man alle fälle abgedeckt hat und alles passt refactored man so das nie ein Test failed.

    Wenn man zwischendurch schon refactored, kann es sein das es durch die nächsten tests dann nicht mehr so richtig passt, dann muss man es wieder und wieder ändern.

    Kann dir das TDD Buch von Kent Beck empfehlen. Videos taugen nichts da du dort zwar die schritte siehst, aber nicht warum etwas wie gemacht wird.
    (Ist auch im The Clean Coder von Martin ein Thema)



  • Durch diese "blöden Lösungen" zwingst du dich für wirklich jede Kleinigkeit einen Test zu schreiben, bis dir nichts anderes mehr übrig bleibt als eine korrekte Implementierung zu machen.
    Halte ich auf Dauer für nicht durchhaltbar.



  • Klar ist das "durchhaltbar". Ich habe schon einige Firmen getroffen die nur noch nach diesem Prinzip entwickeln.
    Keine Tests sind schlecht, da sind wir uns alle einig denk ich.
    Aber Tests die gerade das notwendigste abdecken sind auch schlecht, die liefern zu schnell ein False Positive. Ist am ende also noch schlimmer da man sich dann zu sehr darauf verlässt das alles funktioniert.
    Und die Tests hinterher schreiben ist auch schlecht, da man die Implementation dann schon kennt und zu eingeschränkt in der Sicht ist.
    Das ist in diversen Büchern sehr schön beschrieben.


Anmelden zum Antworten