it-swarm-eu.dev

Nachteile der testgetriebenen Entwicklung?

Was verliere ich, wenn ich testgetriebenes Design übernehme?

Nur Negative auflisten; Listen Sie keine in negativer Form geschriebenen Vorteile auf.

189
IanL

Einige Nachteile (und ich behaupte nicht, dass es keine Vorteile gibt - besonders wenn man die Grundlage eines Projekts schreibt - es würde am Ende viel Zeit sparen):

  • Großinvestition. Für den einfachen Fall verlieren Sie ungefähr 20% der tatsächlichen Implementierung, für komplizierte Fälle jedoch viel mehr.
  • Zusätzliche Komplexität. Für komplexe Fälle, bei denen Ihre Testfälle schwerer zu berechnen sind, würde ich in solchen Fällen vorschlagen, stattdessen den automatischen Referenzcode zu verwenden, der parallel in der Debug-Version/im Testlauf ausgeführt wird des Komponententests der einfachsten Fälle.
  • Auswirkungen auf das Design. Manchmal ist das Design zu Beginn nicht klar und entwickelt sich im Laufe der Zeit weiter. Dies zwingt Sie dazu, Ihren Test zu wiederholen, was zu einem großen Zeitverlust führt. In diesem Fall würde ich vorschlagen, Unit-Tests zu verschieben, bis Sie sich ein Bild vom Design gemacht haben.
  • Continuous Tweaking. Für Datenstrukturen und Black-Box-Algorithmen wären Unit-Tests perfekt, aber für Algorithmen, die dazu neigen, geändert, optimiert oder feinabgestimmt zu werden, kann dies eine große Zeitinvestition verursachen, von der man behaupten könnte, dass sie es nicht ist gerechtfertigt. Verwenden Sie es also, wenn Sie glauben, dass es tatsächlich zum System passt, und zwingen Sie das Design nicht dazu, es an TDD anzupassen.
126
Adi

Wenn Sie ein "echtes" TDD durchführen möchten (lesen Sie: Testen Sie zuerst mit den roten, grünen und Refactor-Schritten), müssen Sie auch anfangen, Mocks/Stubs zu verwenden, wenn Sie Integrationspunkte testen möchten.

Wenn Sie nach einer Weile mit der Verwendung von Mocks beginnen, sollten Sie mit der Verwendung von Dependency Injection (DI) und einem IoC-Container (Inversion of Control) beginnen. Um dies zu tun, müssen Sie Schnittstellen für alles verwenden (die selbst viele Fallstricke aufweisen).

Am Ende des Tages müssen Sie viel mehr Code schreiben, als wenn Sie es einfach auf die "normale" Weise tun. Anstelle nur einer Kundenklasse müssen Sie auch eine Schnittstelle, eine Scheinklasse, einige IoC-Konfigurationen und einige Tests schreiben.

Und denken Sie daran, dass der Testcode auch gewartet und gepflegt werden sollte. Tests sollten so gut lesbar sein wie alles andere und es braucht Zeit, um guten Code zu schreiben.

Viele Entwickler verstehen nicht ganz, wie man all dies "richtig" macht. Aber weil ihnen alle sagen, dass TDD der einzig wahre Weg ist, Software zu entwickeln, versuchen sie einfach das Beste, was sie können.

Es ist viel schwieriger als man denkt. Projekte, die mit TDD erstellt wurden, enthalten oft viel Code, den niemand wirklich versteht. Die Unit-Tests testen oft das Falsche, den falschen Weg. Und niemand ist sich einig, wie ein guter Test aussehen soll, nicht einmal die sogenannten Gurus.

All diese Tests machen es viel schwieriger, das Verhalten Ihres Systems zu "ändern" (im Gegensatz zum Refactoring), und einfache Änderungen werden einfach zu schwierig und zeitaufwendig.

Wenn Sie die TDD-Literatur lesen, gibt es immer einige sehr gute Beispiele. In realen Anwendungen müssen Sie jedoch über eine Benutzeroberfläche und eine Datenbank verfügen. Hier wird TDD wirklich schwierig, und die meisten Quellen bieten keine guten Antworten. Und wenn doch, sind immer mehr Abstraktionen erforderlich: Scheinobjekte, Programmierung auf eine Schnittstelle, MVC/MVP-Muster usw., die wiederum viel Wissen erfordern, und ... Sie müssen noch mehr Code schreiben.

Also sei vorsichtig ... wenn du kein begeistertes Team und mindestens einen erfahrenen Entwickler hast, der gute Tests schreiben kann und auch ein paar Dinge über gute Architektur weiß, musst du wirklich zweimal überlegen, bevor du die TDD-Straße betrittst .

186

Wenn Sie an den Punkt kommen, an dem Sie eine große Anzahl von Tests haben, müssen Sie beim Ändern des Systems möglicherweise einige oder alle Tests neu schreiben, je nachdem, welche durch die Änderungen ungültig geworden sind. Dies könnte aus einer relativ schnellen Änderung eine sehr zeitaufwendige machen.

Außerdem könnten Sie anfangen, Entwurfsentscheidungen eher auf der Grundlage von TDD als auf der Grundlage von tatsächlich guten Entwurfsprinzipien zu treffen. Während Sie vielleicht eine sehr einfache und unkomplizierte Lösung hatten, mit der sich die Anforderungen von TDD nicht testen lassen, verfügen Sie jetzt über ein viel komplexeres System, das tatsächlich anfälliger für Fehler ist.

66
Eric Z Beard

Ich denke, das größte Problem für mich ist der RIESIGE Zeitverlust, den ich brauche, um "hineinzukommen". Ich bin immer noch sehr am Anfang meiner Reise mit TDD (siehe mein Blog für Updates meiner Testabenteuer, wenn Sie interessiert sind) und ich habe buchstäblich Stunden verbracht loslegen.

Es dauert lange, bis Ihr Gehirn in den "Testmodus" wechselt, und das Schreiben von "testbarem Code" ist eine Fähigkeit für sich.

TBH, ich bin respektvoll anderer Meinung als Jason Cohens Kommentare über die Veröffentlichung privater Methoden, darum geht es nicht. Ich habe in meiner neuen Arbeitsweise nicht mehr öffentliche Methoden gemacht als vorher . Es sind jedoch Änderungen an der Architektur erforderlich, sodass Sie Codemodule "hot plug" können, um das Testen aller anderen Komponenten zu vereinfachen. Sie sollten nicht die Interna Ihres Codes zugänglicher machen, um dies zu tun. Ansonsten sind wir wieder auf dem ersten Platz, da alles öffentlich ist. Wo ist die Kapselung darin?

Also, (IMO) auf den Punkt gebracht:

  • Die Zeit, die zum Nachdenken benötigt wird (d. H. Tatsächlich, um nachzudenken Testen).
  • Die neuen Kenntnisse, die erforderlich sind, um testbaren Code schreiben zu können.
  • Verständnis der Architekturänderungen, die erforderlich sind, um Code testbar zu machen.
  • Erhöhen Sie Ihre Fähigkeiten in "TDD-Coder", während Sie versuchen, alle anderen Fähigkeiten zu verbessern, die für unser ruhmreiches Programmierhandwerk erforderlich sind :)
  • Organisieren Sie Ihre Codebasis so, dass sie Testcode enthält, ohne Ihren Produktionscode zu verschrauben.

PS: Wenn Sie Links zu Positiven haben möchten, habe ich einige Fragen dazu gestellt und beantwortet, lesen Sie mein Profil .

54
Rob Cooper

In den wenigen Jahren, in denen ich Test Driven Development praktiziert habe, muss ich sagen, dass die größten Nachteile folgende sind:

Verkauf an das Management

TDD wird am besten paarweise durchgeführt. Zum einen ist es schwierig, dem Drang zu widerstehen, nur die Implementierung zu schreiben, wenn Sie [~ # ~] wissen, [~ # ~] wie man ein if/else schreibt Aussage. Aber ein Paar wird Sie auf dem Laufenden halten, weil Sie ihn auf dem Laufenden halten. Leider glauben viele Unternehmen/Manager nicht, dass dies eine gute Ressourcennutzung ist. Warum für zwei Personen bezahlen, um eine Funktion zu schreiben, wenn zwei Funktionen gleichzeitig ausgeführt werden müssen?

Verkauf an andere Entwickler

Einige Leute haben einfach nicht die Geduld, Unit-Tests zu schreiben. Einige sind sehr stolz auf ihre Arbeit. Oder manche mögen es, wenn verschlungene Methoden/Funktionen am Ende des Bildschirms ausgeblutet werden. TDD ist nicht jedermanns Sache, aber ich wünschte wirklich, es wäre so. Dies würde es den armen Seelen, die Code erben, sehr viel leichter machen, Dinge zu pflegen.

Pflegen Sie den Testcode zusammen mit Ihrem Produktionscode

Im Idealfall brechen Ihre Tests nur dann ab, wenn Sie eine falsche Codeentscheidung treffen. Das heißt, Sie dachten, das System hat in eine Richtung funktioniert, und es stellte sich heraus, dass dies nicht der Fall war. Wenn Sie einen Test oder eine (kleine) Reihe von Tests abbrechen, sind dies tatsächlich gute Nachrichten. Sie wissen genau, wie sich Ihr neuer Code auf das System auswirkt. Wenn Ihre Tests jedoch schlecht geschrieben, eng miteinander verbunden oder, noch schlimmer, erzeugt sind ( Husten VS-Test), kann die Aufrechterhaltung Ihrer Tests schnell zu einem Chor werden. Und wenn genügend Tests anfangen, mehr Arbeit zu verursachen als der wahrgenommene Wert, den sie erzeugen, werden die Tests als erstes gelöscht, wenn die Zeitpläne komprimiert werden (z. B. wenn die Zeit knapp wird).

Schreiben von Tests, damit Sie alles abdecken (100% Codeabdeckung)

Wenn Sie sich an die Methodik halten, wird Ihr Code im Idealfall standardmäßig zu 100% getestet. Typischerweise, dachte ich, lande ich mit einer Codeabdeckung von über 90%. Dies geschieht normalerweise, wenn ich eine Architektur im Vorlagenstil habe und die Basis getestet wurde und ich versuche, Ecken abzuschneiden und die Vorlagenanpassungen nicht zu testen. Außerdem habe ich festgestellt, dass ich beim Testen einer neuen Barriere, auf die ich zuvor noch nicht gestoßen war, eine Lernkurve habe. Ich gebe zu, einige Codezeilen auf die alte Art und Weise zu schreiben, aber ich mag es wirklich, dass 100%. (Ich denke, ich war ein Überflieger in der Schule, ähm Schule).

Damit würde ich jedoch sagen, dass die Vorteile von TDD die negativen bei weitem überwiegen, wenn Sie eine gute Reihe von Tests erzielen, die Ihre Anwendung abdecken, aber nicht so zerbrechlich sind, dass eine Änderung sie alle kaputt macht Sie werden in der Lage sein, an Tag 300 Ihres Projekts wie an Tag 1 neue Funktionen hinzuzufügen. Dies trifft nicht auf alle zu, die TDD als Wundermittel für all ihren fehlerhaften Code betrachten nicht funktionieren, Punkt.

Persönlich habe ich festgestellt, dass ich mit TDD einfacheren Code schreibe, weniger Zeit damit verbringe, zu debattieren, ob eine bestimmte Codelösung funktioniert oder nicht, und dass ich keine Angst habe, Codezeilen zu ändern, die die von festgelegten Kriterien nicht erfüllen Das Team.

TDD ist eine schwierige Disziplin, die es zu meistern gilt. Ich bin schon seit einigen Jahren dabei und lerne immer wieder neue Testtechniken. Es ist eine enorme Zeitinvestition im Vorfeld, aber auf lange Sicht ist Ihre Nachhaltigkeit viel höher als ohne automatisierte Komponententests. Nun, wenn nur meine Chefs das herausfinden könnten.

49
casademora

Bei Ihrem ersten TDD-Projekt gibt es zwei große Verluste: Zeit und persönliche Freiheit

Sie verlieren Zeit, weil:

  • Die Erstellung einer umfassenden, überarbeiteten und wartbaren Suite von Einheiten- und Abnahmetests verlängert die erste Iteration des Projekts erheblich. Dies kann auf lange Sicht Zeit sparen, aber es kann auch Zeit sein, die Sie nicht sparen müssen.
  • Sie müssen sich für einen Kernsatz von Tools entscheiden und sich darin auskennen. Ein Unit-Test-Tool muss durch eine Art Spott-Framework ergänzt werden und beide müssen Teil Ihres automatisierten Build-Systems werden. Sie möchten auch geeignete Metriken auswählen und generieren.

Sie verlieren persönliche Freiheit, weil:

  • TDD ist eine sehr disziplinierte Art, Code zu schreiben, die dazu neigt, die obersten und untersten Bereiche der Skalierbarkeit zu treffen. Wenn Sie den Produktionscode immer auf eine bestimmte Art und Weise schreiben und Ihre Arbeit einer ständigen Überprüfung durch Fachkollegen unterziehen, kann dies Ihre schlechtesten und besten Entwickler ausflippen und sogar zum Verlust der Mitarbeiterzahl führen.
  • Die meisten agilen Methoden, in die TDD eingebettet ist, erfordern, dass Sie ständig mit dem Kunden darüber sprechen, was Sie erreichen möchten (in dieser Geschichte/diesem Tag/was auch immer) und was die Kompromisse sind. Auch dies ist nicht jedermanns Sache, sowohl auf der Entwicklerseite als auch auf der Kundenseite.

Hoffe das hilft

24
Garth Gilmour

Bei TDD müssen Sie die Funktionsweise Ihrer Klassen planen, bevor Sie Code schreiben, um diese Tests zu bestehen. Dies ist sowohl ein Plus als auch ein Minus.

Ich finde es schwierig, Tests im "luftleeren Raum" zu schreiben, bevor ein Code geschrieben wurde. Nach meiner Erfahrung neige ich dazu, über meine Tests zu stolpern, wenn ich beim Schreiben meiner Klassen unvermeidlich an etwas denke, das ich beim Schreiben meiner ersten Tests vergessen habe. Dann ist es an der Zeit, nicht nur meine Klassen, sondern auch meine Tests zu überarbeiten. Wiederholen Sie dies drei oder vier Mal und es kann frustrierend werden.

Ich bevorzuge es, zuerst einen Entwurf meiner Klassen zu schreiben und dann eine Reihe von Komponententests zu schreiben (und zu warten). Nach einem Entwurf funktioniert TDD für mich einwandfrei. Wenn zum Beispiel ein Fehler gemeldet wird, schreibe ich einen Test, um diesen Fehler auszunutzen, und korrigiere dann den Code, damit der Test bestanden wird.

14
Chrass

Mit TDD kann das Erstellen von Prototypen sehr schwierig sein. Wenn Sie nicht sicher sind, welchen Weg Sie zu einer Lösung einschlagen möchten, kann es schwierig sein, die Tests im Voraus zu schreiben (abgesehen von sehr umfangreichen Tests). Dies kann ein Schmerz sein.

Ehrlich gesagt glaube ich nicht, dass es für die "Kernentwicklung" der allermeisten Projekte einen wirklichen Nachteil gibt. Es wird viel mehr ausgesprochen, als es sein sollte, normalerweise von Leuten, die glauben, dass ihr Code gut genug ist, dass sie keine Tests brauchen (das ist es nie), und von Leuten, die einfach nicht die Mühe haben, sie zu schreiben.

12
Calum

Nun, und dieses Strecken müssen Sie Ihre Tests debuggen. Das Verfassen der Tests ist mit einem gewissen Zeitaufwand verbunden, obwohl die meisten Befragten der Ansicht sind, dass sich diese Investition über die gesamte Lebensdauer der Anwendung sowohl für das zeitsparende Debugging als auch für die Stabilität auszahlt.

Das größte Problem, das ich persönlich damit hatte, ist jedoch, die Disziplin aufzubauen, um die Tests tatsächlich zu schreiben. In einem Team, insbesondere einem etablierten Team, kann es schwierig sein, sie davon zu überzeugen, dass sich die aufgewendete Zeit lohnt.

9
Tim Sullivan

Der Nachteil von TDD ist, dass es in der Regel eng mit der „agilen“ Methodik verknüpft ist, die der Dokumentation eines Systems nein Bedeutung beimisst, und eher dem Verständnis, warum ein Test einen bestimmten Wert zurückgeben sollte, anstatt Alle anderen befinden sich nur im Kopf des Entwicklers.

Sobald der Entwickler den Grund dafür verlässt oder vergisst, dass der Test einen bestimmten Wert und keinen anderen zurückgibt, sind Sie fertig. TDD ist in Ordnung, wenn es angemessen dokumentiert und von einer für Menschen lesbaren (dh spitzen Manager) Dokumentation umgeben ist, auf die in 5 Jahren Bezug genommen werden kann, wenn sich die Welt ändert und Ihre App dies auch muss.

Wenn ich von Dokumentation spreche, handelt es sich nicht um eine Code-Unschärfe, sondern um eine offizielle Schrift, die außerhalb der Anwendung vorhanden ist, z Ihr Code im Jahr 2011.

7
Ron McMahon

Wenn Ihre Tests nicht sehr gründlich sind, könnten Sie in den falschen Sinn "alles funktioniert" geraten, nur weil Sie die Tests bestanden haben. Theoretisch funktioniert der Code, wenn Ihre Tests bestanden wurden. Aber wenn wir beim ersten Mal Code perfekt schreiben könnten, bräuchten wir keine Tests. Die Moral hier ist es, sicherzustellen, dass Sie selbst einen Gesundheitscheck durchführen, bevor Sie etwas Vollständiges aufrufen, und sich nicht nur auf die Tests verlassen.

In diesem Sinne sollten Sie einen Test schreiben, wenn Ihre Gesundheitsprüfung etwas findet, das nicht getestet wurde.

7
Aaron Lee

Ich habe verschiedene Situationen erlebt, in denen TDD mich verrückt macht. Um einige zu nennen:

  • Wartbarkeit des Testfalls:

    Wenn Sie in einem großen Unternehmen arbeiten, müssen Sie die Testfälle wahrscheinlich nicht selbst schreiben, oder zumindest die meisten werden von einer anderen Person geschrieben, wenn Sie in das Unternehmen eintreten. Die Funktionen einer Anwendung ändern sich von Zeit zu Zeit. Wenn Sie über kein System wie HP Quality Center verfügen, um sie zu verfolgen, werden Sie in kürzester Zeit verrückt.

    Dies bedeutet auch, dass neue Teammitglieder eine Menge Zeit benötigen, um zu erfahren, was mit den Testfällen los ist. Dies kann wiederum in mehr Geld umgewandelt werden.

  • Komplexität der Testautomatisierung:

    Wenn Sie einige oder alle Testfälle in maschinenlauffähige Testskripten automatisieren, müssen Sie sicherstellen, dass diese Testskripten mit den entsprechenden manuellen Testfällen synchronisiert sind und den Änderungen der Anwendung entsprechen.

    Außerdem nehmen Sie sich Zeit, um die Codes zu debuggen, mit denen Sie Fehler erkennen können. Meiner Meinung nach sind die meisten dieser Fehler darauf zurückzuführen, dass das Testteam die Anwendungsänderungen im Automatisierungstestskript nicht berücksichtigt hat. Änderungen an der Geschäftslogik, der Benutzeroberfläche und anderen internen Elementen können dazu führen, dass Ihre Skripts nicht mehr oder nicht mehr zuverlässig ausgeführt werden. Manchmal sind die Änderungen sehr subtil und schwer zu erkennen. Einmal meldeten alle meine Skripte einen Fehler, weil sie ihre Berechnung auf Informationen aus Tabelle 1 basierten, während Tabelle 1 jetzt Tabelle 2 war (weil jemand den Namen der Tabellenobjekte im Anwendungscode vertauschte).

6
Martin08

Das größte Problem sind die Leute, die nicht wissen, wie man richtige Unit-Tests schreibt. Sie schreiben Tests, die voneinander abhängen (und sie funktionieren hervorragend, wenn sie mit Ant ausgeführt werden, aber plötzlich scheitern sie, wenn ich sie mit Eclipse ausführe, nur weil sie in einer anderen Reihenfolge ausgeführt werden). Sie schreiben Tests, die nichts Bestimmtes testen - sie debuggen nur den Code, überprüfen das Ergebnis und ändern es in test und nennen es "test1". Sie erweitern den Umfang von Klassen und Methoden, nur weil es einfacher sein wird, Komponententests für sie zu schreiben. Der Code von Unit-Tests ist schrecklich, mit all den klassischen Programmierproblemen (schwere Kopplung, Methoden, die 500 Zeilen lang sind, hartcodierte Werte, Code-Duplizierung) und es ist eine Hölle zu pflegen. Aus irgendeinem seltsamen Grund behandeln Leute Unit-Tests als etwas, das dem "echten" Code unterlegen ist, und sie kümmern sich überhaupt nicht um ihre Qualität. :-(

5
rmaruszewski

Sie verlieren viel Zeit damit, Tests zu schreiben. Natürlich könnte dies bis zum Ende des Projekts gespeichert werden, indem Fehler schneller erkannt werden.

4
Joel Coehoorn

Sie verlieren die Fähigkeit zu sagen, dass Sie "fertig" sind, bevor Sie Ihren gesamten Code testen.

Sie verlieren die Fähigkeit, Hunderte oder Tausende von Codezeilen zu schreiben, bevor Sie ihn ausführen.

Sie verlieren die Gelegenheit, durch Debuggen zu lernen.

Sie verlieren die Flexibilität, Code zu versenden, dessen Sie sich nicht sicher sind.

Sie verlieren die Freiheit, Ihre Module fest zu koppeln.

Sie verlieren die Möglichkeit, das Schreiben von Konstruktionsunterlagen auf niedriger Ebene zu überspringen.

Sie verlieren die Stabilität, die mit Code einhergeht, für den sich jeder fürchtet, geändert zu werden.

Sie verlieren den Titel "Hacker".

4
Uncle Bob

Der größte Nachteil ist, dass Sie viel scheitern müssen, bevor Sie erfolgreich sind, wenn Sie TDD wirklich richtig durchführen möchten. Wenn man bedenkt, wie viele Softwareunternehmen arbeiten (Dollar pro KLOC), wird man irgendwann entlassen. Auch wenn Ihr Code schneller, sauberer, einfacher zu warten und weniger Fehler aufweist.

Wenn Sie in einem Unternehmen arbeiten, das Sie von den KLOCs bezahlt (oder implementierte Anforderungen - auch wenn diese nicht getestet wurden), meiden Sie TDD (oder Codeüberprüfungen, Paarprogrammierung oder kontinuierliche Integration usw. usw. usw.).

3
Vasco Duarte

Sich auf schwierige, unvorhergesehene Anforderungen zu konzentrieren, ist der ständige Fluch des Programmierers. Testgetriebene Entwicklung zwingt Sie dazu, sich auf die bereits bekannten, alltäglichen Anforderungen zu konzentrieren und Ihre Entwicklung auf das zu beschränken, was Sie sich bereits vorgestellt haben.

Denken Sie darüber nach, es ist wahrscheinlich, dass Sie bestimmte Testfälle entwerfen, sodass Sie nicht kreativ werden und denken, dass es cool wäre, wenn der Benutzer X, Y und Z ausführen könnte. Wenn sich dieser Benutzer über die potenziellen Kühlungsanforderungen X, Y und Z aufregt, konzentriert sich Ihr Design möglicherweise zu stark auf bereits festgelegte Testfälle, und es ist schwierig, sie anzupassen.

Dies ist natürlich ein zweischneidiges Schwert. Wenn Sie Ihre ganze Zeit damit verbringen, für jedes erdenkliche, vorstellbare X, Y und Z zu entwerfen, das sich ein Benutzer jemals wünschen könnte, werden Sie unweigerlich nie etwas fertigstellen. Wenn Sie etwas vervollständigen, kann niemand (auch Sie nicht) eine Vorstellung davon haben, was Sie in Ihrem Code/Design tun.

2
Doug T.

Ich stimme der Antwort über die anfängliche Entwicklungszeit zu. Sie verlieren auch die Fähigkeit, ohne die Sicherheit von Tests bequem zu arbeiten. Ich wurde auch als TDD Nutbar bezeichnet, sodass du ein paar Freunde verlieren könntest;)

2
Chris Canal

Es wird als langsamer empfunden. Langfristig gesehen ist das nicht der Fall, denn es wird Sie auf dem Weg retten, aber Sie werden am Ende mehr Code schreiben, so dass Sie wahrscheinlich Zeit damit verbringen, "zu testen, nicht zu codieren". Es ist ein fehlerhaftes Argument, aber Sie haben gefragt!

2
MarcE

Es kann schwierig und zeitaufwendig sein, Tests für "zufällige" Daten wie XML-Feeds und Datenbanken zu schreiben (nicht so schwierig). Ich habe in letzter Zeit einige Zeit mit Wetterdaten-Feeds verbracht. Es ist ziemlich verwirrend, Tests dafür zu schreiben, zumindest da ich nicht zu viel Erfahrung mit TDD habe.

1
Vargen

Es braucht einige Zeit, um sich damit zu beschäftigen, und einige Zeit, um es in einem Projekt zu beginnen, aber ... Ich bedaure es immer, keinen Test-Driven-Ansatz gewählt zu haben, wenn ich dumme Fehler finde, die ein automatisierter Test sehr schnell hätte finden können. Darüber hinaus verbessert TDD die Codequalität.

1
aerlijman

Gute Antworten an alle. Ich würde ein paar Möglichkeiten hinzufügen, um die dunkle Seite von TDD zu vermeiden:

  • Ich habe Apps geschrieben, um ihren eigenen randomisierten Selbsttest durchzuführen. Das Problem beim Schreiben spezifischer Tests ist, dass sie nur die Fälle abdecken, an die Sie denken, auch wenn Sie viele schreiben. Zufallsgeneratoren finden Probleme, an die Sie nicht gedacht haben.

  • Das gesamte Konzept vieler Komponententests impliziert, dass Komponenten, wie komplexe Datenstrukturen, in ungültige Zustände geraten können. Wenn Sie sich von komplexen Datenstrukturen fernhalten, gibt es viel weniger zu testen.

  • Wenn es Ihre Anwendung zulässt, sollten Sie sich vor einem Design scheuen, das auf die richtige Reihenfolge von Benachrichtigungen, Ereignissen und Nebenwirkungen angewiesen ist. Diese können leicht fallen gelassen oder verschlüsselt werden, so dass sie eine Menge Tests benötigen.

1
Mike Dunlavey
  • komponententest sind mehr Code zu schreiben, daher höhere Vorab-Entwicklungskosten
  • es ist mehr Code zu pflegen
  • zusätzliches Lernen erforderlich
1
Bob Dizzle

Sie verlieren große Klassen mit mehreren Verantwortlichkeiten. Sie werden wahrscheinlich auch große Methoden mit mehreren Verantwortlichkeiten verlieren. Möglicherweise verlieren Sie die Fähigkeit zur Umgestaltung, aber Sie verlieren auch einen Teil der Notwendigkeit zur Umgestaltung.

Jason Cohen sagte so etwas wie: TDD erfordert eine bestimmte Organisation für Ihren Code. Dies könnte architektonisch falsch sein; Da private Methoden beispielsweise nicht außerhalb einer Klasse aufgerufen werden können, müssen Sie Methoden nicht privat machen, um sie testbar zu machen.

Ich sage, dies deutet auf eine fehlende Abstraktion hin - wenn der private Code wirklich getestet werden muss, sollte er wahrscheinlich in einer separaten Klasse sein.

Dave Mann

1
Dave Mann

Sie müssen Anwendungen auf eine andere Art schreiben: eine, die sie testbar macht. Sie wären überrascht, wie schwierig dies zunächst ist.

Einige Leute finden das Konzept, darüber nachzudenken, was sie schreiben werden, bevor sie es zu schwer schreiben. Konzepte wie das Verspotten können für manche auch schwierig sein. TDD in älteren Apps kann sehr schwierig sein, wenn sie nicht zum Testen entwickelt wurden. TDD um Frameworks, die nicht TDD-freundlich sind, kann auch ein Kampf sein.

TDD ist eine Fähigkeit, mit der sich Junior-Entwickler zunächst schwer tun können (hauptsächlich, weil ihnen diese Arbeitsweise nicht beigebracht wurde).

Insgesamt werden die Nachteile jedoch gelöst, wenn die Leute geschickter werden und Sie am Ende den "stinkenden" Code abstrahieren und ein stabileres System haben.

1

Die Person, die mein Team in agiler Entwicklung unterrichtet hat, glaubte nicht an Planung, Sie haben nur so viel für die kleinste Anforderung geschrieben.

Sein Motto war Refaktor, Refaktor, Refaktor. Mir wurde klar, dass Refactor „nicht vorausplanen“ bedeutete.

0
Jack B Nimble

Lassen Sie mich hinzufügen, dass Sie, wenn Sie BDD-Prinzipien auf ein TDD-Projekt anwenden, einige der hier aufgeführten Hauptnachteile (Verwirrung, Missverständnisse usw.) beseitigen können. Wenn Sie mit BDD nicht vertraut sind, sollten Sie die Einführung von Dan North lesen. Er entwickelte das Konzept als Antwort auf einige Probleme, die sich aus der Anwendung von TDD am Arbeitsplatz ergaben. Dans Intro zu BDD ist zu finden hier .

Ich mache diesen Vorschlag nur, weil BDD einige dieser Negative anspricht und als Lückenstop fungiert. Sie sollten dies berücksichtigen, wenn Sie Ihr Feedback einholen.

0
Kilhoffer

TDD erfordert eine bestimmte Organisation für Ihren Code. Dies ist möglicherweise ineffizient oder schwer lesbar. Oder auch architektonisch falsch; Da private -Methoden beispielsweise nicht außerhalb einer Klasse aufgerufen werden können, müssen Sie Methoden als nicht privat definieren, um sie testbar zu machen, was einfach falsch ist.

Wenn sich der Code ändert, müssen Sie auch die Tests ändern. Beim Refactoring kann dies eine Menge zusätzlicher Arbeit bedeuten.

0
Jason Cohen

Sie müssen sicherstellen, dass Ihre Tests immer auf dem neuesten Stand sind. Sobald Sie anfangen, rote Ampeln zu ignorieren, werden die Tests bedeutungslos.

Sie müssen auch sicherstellen, dass die Tests umfassend sind, oder wenn ein großer Fehler auftritt, wird sich der verstopfte Verwaltungstyp beschweren, von dem Sie endgültig überzeugt sind, dass Sie Zeit damit verbringen, mehr Code zu schreiben.

0
qui