Testgetriebene Entwicklung - Meinung?

[Dailox]

Hiho!
Ich wollte mal fragen, was ihr von testgetriebener Entwicklung haltet und was ihr so für Erfahrungen damit gemacht habt.
Mein aktuelles Problem ist halt, dass die Tests die ich schreibe ja sowieso von mir kommen und ich sofort alles abdecke.
Zumal es sowieso so ist, dass man, wenn man Tests schreibt, doch selber eh nur an die Dinge denkt die man auch beim implementieren einbaut und abdeckt bzw. auffängt.

Macht für euch testgetriebene Entwicklung also nur Sinn im Team oder was haltet ihr davon?
Würde mich wirklich mal interessieren.

[Jut4h.tm]

Du schreibst für jede Funktion/Methode einen Test. Jedesmal wenn du deinen Code kompilierst bzw ausführst werden alle Tests gemacht und du siehst ob alle Methoden noch das machen was sie sollen. Es geht meiner Meinung nach nicht um das Team sondern um die Größe des Projekts.

Stell dir vor du entwickelst einen Browser. Du hast viele User und alles funktioniert wie es soll. Dann entscheidest du dich dazu eine "Addon Engine" zu Implementieren und updatest den Browser. Plötzlich funktionieren die Lesezeichen nicht mehr weil du das natürlich nicht normal getestet hast, die Funktion ist ja schon Jahre alt und lief immer. Du kannst ja nicht jedesmal alle Funktionen testen nur weil du was kleines am Code veränderst. Aber auch kleine Änderungen können viel zerstören was du nicht direkt im blick hast weil der Code einfach zu alt und zu groß ist.

Also für kleine Projekte macht das meiner Meinung nach keinen sinn. Für große ist das super.

[Coffeeman]

Ich glaube es geht hier weniger darum ob Tests per se sinnvoll sind oder nicht sondern eher um das TDD selbst.

Tests sind mMn eher weniger da um zu testen ob der Code das macht was er soll, sondern eher um zu prüfen ob er noch das tut, was er vorher tat (eben wie du schon geschrieben hast).

Und da ist der Ablauf nämlich du schreibst erst den Test, dann den Code.

Bspw an einem Taschenrechner: Du willst die Funktion Plus implementieren für alle reelen Zahlen.
Jetzt schreibst du deine Tests für Plus mit 0, mit einer negativen Zahl, mit sehr kleinen Gleitkommazahlen welche auf sehr große addiert werden, etc.
In den Tests selbst legst du dann quasi das Verhalten des Codes schon fest, da du ja ein gewisses Ergebnis erwartest.

Erst danach schreibst du den eigentlichen Code. ;-)

Persönlich finde ich den Aufwand dafür sehr hoch, jedes mal x Testfälle zu schreiben, was auch nicht immer trivial ist: Die Tests müssen für sich alleine stehen können und von möglich nichts anderem Abhängen, weil man sonst jedes mal wenn man im Code was ändert 300 fehlgeschlagene Tests hat. Und leider ist damit ja noch nicht genüge getan, es bleiben ja weiterhin die anderen Tests wie Integrationstests bestehen. Gibt da eine schöne Grafik:



Klar liefert das TDD zusammen mit Entwicklern die ordentliche Tests schreiben können sehr gute Resultate, vor allem was die Codequalität betrifft.
Nur irgendwo bleibt dann mMn den Entwickler auf der Strecke, denn wer hat ernsthaft Lust 70% der Zeit nur Tests zu schreiben? Und wenn man mal auf die "Softwaregroßprojekte" wie Netflix guckt, dann sieht man auch das diese bewusst kein TDD nutzen. ;-)

[sontyp]

Kannst TDD auch nutzen, um die eigentliche Implementierung outsourcen zu lassen.
Klar kannst du auch einfach ein Interface erstellen, das dann alle gewünschten Methoden/Funktionen auflistet, aber bei aus Tests lässt sich präzise auslesen, was denn eigentlich für Ergebnisse gewollt sind.

[Dailox]

Alles klar, danke!