Testgetriebene Entwicklung - überzeugen Sie mich! [geschlossen]

Ich weiß, dass einige Leute massive Befürworter einer testgetriebenen Entwicklung sind. Ich habe in der Vergangenheit Unit-Tests verwendet, aber nur, um Vorgänge zu testen, die einfach getestet werden können oder von denen ich glaube, dass sie möglicherweise korrekt sind. Eine vollständige oder nahezu vollständige Codeabdeckung scheint viel Zeit in Anspruch zu nehmen.

1. Für welche Projekte setzen Sie testgetriebene Entwicklung ein? Verwenden Sie es nur für Projekte ab einer bestimmten Größe?
2. Soll ich es benutzen oder nicht? Überzeuge mich!

Ok, einige Vorteile für TDD:

1. Das bedeutet, dass Sie am Ende mehr Tests haben. Jeder mag mit Tests, aber nur wenige Menschen wie schreiben sie. Wenn Sie das Schreiben von Tests in Ihren Entwicklungsablauf integrieren, erhalten Sie am Ende mehr Tests.
2. Wenn Sie in einen Test schreiben, müssen Sie über die Testbarkeit Ihres Designs nachdenken, und testbares Design ist fast immer besseres Design. Es ist mir nicht ganz klar, warum dies der Fall ist, aber meine Erfahrung und die der meisten TDD-Evangelisten scheinen es zu bestätigen.
3. Hier ist eine Studie, die besagt, dass TDD zwar etwas länger zum Schreiben braucht, sich aber auszahlt, weil Sie Code mit höherer Qualität und damit weniger zu behebenden Fehlern erhalten.
4. Es gibt Ihnen Vertrauen in Refactoring. Es ist ein großartiges Gefühl, ein System ändern zu können, ohne sich Gedanken darüber machen zu müssen, was sonst noch alles passiert, da es durch Unit-Tests ziemlich gut abgedeckt ist.
5. Sie bekommen so gut wie nie einen Wiederholungsfehler, da jeder, den Sie finden, einen Test erhalten sollte, bevor er behoben wird.

Sie wollten überzeugt sein, das waren also Vorteile. Siehe diese Frage für eine ausgewogenere Sichtweise.

Robert C. Martin hat diese Punkte ursprünglich angesprochen - ich kann sie aus eigener Erfahrung bestätigen:

• Sie erstellen automatisch eine Regressionstestsuite mit Komponententests.
• Sie werden kaum Zeit mit dem Debuggen verbringen, als ob Sie sich selbst in eine Lücke codieren. Es ist einfacher, Ihren Code bis zu dem Punkt rückgängig zu machen, an dem der letzte Test bestanden wurde, als einen Debugger aufzubrechen.
• Alle paar Minuten überprüfen Sie, ob Ihr Code funktioniert - alles (oder zumindest das gesamte Verhalten, das von den Tests abgedeckt wird. Wenn Sie TDD ausführen, ist dies ein sehr hoher Prozentsatz davon).

Ich mache die ganze Zeit TDD, egal ob ich an der Produktion arbeite oder Code spiele. Ich finde es heutzutage schwierig, anders zu codieren.

(Haftungsausschluss: Ich mache kaum UI-Sachen, daher kann ich TDD für UIs nicht besprechen.)

Ich verwende TDD in so ziemlich allem, was ich tue, von einfachen Apps bis zu ganzen SIP-Stacks.

Ich verwende TDD nicht in einer alten PHP-Website, die ich übernommen habe. Ich finde es schmerzhaft, keine Tests zu haben. Und ich finde es sehr ärgerlich, versehentlich Teile der Website zu beschädigen, weil ich keine Regressionstestsuite habe, die mir sagt, dass ich etwas kaputt gemacht habe. Der Client hat nicht das Budget für mich, um (a) Tests für die Codebasis zu schreiben und (b) dabei den Code überhaupt erst testbar zu machen, also habe ich es einfach in Kauf genommen.

• Wann immer Ihr Kunde effektiver beliefert werden kann (möglicherweise beziehen sie sich gut auf Tests - und es wird zumindest das Ende der Projektdiskussion verkürzt)
• Wann immer es länger dauern würde, Ihre Mitentwickler über ALLES im Code auf dem Laufenden zu halten, als sich Mühe zu geben, den Test zu erstellen - und das ist früher, als Sie vielleicht denken

Was? Keine negative Antwort!?

Haftungsausschluss: Ich bin kein Einheitentester. Wenn Leute TDD sagen, dann meine ich damit die krankheitserregende Version, in der sie Tests schreiben, bevor sie den Code für 80-100% des gesamten Codes schreiben, den sie schreiben.

Ich würde argumentieren:

• Es ist ein Wegbereiter. Wenn das Auffinden von Regressionsproblemen für Sie ein so großes Problem ist, dass sich eine vollautomatische TDD von Anfang an lohnt, kann das Schreiben von Tests für jeden letzten Code, den Sie schreiben, Ihnen tatsächlich dabei helfen, das eigentliche Problem zu ignorieren.

• Es hilft den Menschen, das eigentliche Problem zu ignorieren. Wenn sich das Beheben eines Fehlers in ein Schlag-auf-Schlag-Spiel verwandelt, bei dem zwei weitere auftauchen, bläst die Architektur. Fokus. Konzentrieren Sie sich auf das eigentliche Problem. Die Maulwürfe zu sehen, bevor sie verprügelt werden müssen, ist nett, aber Sie sollten nicht an erster Stelle dabei sein.

• Es frisst viel Zeit. Ich habe gelegentlich Fehler gefunden. Ich treffe nicht so viele, dass es sich zu lohnen scheint, jeder neuen Sache, die ich schreibe, einen Test voranzustellen. Ermitteln Sie Probleme, bei denen sie wahrscheinlich auftreten werden. Behandeln Sie Fehler so, dass sie leicht zu diagnostizieren sind. Bestätigen. Testen Sie an wichtigen Überlappungs- / Engpasspunkten. Aber um laut zu schreien, testen Sie nicht jeden letzten Getter und Setter in etwas, das diese wahrscheinlich gar nicht erst hätten haben sollen.

• Designfokus: Es gibt absolut keine Möglichkeit, dass selbst ein guter Entwickler den bestmöglichen Code schreibt, wenn er sich auch auf den Test konzentriert. Wenn es Ihnen als die einzige Möglichkeit erscheint, ein anständiges Design zu haben, empfehle ich, die obigen Ausführungen zum Thema "Konzentration auf das eigentliche Problem" zu lesen.

• Macro-Design Fail: Die Codebasis in meinem aktuellen Job ist voll von Schnittstellen, die nie mehr als einmal verwendet werden, und massiven Verstößen gegen das DRY-Prinzip, die ich erst begriff, als ich merkte, dass Leute für die Test-Frameworks und das Testen in schrieben Allgemeines. Testen sollte nicht zu blöder Architektur führen. Nein, es gibt nichts Skalierbareres oder Unternehmenswerteres, als 20 Dateien zu kopieren und einzufügen und dann nur zwei davon signifikant zu verändern. Die Idee ist, Bedenken zu trennen und nicht in der Mitte aufzuteilen. Cruft und sinnlose Abstraktion kosten Sie mehr als 95% Abdeckung jemals haben wird.

• Es ist sehr beliebt und viele Leute mögen es wirklich. Wenn das nicht Grund genug ist, vor der Adoption die Technologie zumindest zu überdenken und / oder den Mist zu beseitigen, lernen Sie etwas Paranoia.