Testgetriebene Entwicklung - Überzeugen Sie mich! [abgeschlossen

Question

Ich weiß, dass einige Menschen massive Befürworter der Testentwicklung sind. Ich habe in der Vergangenheit Unit -Tests verwendet, aber nur, um Operationen zu testen, die leicht getestet werden können oder die meiner Meinung nach möglicherweise korrekt ist. Die vollständige oder nahezu vollständige Codeabdeckung klingt so, als würde es viel Zeit dauern.

1. Für welche Projekte verwenden Sie eine testgesteuerte Entwicklung? Verwenden Sie es nur für Projekte über einer bestimmten Größe?
2. Soll ich es benutzen oder nicht? Überzeuge mich!

Answer 1

Ok, einige Vorteile gegenüber TDD:

1. Es bedeutet, dass Sie mehr Tests haben. Jeder mag haben Tests, aber nur wenige Menschen mögen Schreiben Sie. Das Aufbau von Tests in Ihren Entwicklungsfluss bedeutet, dass Sie mehr Tests haben.
2. Das Schreiben in einen Test zwingt Sie dazu, über die Testbarkeit Ihres Designs nachzudenken, und ein Testable -Design ist fast Immer besseres Design. Mir ist nicht ganz klar, warum dies der Fall ist, aber meine Erfahrung und die der meisten TDD -Evangelisten scheint es zu tragen.
3. Hier ist eine Studie Sagen Sie, dass TDD zwar etwas länger dauert, um zu schreiben, aber es gibt eine gute Kapitalrendite, da Sie Code von höherer Qualität erhalten und daher weniger Fehler zu beheben.
4. Es gibt Ihnen Vertrauen in die Wiederaufnahme. Es ist ein großartiges Gefühl, ein System zu verändern, ohne sich Gedanken darüber zu machen, alles andere zu brechen, da es ziemlich gut durch Unit -Tests abgedeckt ist.
5. Sie erhalten fast nie einen Wiederholungsfehler, da jeder, den Sie finden, einen Test erhalten sollte, bevor er eine Lösung erhält.

Sie haben darum gebeten, überzeugt zu sein, also waren dies Vorteile. Sehen diese Frage für eine ausgewogenere Sicht.

Answer 2

Robert C. Martin hat ursprünglich diese Punkte gemacht - ich kann sie aus meiner eigenen Erfahrung unterstützen:

• Sie erstellen automatisch eine Regressionstestsuite von Unit -Tests, während Sie gehen.
• Sie werden kaum Zeit damit verbringen, zu debuggen, als ob Sie sich in ein Loch codieren würden. Es ist einfacher, Ihren Code bis zu dem Punkt zu rückgängigen, als der letzte Test bestand, anstatt einen Debugger zu öffnen.
• 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 machen, ist dies ein sehr hoher Prozentsatz davon).

Ich mache die ganze Zeit so ziemlich TDD, egal ob ich an Produktion oder Spielcode arbeite. Ich finde es heutzutage schwierig, andere Weise auf andere Weise zu codieren.

Answer 3

(Haftungsausschluss: Ich mache kaum ein UI -Sachen, also kann ich nicht über TDD für UIS diskutieren.)

Ich benutze TDD in so ziemlich allem, was ich tue, von trivialen Apps bis hin zu ganzen SIP -Stapeln.

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

Answer 4

• Wann immer Ihr Kunde effektiver geliefert werden kann (er bezieht sich möglicherweise gut auf Tests-und es wird zumindest die Diskussion des Projekts reduzieren)
• Wenn es länger dauern würde, halten Sie Ihre Co -Entwickler über alles im Code auf dem Laufenden, als sich beim Aufbau des Tests zu bemühen - und dies ist früher als Sie vielleicht denken

Answer 5

Was? Keine negative Antwort !?

Haftungsausschluss: Ich bin nicht gegen Einheiten-Tests. Wenn die Leute TDD sagen, gehe ich davon aus, dass sie die von der Krankheit klingende Version meinen, bei der sie Tests schreiben, bevor sie den Code für 80-100% des von ihnen geschriebenen Codes schreiben.

Ich würde argumentieren:

• Es ist ein Enabler. Wenn das Fangen von Regressionsproblemen für Sie ein so großes Problem ist, dass sich von Anfang an die Vollauto-TDD lohnt, können Sie das eigentliche Problem ignorieren.

• Es hilft den Menschen, das eigentliche Problem zu ignorieren. Wenn Sie einen Fehler beheben, wird es in ein Spiel mit Whack-a-Mole, bei dem zwei weitere Pop-up, die Architektur, bläst. Fokus. Konzentrieren Sie sich auf das eigentliche Problem. Die Maulwürfe zu sehen, bevor sie geschlagen werden müssen, ist ordentlich, aber Sie sollten nicht überhaupt nicht da sein.

• Es isst viel Zeit. Ich habe gelegentliche Fehler geschlagen. Ich mache nicht so viele, dass es sich lohnt, jedes neue Ding zu präfixen, das ich mit einem Test dafür schreibe. Fangen Sie Probleme, bei denen sie wahrscheinlich passieren werden. Behandeln Sie Fehler so, dass sie leicht zu diagnostizieren sind. Bestätigen. Testen Sie an wichtigen Punkten von Überlappung/Engpass. Aber um laut zu weinen, testen Sie nicht jeden letzten Getter und Setter in etwas, das diese wahrscheinlich überhaupt nicht hätte haben sollen.

• Design Focus: Es gibt absolut keine Möglichkeit, dass selbst ein guter Entwickler den besten Code schreiben wird, den sie auch auf den Test konzentrieren. Wenn es so aussieht, als ob Sie nur ein anständiges Design haben können, würde ich empfehlen, die oben genannten "auf das eigentliche Problem zu konzentrieren".

• Makrodesign Fail: Die Codebasis bei meinem aktuellen Job ist mit Schnittstellen durchsetzt, die nie mehr als einmal verwendet werden, und massive Verstöße gegen das grundlegende Trockenprinzip, das ich erst schließlich zu verstehen begann, als ich feststellte Allgemeines. Tests sollten nicht zu einer dummen Architektur führen. Nein wirklich, es gibt nichts, was irgendwie skalierbarer oder unternehmungsvoller ist, um 20 Dateien zu kopieren und zu kleben und dann nur erhebliche Änderungen an zwei von ihnen vorzunehmen. Die Idee ist, Bedenken zu trennen und sie nicht in der Mitte aufzuteilen. Cruft und sinnlose Abstraktion kosten Sie mehr als nicht 95%.

• Es ist sehr beliebt und viele Leute mögen es wirklich. Wenn das nicht Grund genug ist, mindestens zweitklassiger zu ägen und/oder zu prüfen, ob die Technologie vor der Einführung eine Paranoia ausgeht.