it-swarm.dev

TDD negative Erfahrung

Was ist eine negative Seite Ihrer TDD-Erfahrung? Finden Sie Babyschritte (die einfachste Lösung, um Test grün zu machen) ärgerlich und nutzlos? Finden Sie wartungsfreie Tests wertlos (wenn der Test anfangs Sinn hat, aber in der endgültigen Implementierung dieselbe Logik wie bei anderen Tests überprüft)? usw.

Die obigen Fragen beziehen sich auf Dinge, mit denen ich mich während meiner TDD-Erfahrung unwohl fühle. Ich bin also interessiert, ob andere Entwickler ähnliche Gefühle haben und was sie über sie denken.

Wäre dankbar für die Links zu Artikeln, die negative Seiten von TDD beschreiben (Google wird von positiven und oft fanatischen Artikeln erfüllt).

97
SiberianGuy

Wie alles, was unter das Banner "Agile" fällt, klingt TDD theoretisch gut, aber in der Praxis ist nicht so klar, wie gut es ist (und wie bei den meisten "agilen" Dingen wird Ihnen gesagt, dass Sie dies tun, wenn Sie dies nicht tun mag es, du machst es falsch).

Die Definition von TDD ist nicht in Stein gemeißelt: Leute wie Kent Beck fordern, dass ein nicht kompilierter Test vor einer einzelnen Codezeile geschrieben werden muss und jede einzelne Codezeile geschrieben werden muss, um einen fehlgeschlagenen Test zu bestehen. Das Design vorne ist minimal und alles wird von den Tests angetrieben. Es funktioniert einfach nicht. Ich habe eine große Unternehmens-App gesehen, die mit dieser Methode entwickelt wurde, und ich hoffe, dass dies der schlechtere Code ist, den ich in meiner Karriere sehe (es wird nicht mehr weit sein; und das trotz der Tatsache, dass einige talentierte Entwickler daran arbeiten). Nach allem, was ich gesehen habe, führt dies zu einer großen Anzahl von schlecht durchdachten Tests, die hauptsächlich bestätigen, dass Funktionsaufrufe auftreten, dass Ausnahmen ausgelöst werden, wenn Variablen null sind und das Verspottungs-Framework ein gründliches Training erhält (whoop-de-whoop); Ihr Produktionscode wird stark an diese Tests gekoppelt, und der Traum von ständigem und einfachem Refactoring wird nicht erfüllt. Tatsächlich ist es noch weniger wahrscheinlich, dass Benutzer schlechten Code reparieren, da der gesamte Test unterbrochen wird. In einer solchen Umgebung hätten Software-Manager lieber schlechte Software mit bestandenen Tests und hoher Codeabdeckung als gute Software mit weniger Tests.

Umgekehrt habe ich Leute argumentieren hören, dass TDD bedeutet, die Tests im Rahmen der Planungsphase im Vorfeld auf hohem Niveau zu entwerfen - neben dem architektonischen Entwurf. Diese Tests können sich während der Entwicklung ändern, sobald weitere Informationen verfügbar sind. Sie wurden jedoch sorgfältig geprüft und bieten eine gute Anleitung, was der Code tatsächlich tun sollte. Für mich macht das vollkommen Sinn.

97
user23157

Dieses ( Clojure Autor) Rich Hickey Interview enthält Folgendes. Ich fühle mich zu 100% sympathisch:

Das Leben ist kurz und es gibt nur eine begrenzte Anzahl von Stunden an einem Tag. Wir müssen also entscheiden, wie wir unsere Zeit verbringen. Wenn wir damit verbringen, Tests zu schreiben, verbringen wir keine Zeit damit, etwas anderes zu tun. Jeder von uns muss beurteilen, wie er seine Zeit am besten verbringen kann, um seine Ergebnisse sowohl in quantitativer als auch in qualitativer Hinsicht zu maximieren. Wenn die Leute denken, dass fünfzig Prozent ihrer Zeit damit verbracht werden, Tests zu schreiben, maximieren sie ihre Ergebnisse - okay für sie. Ich bin mir sicher, dass das für mich nicht zutrifft. Ich würde diese Zeit lieber damit verbringen, über mein Problem nachzudenken. Ich bin mir sicher, dass dies für mich zu besseren Lösungen mit weniger Fehlern führt als jede andere Nutzung meiner Zeit. Ein schlechtes Design mit einer vollständigen Testsuite ist immer noch ein schlechtes Design.

Eine weitere ähnliche Aussage von Donald Knuth in Coders at Work Buchinterview, kopiert von hier :

Seibel: Apropos praktische Arbeit: Während Sie an The Art of Computer Programming arbeiteten, haben Sie eine zehnjährige Pause eingelegt, um Ihr Schriftsatzsystem TeX zu schreiben. Ich verstehe, Sie haben die erste Version von TeX komplett außerhalb des Computers geschrieben.

Knuth: Als ich TeX ursprünglich 1977 und 1978 schrieb, hatte ich natürlich keine literarische Programmierung, aber strukturierte Programmierung. Ich schrieb es in einem großen Notizbuch in Langschrift, mit Bleistift. Sechs Monate später, nachdem ich das gesamte Projekt durchlaufen hatte, begann ich, in den Computer zu tippen. Und habe das Debuggen im März 1978 durchgeführt, während ich im Oktober 77 mit dem Schreiben des Programms begonnen hatte. Der Code dafür befindet sich in den Stanford-Archiven - alles in Bleistift - und natürlich würde ich zurückkommen und ein Unterprogramm ändern, sobald ich gelernt habe, was es sein soll. Dies war ein System der ersten Generation, daher waren viele verschiedene Architekturen möglich und mussten verworfen werden, bis ich eine Weile damit gelebt hatte und wusste, was da war. Und es war ein Henne-Ei-Problem - Sie konnten erst setzen, wenn Sie Schriftarten hatten, aber dann konnten Sie keine Schriftarten haben, bis Sie setzen konnten. Aber strukturierte Programmierung brachte mich auf die Idee von Invarianten und wusste, wie man Black Boxes macht, die ich verstehen konnte. Ich hatte also das Vertrauen, dass der Code funktionieren würde, wenn ich ihn endlich debuggen würde. Ich hatte das Gefühl, dass ich viel Zeit sparen würde, wenn ich sechs Monate warten würde, bevor ich etwas teste. Ich hatte genug Vertrauen, dass der Code ungefähr richtig war.

Seibel: Und die Zeitersparnis wäre, weil Sie keine Zeit damit verbringen würden, Gerüste und Stubs zu bauen, um unvollständigen Code zu testen?

Knuth: Richtig.

67
Joonas Pulakka

Meine negative Erfahrung mit TDD war meine erste. TDD klang großartig für mich, ich hatte jahrelang Qualitätssicherung durchgeführt und hatte immer noch die Schrecken im Kopf. Ich wollte jeden Fehler beseitigen, bevor er zu einem Build wurde. Leider garantiert die Verwendung von TDD nicht, dass Sie gute Tests schreiben. Tatsächlich bestand meine anfängliche Veranlagung darin, einfache Tests zu schreiben, die einfachen Code erzeugten. Wirklich einfacher Code, der nur wenige Abstraktionen enthielt. Wirklich einfache Tests, die mit den Klasseneinbauten verflochten waren. Und wenn Sie ein paar tausend kleine Tests durchgeführt haben, haben Sie sicher nicht das Gefühl, dass Sie sich schneller bewegen, wenn Sie hundert davon ändern müssen, um Ihren Code für die Verwendung des sehr wichtigen Domain-Konzepts X umzugestalten.

Das Licht ging für mich an - TDD ist keine Testfähigkeit. Es ist eine Designfähigkeit. Es kann Sie nur mit Übung und einem ständigen Bewusstsein für die Entwurfsrichtungen, in die es Sie führt, zu gutem, einfachem und funktionsfähigem Code führen. Wenn Sie Tests schreiben, um die Codeabdeckung zu gewährleisten, werden Sie spröde Tests erstellen. Wenn Sie Tests schreiben, um Ihre Abstraktionen zu entwerfen, ist dies nur eine strengere Methode zum Schreiben von Top-Down-Code. Sie können den Code zuerst aus der Perspektive des Anrufers sehen, was Sie dazu ermutigt, sein Leben einfacher zu gestalten, anstatt die Interna einer Klasse nach außen zu spiegeln.

Ich denke, TDD ist nützlich, aber ich bin nicht dogmatisch. Wenn diese "wertlosen Tests" die Wartung erschweren - Löschen Sie sie! Ich behandle Tests genauso wie den Rest des Codes. Wenn es weg überarbeitet werden kann und die Dinge einfacher macht, dann mach es!

Ich habe es nicht persönlich gesehen, aber ich habe gehört, dass einige Orte die Codeabdeckung und die Testanzahl verfolgen. Wenn das Sammeln von Metriken ein Nebeneffekt von TDD ist, könnte ich dies auch als negativ ansehen. Ich werde begeistert 1000 Codezeilen löschen, und wenn dies 20 Tests überflüssig macht und meine Codeabdeckung% verringert, na ja.

59
Steve Jackson

Ich werde hier auf die Beine gehen und mit brutaler Ehrlichkeit erklären, dass es buchstäblich eine rituelle Zeitverschwendung ist. (In den meisten Situationen.)

Ich habe ein Buch über Unit Testing gekauft, in dem auch TDD behandelt wurde, und obwohl ich den Vorteilen von UT zustimme, habe ich es nach etwa hundert Stunden des Testens von TDD aus einer Vielzahl von Gründen aufgegeben. Ich bin Art Cross-Posting hier, aber TDD:

  1. Ist keine bessere Dokumentation als echte Dokumentation.
  2. Fängt keine Bugs oder Regressionen ab .
  3. Macht meine Designs nicht wirklich besser, als sie es am Ende sind, wenn ich funktionale Programmierung und Kompositionsfähigkeit Konzepte anwende.
  4. Ist Zeit, die besser für Codeüberprüfungen oder das Polieren von Dokumentationen und Spezifikationen verwendet werden könnte.
  5. Gibt Managern ein falsches Sicherheitsgefühl, wenn sie eine Liste mit Hunderten von grünen Symbolen sehen.
  6. Verbessert die Produktivität bei der Implementierung von Algorithmen mit begrenzten Eingabe-Ausgabe-Zuordnungen.
  7. Ist insofern ungeschickt, als Sie vielleicht wissen , was Sie als Ergebnis von TDD tun, aber Sie verdienen keine Verständnis , warum es so gut funktioniert, warum Ihre Designs so herauskommen, wie sie es tun.

Ein weiteres Problem ist der umstrittene Grad an Perfektion, bis zu dem TDD durchgeführt werden muss, um dies erfolgreich zu tun. Einige bestehen darauf, dass Sie nur leiden werden, wenn TDD nicht von Anfang an von allen Teammitgliedern beharrlich durchgeführt wird. Andere bestehen darauf, dass niemand jemals TDD nach dem Buch macht. Wenn beide wahr sind, dann folgt, dass TDD-Praktizierende leiden, ob sie es realisieren oder nicht.

Wenn man argumentiert, dass man durch TDD-ähnliche Dinge zu Entwürfen kommt, die leicht mit TDD funktionieren, gibt es natürlich viel schnellere Wege, dies zu erreichen - nämlich indem man die Konzepte von TDD tatsächlich studiert Zusammensetzbarkeit. Es gibt viele Ressourcen, sogar eine Menge strenger mathematischer Theorien (hauptsächlich in der funktionalen Programmierung, aber auch in anderen Bereichen). Warum verbringen Sie nicht Ihre gesamte TDD-Zeit mit Lernen ?

Kulturell zeigt TDD Symptome einer rituellen Praxis. Es reitet auf Schuld; es fördert das Verfahren über das Verständnis; Es gibt jede Menge Lehren und Slogans ("fälsche es, bis du es schaffst" ist wirklich ziemlich alarmierend, wenn du es objektiv betrachtest). Die Definition des Wortes "Ritual" durch Wikipedia ist in der Tat ziemlich zutreffend:

In der Psychologie wird der Begriff Ritual manchmal im technischen Sinne für ein sich wiederholendes Verhalten verwendet, das systematisch von einer Person verwendet wird, um Angstzustände zu neutralisieren oder zu verhindern. Es ist ein Symptom für eine Zwangsstörung.

41
Rei Miyasaka

Ein weiteres Problem mit TDD, das mir aufgefallen ist, ist:

TDD verursacht ein versehentliches Verschiebung des Fokus des Entwicklungsteams vom Qualitätscode zu Testfällen und Codeabdeckung! Ich persönlich mochte TDD nicht, da es macht mich weniger kreativ und macht die Softwareentwicklung zu einem langweiligen mechanischen Prozess! Unit-Testfälle sind nützlich, wenn sie mit Bedacht verwendet werden, werden jedoch zu einer Belastung, wenn das Ziel der Softwareentwicklung behandelt wird.

Ich kenne einen Mann, der Manager ist und technisch langweilig ist, als er von TDD besessen war. Es war so magisch für ihn, dass er glaubte, magische Lösungen für alle Probleme in seiner schlecht strukturierten Software mit am wenigsten wartbarem Code zu finden. Um nicht zu sagen, was mit diesem Projekt passiert ist - es ist in seinen Händen kläglich gescheitert, während alle seine Testfälle grün waren. Ich denke, TDD hat ihm geholfen, statistische Informationen wie "99/100 meiner Fälle sind grün" usw. zu erhalten, und das war der Grund für seine Besessenheit, da er niemals in der Lage sein würde, die Qualität zu bewerten oder Verbesserungen im Design vorzuschlagen.

19
WinW

Meine primäre negative Erfahrung ist der Versuch, TDD zu verwenden, um den Code eines anderen Programmierers zu bearbeiten, der keine Tests oder sehr, sehr grundlegende Integrationstests hat. Wenn ich eine Funktion hinzufüge oder ein Problem mit dem Code behebe; Ich würde es vorziehen, zuerst einen Test zu schreiben (auf TDD-Weise). Leider ist der Code eng gekoppelt und ich kann nichts ohne viel Refactoring testen.

Das Refactoring ist sowieso eine großartige Übung, aber es ist erforderlich, um den Code in einen testbaren Zustand zu bringen. Und nach diesem Schritt habe ich keine Kontrolle mehr, um festzustellen, ob meine Änderungen irgendetwas kaputt gemacht haben. kurz bevor die Anwendung ausgeführt und jeder Anwendungsfall untersucht wird.

Auf der anderen Seite wird das Hinzufügen von Funktionen/das Beheben von Fehlern zu einem TDD-Projekt sehr einfach. Mit TDD geschriebener Code ist normalerweise von Natur aus mit kleinen Teilen, mit denen gearbeitet werden soll, ziemlich entkoppelt.

In jedem Fall ist TDD eine Richtlinie. Folgen Sie ihm bis zu dem Punkt, an dem Sie maximale Effektivität erzielen. Anständige Testabdeckung und entkoppelter Code, gut geschriebener Code.

14

Ich habe die Erfahrung gemacht, dass ich mich manchmal zu sehr auf meine Tests verlasse, wenn es um das Design des Systems geht. Ich bin im Grunde zu wenig in den Details der Implementierung, um den Schritt zurück zu machen, um das Gesamtbild zu betrachten. Dies führt häufig zu einem unnötig komplexen Design. Ich weiß, ich sollte den Code umgestalten, aber manchmal habe ich den Eindruck, dass ich viel Zeit sparen könnte, wenn ich öfter einen Schritt zurück mache.

Wenn Sie jedoch ein Framework wie Rails] haben, in dem Ihre Architekturentscheidungen sehr begrenzt sind, sind diese Probleme im Grunde nicht vorhanden.

Ein weiteres Problem ist, wenn Sie Ihren Tests blind vertrauen. Die Wahrheit ist - wie bei jedem anderen Code -, dass Ihre Tests auch Fehler enthalten können. Seien Sie also für Ihre Tests genauso kritisch wie für Ihre Implementierung.

13
sebastiangeiger

Als großer Fan von TDD sehe ich manchmal diese Nachteile

  • Versuchung, zu viele Tests zu schreiben um eine nahezu 100% ige Codeabdeckung zu erreichen. Meiner Meinung nach ist es nicht notwendig, Tests zu schreiben
    • für einfache Property Getter/Setter
    • für jeden Fall, wenn eine Ausnahme ausgelöst wird
    • das überprüft die gleiche Funktionalität durch verschiedene Ebenen. (Beispiel: Wenn Sie nicht in der Lage sind, die Eingabevalidierung für jeden Parameter zu überprüfen, müssen Sie nicht alle diese Tests auch durch einen Integrationstest wiederholen.)
  • Wartungskosten des Testcodes für ähnliche Tests, die nur geringfügig variieren (erstellt durch Codeduplizierung (auch bekannt als Copy-Paste-Vererbung)). Wenn Sie bereits eine haben, ist es einfach, eine ähnliche zu erstellen. Wenn Sie den Testcode jedoch nicht umgestalten, benötigen Sie möglicherweise einige Zeit, um die Tests zu korrigieren, wenn sich die Implementierungsdetails Ihres Geschäftscodes ändern, indem Sie die Codeduplizierung in Hilfsmethoden eliminieren.

  • Wenn Sie unter Zeitdruck stehen, könnten Sie versucht sein, defekte Tests zu beseitigen (oder sie auskommentieren) anstatt sie zu reparieren sie. Auf diese Weise verlieren Sie die Investition in die Tests

11
k3b

Ich habe als Spieleentwickler noch nicht mehr als ein Szenario gesehen, in dem sich TDD gelohnt hat. Und der Fall, in dem dies der Fall war, war ein rein mathematischer Code, der einen soliden Ansatz benötigte, um eine große Anzahl von Edge-Fällen gleichzeitig zu testen - eine seltene Notwendigkeit.

Vielleicht wird irgendwann etwas meine Meinung ändern, aber unter XP Praktiken) die Idee, gnadenlos umzugestalten und Code die Entwicklung seiner eigenen Form ist weitaus wichtiger und führt für mich zu der größten Produktivität, vgl. ein Zitat aus ein Artikel von James Newkirk :

Einfachheit - "Was ist das Einfachste, was möglicherweise funktionieren könnte?"
Die Botschaft ist sehr klar. Entwerfen und schreiben Sie Ihre Software angesichts der heutigen Anforderungen. Versuchen Sie nicht, die Zukunft vorwegzunehmen, sondern lassen Sie die Zukunft sich entfalten. Dies geschieht oft auf sehr unvorhersehbare Weise, sodass Vorfreude zu Kosten wird, die oft zu teuer sind, um sie sich leisten zu können. "

Die Konzepte von Mut und von engeren Rückkopplungsschleifen , die er erwähnt, sind ebenfalls Meiner Meinung nach der Schlüssel zur Produktivität.

9
Engineer

Meine negative TDD-Erfahrung, so begrenzt sie auch sein mag, ist einfach zu wissen, wo ich anfangen soll! Zum Beispiel werde ich versuchen, etwas TDD zu tun, und entweder habe ich keine Ahnung, wo ich anfangen soll, triviale Dinge zu testen (kann ich ein Foo-Objekt neu erstellen, kann ich ein Quux an das übergeben Baz und dergleichen. Tests, die nichts testen) oder wenn ich versuche, es in ein vorhandenes Projekt zu implementieren, muss ich verschiedene Klassen neu schreiben, um sie verwenden zu können TDD. Das Endergebnis ist, dass ich den Begriff schnell ganz aufgeben muss.

Es hilft wahrscheinlich nicht, dass ich oft die einzige Person im gesamten Unternehmen bin, die weiß, was Unit-Tests (TDD oder andere) sind und warum es eine gute Sache ist.

7
Wayne Molina

TDD-Fanatiker.

Für mich sind sie nur einer von vielen religiösen Spinnern, die an meine Tür klopfen und versuchen zu beweisen, dass meine Art, Dinge zu tun, irreparabel gebrochen ist und der einzige Weg zur Erlösung Jesus, Kent Back oder Unit Testing ist.

IMO, ihre größte Lüge ist, dass TDD Sie dazu führen wird heil ein besseres Algorithmus-Design. Siehe den berühmten Soduku-Löser in TDD: hier , hier , hier , hier und hier)

Und vergleichen Sie es Peter Norvig Sudoku-Löser, der nicht mit TDD, sondern mit altmodischer Technik erstellt wurde: http://norvig.com/sudoku.html

7
Cesar Canassa

Wenn Sie TDD aus diesen "fanatischen" Artikeln verwenden, erhalten Sie ein falsches Sicherheitsgefühl, dass Ihre Software keine Fehler aufweist.

5
Dainius

TDD hat einige Vorteile:

  • Sie konzentrieren sich auf wie, um Ihren Code aufzurufen und was Sie zuerst erwarten (während Sie den Test zuerst schreiben), anstatt sich auf die Lösung des Problems zu konzentrieren, und kleben dann einen Aufruf aus der Anwendung ein. Die Modularität erleichtert das Verspotten und Umwickeln.
  • Die Tests stellen sicher, dass Ihr Programm vor und nach einem Refactoring gleich funktioniert. Dies bedeutet nicht, dass Ihr Programm fehlerfrei ist, sondern dass es weiterhin auf die gleiche Weise funktioniert.

Bei TDD geht es um langfristige Investitionen. Der Aufwand zahlt sich aus, wenn Sie den Wartungsmodus Ihrer Anwendung erreichen. Wenn die Anwendung diesen Punkt nicht erreichen soll, können Sie die Investition möglicherweise nie zurückerhalten.

Ich betrachte den TDD-Rot-Grün-Zyklus mit den Babyschritten ähnlich einer Checkliste für ein Flugzeug. Es ist ärgerlich und mühsam, alles im Flugzeug vor dem Start zu überprüfen, besonders wenn es trivial einfach ist (die TDD-Babyschritte), aber es wurde festgestellt, dass es die Sicherheit erhöht. Neben der Überprüfung, dass alles funktioniert, ist es im Wesentlichen setzt die Ebene zurück. Mit anderen Worten, ein Flugzeug wird vor jedem Start neu gestartet.

4
user1249

Ich habe mehr als einmal Code geschrieben, den ich am nächsten Tag verworfen habe, da er ungeschickt war. Ich habe mit TDD neu gestartet und die Lösung war besser. Ich habe also nicht zu viel negative TDD-Erfahrung gemacht. Abgesehen davon habe ich Zeit damit verbracht, über ein Problem nachzudenken und eine bessere Lösung außerhalb des TDD-Bereichs zu finden.

3
user23356

Ich habe festgestellt, dass TDD bei aufstrebenden Systemen eine schlechte Leistung erbringt. Ich bin ein Videospielentwickler und habe kürzlich TDD verwendet, um ein System zu erstellen, das mehrere einfache Verhaltensweisen verwendet, um eine realistisch aussehende Bewegung für eine Entität zu erstellen.

Zum Beispiel gibt es Verhaltensweisen, die dafür verantwortlich sind, Sie von gefährlichen Bereichen unterschiedlicher Art zu entfernen, und Verhaltensweisen, die dafür verantwortlich sind, Sie in interessante Bereiche unterschiedlicher Art zu bringen. Das Zusammenführen der Ausgabe jedes Verhaltens erzeugt eine endgültige Bewegung.

Die Eingeweide des Systems waren einfach zu implementieren, und TDD war hier nützlich, um anzugeben, wofür jedes Subsystem verantwortlich sein sollte.

Ich hatte jedoch Probleme, wenn es darum ging, festzulegen, wie die Verhaltensweisen interagieren und was noch wichtiger ist, wie sie im Laufe der Zeit interagieren. Oft gab es keine richtige Antwort, und obwohl meine ersten Tests bestanden wurden, konnte die Qualitätssicherung immer wieder Edge-Fälle finden, in denen das System nicht funktionierte. Um die richtige Lösung zu finden, musste ich verschiedene Verhaltensweisen durchlaufen. Wenn ich die Tests jedes Mal aktualisiert habe, um die neuen Verhaltensweisen widerzuspiegeln, bevor ich überprüft habe, dass sie im Spiel funktionieren, habe ich die Tests möglicherweise immer wieder verworfen. Also habe ich diese Tests gelöscht.

Ich hätte möglicherweise stärkere Tests haben sollen, die die entdeckten Edge-Fälle der Qualitätssicherung erfassen, aber wenn Sie ein System wie dieses haben, das auf vielen Physik- und Gameplay-Systemen aufbaut, nd haben Sie es mit Verhaltensweisen im Laufe der Zeit zu tun Es wird zu einem Albtraum, genau anzugeben, was passiert.

Ich habe mit ziemlicher Sicherheit Fehler in meinem Ansatz gemacht, und wie ich bereits sagte, hat TDD für die Eingeweide des Systems hervorragend funktioniert und sogar einige optimierende Refaktoren unterstützt.

3
tenpn

Meine negative Erfahrung mit TDD ist etwas, das ich mit vielen neuen und gehypten Sachen fühle. Tatsächlich gefällt mir TDD, weil es die Gültigkeit meines Codes sicherstellt, und noch wichtiger: Ich kann fehlerhafte Tests erkennen, nachdem ich neuen Code hinzugefügt oder Refactoring durchgeführt habe.

Was mich an TDD ärgert, ist die Tatsache, dass es viele Regeln oder Richtlinien gibt. Da es noch ziemlich neu ist, erleben wir die meisten von uns, Anfänger bei TDD zu sein. Was für einige von uns gut funktioniert, funktioniert für andere möglicherweise nicht. Was ich sagen möchte ist, dass es keinen wirklichen "falschen oder richtigen" Weg gibt, TDD durchzuführen: Es gibt einen Weg, der für mich funktioniert - und für mein Team, wenn ich einen habe.

Solange Sie Tests schreiben - vor oder nach dem Produktionscode spielt meiner Meinung nach keine Rolle - bin ich mir nicht sicher, ob testgetrieben wirklich bedeutet, dass Sie alle Richtlinien befolgen müssen, die jetzt angegeben sind, da sie noch nicht bewiesen sind Die ideale Lösung für die tägliche Arbeit. Wenn Sie beim Schreiben von Tests einen besseren Weg finden, sollten Sie ihn in einem Blog veröffentlichen, hier diskutieren oder einen Artikel darüber schreiben. In ungefähr zehn Jahren haben wir vielleicht genug Erfahrung geteilt, um feststellen zu können, welche TDD-Regel in einer bestimmten Situation als gut oder nicht gut angesehen werden kann.

3
Alex