Nachteile von Test Driven Development? [geschlossen]

https://stackoverflow.com/questions/64333

09-06-2019
|

Frage

Was verliere ich von Test Driven Design Annahme?

Liste nur Negativ; Liste nicht Vorteile in einer negativen Form geschrieben.

Lösung

Mehrere Nachteile (und ich behaupte nicht, es gibt keine Vorteile - vor allem, wenn die Gründung eines Projekts zu schreiben - es würde viel Zeit am Ende speichern):

Big Zeit Investitionen. Für den einfachen Fall, dass Sie etwa 20% der tatsächlichen Umsetzung zu verlieren, aber für komplizierte Fälle, die Sie verlieren viel mehr.
Zusätzliche Komplexität. Für komplexe Fälle Ihrer Testfälle schwerer zu berechnen, die ich in solchen Fällen, dass würde vorschlagen, um zu versuchen und die automatischen Referenzcode zu verwenden, die parallel in dem Debug-Version / Test laufen laufen, anstelle des Unit-Test von einfachsten Fälle.
Konstruktions Impacts Manchmal ist das Design zu Beginn nicht klar und entwickelt sich, wie Sie gehen - das wird Sie zwingen, Ihren Test zu wiederholen, die eine große Zeit verlieren erzeugen. Ich würde vorschlagen, in diesem Fall Unit-Tests zu verschieben, bis Sie etwas Verständnis für das Design im Sinne haben.
Kontinuierliche Tweaking. Für Datenstrukturen und Black-Box-Algorithmen Unit-Tests wäre perfekt, aber für Algorithmen, die geändert werden neigen, gezwickt oder fein abgestimmt, kann dies einen großen Zeitaufwand verursachen, man könne Anspruch ist nicht gerechtfertigt. So ist es verwenden, wenn Sie denken, dass es tatsächlich das System passt und nicht mit Gewalt, das Design zu TDD passen.

Andere Tipps

Wenn Sie „echten“ TDD (sprich: Test zuerst mit den roten, grünen, Refactoring-Schritten) tun wollen. Dann muss man auch Mocks / Stubs beginnen, wenn Sie Integrationspunkte testen mögen

Wenn Sie Mocks beginnen, nach einer Weile, werden Sie mit Dependency Injection (DI) und eine Inversion of Control (IoC) Behälter zu starten. Dazu müssen Sie Schnittstellen für alles verwenden müssen (was viele Tücken haben selbst).

Am Ende des Tages haben Sie viel mehr Code zu schreiben, als wenn man es nur die „gute alte Art und Weise“. Statt nur eine Kundenklasse, müssen Sie auch eine Schnittstelle, eine Mock-Klasse, einige IoC Konfiguration und ein paar Tests.

schreiben

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

Viele Entwickler nicht ganz verstehen, wie all diese „den richtigen Weg“ zu tun. Aber weil jeder sagt ihnen, dass TDD der einzig wahre Weg ist, Software zu entwickeln, versuchen sie einfach gut sie können.

Es ist viel schwieriger, als man denken könnte. Oft Projekte mit TDD getan mit viel Code am Ende, dass niemand wirklich versteht. Die Unit-Tests testen oft die falsche Sache, in die falsche Richtung. Und niemand stimmt, wie ein guter Test, wie, nicht einmal die so genannten Gurus aussehen sollte.

All diese Tests machen es viel schwieriger zu „change“ (gegenüber Refactoring) das Verhalten Ihres Systems und einfacher Änderungen wird einfach zu schwer und zeitaufwendig.

Wenn Sie die TDD-Literatur zu lesen, gibt es immer einige sehr gute Beispiele, aber oft im wirklichen Leben Anwendungen, müssen Sie eine Benutzeroberfläche und eine Datenbank haben. Dies ist, wo TDD wirklich hart wird, und die meisten Quellen bieten keine guten Antworten. Und wenn sie es tun, es geht immer mehr Abstraktionen. Mock-Objekte, die Programmierung einer Schnittstelle, MVC / MVP-Muster usw., die wiederum eine Menge Wissen erfordern, und ... Sie haben zu schreiben, noch mehr Code

Seien Sie also vorsichtig ... wenn Sie nicht über ein engagiertes Team haben und mindestens einen erfahrenen Entwickler, der weiß, wie gut Tests zu schreiben und weiß auch, ein paar Dinge über gute Architektur, müssen Sie wirklich denken zweimal, bevor sie nach unten gehen die TDD-Straße.

Wenn Sie an dem Punkt, wo Sie eine große Anzahl von Tests haben, das System zu ändern könnten einige oder alle Ihre Tests erfordern Umschreiben, je nachdem, welche diejenigen, die durch die Änderungen für ungültig erklärt wurde. Dies könnte eine relativ schnelle Änderung in ein sehr zeitaufwendig eine Umdrehung.

Auch könnten Sie beginnen Design Entscheidungen mehr auf TDD basiert als auf tatsächlich gutes Design prinicipals. Während Sie eine sehr einfache, einfache Lösung gehabt haben können, die die Art und Weise TDD Anforderungen zu testen unmöglich ist, haben Sie jetzt eine viel komplexere System, das tatsächlich anfälliger für Fehler ist.

Ich denke, das größte Problem für mich den riesigen Verlust von Zeit ist es „immer in ihn“ nimmt. Ich bin immer noch sehr am Anfang meiner Reise mit TDD (meinem Blog für Updates Abenteuer meiner Tests Sehen Sie, wenn Sie interessiert) und ich habe buchstäblich Stunden ausgegeben am Anfang.

Es dauert eine lange Zeit, um Ihr Gehirn in „Testmodus“ zu bekommen und „überprüfbaren Code“ zu schreiben ist eine Fähigkeit, in mir selbst.

TBH, ich mit Jason Cohens Kommentare respektvoll widersprechen auf private Methoden öffentlich zu machen, das ist nicht, worum es geht. Ich habe in meinem neuen Weg nicht mehr öffentliche Methoden, die vor der Arbeit als . Sie räumt jedoch Änderungen an der Architektur einzubeziehen und damit für Sie „hot plug“ Code-Module alles andere leichter zu testen, machen. Sie sollten nicht sein machen die Einbauten des Codes zugänglich, dies zu tun. Ansonsten sind wir wieder Platz eins mit allem, was sein Publikum, wo ist die Verkapselung in das?

So (IMO) auf den Punkt:

Die Zeit, zu denken genommen (das heißt eigentlich grok'ing Test ).
Die neuen Kenntnisse erforderlich zu wissen, wie prüfbaren Code zu schreiben.
die architektonischen Änderungen Verständnis erforderlich, um Code testbar zu machen.
Erhöhen Sie Ihre Fähigkeiten von „TDD-Coder“ bei dem Versuch, alle anderen Fähigkeiten für unsere glorreiche Programmierhandwerk erforderlich zu verbessern:)
Ihre Code-Basis organisiert Testcode umfasst ohne Ihren Produktionscode schrauben.

PS: Wenn Sie Links zu Positiven möchte, habe ich gefragt und antwortete auf es mehrere Fragen, überprüfen Sie mein Profil out .

In den wenigen Jahren, die ich Test Driven Development praktiziert, würde ich die größten Nachteile zu sagen haben, sind:

Verkauf an Management

TDD ist am besten paarweise erfolgen. Zum einen ist es schwierig, den Drang zu widerstehen, nur die Umsetzung zu schreiben, wenn Sie auf KNOW , wie eine if / else Erklärung zu schreiben. Aber ein Paar werden Sie auf Aufgabe halten, weil Sie ihn auf Aufgabe halten. Leider denken viele Unternehmen / Manager nicht, dass dies eine gute Nutzung der Ressourcen. Warum für zwei Personen zahlen eine Funktion zu schreiben, wenn ich zwei Funktionen, die zur gleichen Zeit durchgeführt werden müssen?

es an andere Entwickler zu verkaufen

Einige Leute haben einfach nicht die Geduld, Unit-Tests für das Schreiben. Einige sind sehr stolz auf ihre Arbeit. Oder einige wie sieht gewundene Methoden / Funktionen bluten das Ende des Bildschirms aus. TDD ist nicht jedermanns Sache, aber ich wirklich wünschte, es wäre. Es wäre Sachen Aufrechterhaltung so viel einfacher für die armen Seelen machen, den Code erbt.

Pflege des Testcode zusammen mit Ihrem Produktionscode

Im Idealfall Ihre Tests nur brechen, wenn Sie einen schlechten Code Entscheidung zu treffen. Das heißt, Sie dachten, das System eine Art und Weise gearbeitet, und es stellt sich heraus, es kommt nicht. Durch einen Test zu brechen, oder eine (kleine) Gruppe von Tests, das ist eigentlich eine gute Nachricht. Sie wissen, genau , wie Sie Ihren neuen Code wird das System beeinflussen. Jedoch schlecht, wenn Ihre Tests geschrieben werden, eng gekoppelt oder, schlimmer noch, erzeugt ( Husten VS Test), dann können Sie Ihre Tests beibehalten wird schnell ein Chor geworden. Und nach genug Tests, mehr Arbeit zu verursachen beginnen, dass die empfundene Wert, den sie schaffen, dann werden die Tests das erste, was gelöscht werden, wenn Zeitpläne zusammengedrückt werden (z. B. wird es Zeit crunch)

Schreibtests, so dass Sie alles abdecken (100% Code Coverage)

Im Idealfall wieder, wenn Sie an die Methodik einhalten, wird Ihr Code 100% standardmäßig getestet werden. Typischerweise dachte, ich mit Code-Abdeckung nach oben von 90% am Ende. Dies geschieht in der Regel, wenn ich einige Template-Architektur haben, und die Basis ist getestet, und ich versuche, Ecken zu schneiden und nicht die Template-Anpassungen zu testen. Ich habe auch festgestellt, dass wenn ich eine neue Barriere stoßen hatte ich vorher nicht begegnet, ich beim Testen es eine Lernkurve haben. Ich werde die alte Skool Art und Weise zu schreiben, einige Zeilen Code zugeben, aber ich wirklich, dass 100% haben möge. (Ich glaube, ich war ein über Flieger in der Schule, er skool).

Sie jedoch, dass mit Ich würde sagen, dass die Vorteile von TDD weit die Negative für die einfache Idee überwiegen, dass, wenn Sie einen guten Satz von Tests erreichen können, die Ihre Anwendung abdecken, sind aber nicht so zerbrechlich, dass eine Veränderung bricht sie alle werden Sie in der Lage sein, neue Funktionen am Tag 300 des Projekts, um das Hinzufügen, wie Sie am Tag tat 1. Dies geschieht nicht mit allen, die TDD versuchen denken, es Allheilmittel ist, um alle ihre verwanzten Code, und so sie denke, es kann nicht funktionieren, period.

Persönlich habe ich festgestellt, dass mit TDD, ich einfacher Code zu schreiben, verbringe ich weniger Zeit diskutiert, ob eine bestimmte Code-Lösung funktioniert oder nicht, und dass ich keine Angst zu haben jede Zeile Code zu ändern, die die Kriterien nicht erfüllen her durch das Team.

TDD ist eine schwierige Disziplin zu meistern, und ich habe seit ein paar Jahren an ihm gewesen, und ich immer noch neue Prüftechniken die ganze Zeit lernen. Es ist ein sehr großer Zeitaufwand vorne, aber auf lange Sicht, Ihre Nachhaltigkeit als viel größer sein wird, wenn Sie keine automatische Unit-Tests hatte. Nun, wenn nur meine Chefs dieses herausfinden könnte.

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

Sie verlieren Zeit, weil:

eine umfassende, Refactoring, wartbar Suite von Einheit und Akzeptanztests Erstellen fügt große Zeit die ersten Iteration des Projektes. Dies kann auf lange Sicht Zeit gespeichert sein, aber ebenso kann es sein, wenn Sie nicht scheuen müssen.
Sie müssen wählen und Experte in einem Kernsatz von Werkzeugen worden. Ein Unit-Test-Tool muss durch eine Art ergänzt werden Rahmen spöttisch und beide müssen Teil Ihrer automatisierten Build-System werden. Sie wollen auch geeignete Metriken auszuwählen und zu erzeugen.

Sie verlieren die persönliche Freiheit, weil:

TDD ist eine sehr disziplinierte Art und Weise des Schreibens Code, der gegen die am oberen und unteren Ende der Skala Fähigkeiten zu reiben roh tendiert. Immer Produktionscode in einer bestimmten Art und Weise zu schreiben und Ihre Arbeit zum kontinuierlichen Peer-Review unterzogen kann Ihre schlimmsten und beste Entwickler ausflippen und sogar zum Verlust der Mitarbeiterzahl führen.
Die Agile Methoden, die TDD einbetten erfordern, dass Sie an den Kunden ständig darüber reden, was Sie vorschlagen (in dieser Geschichte / Tag / was auch immer) zu erreichen, und was die Abwägungen sind. Wieder einmal ist dieser Kelch ist nicht jeder von Tee, die beide auf dem Entwickler Seite des Zauns und die Kunden.

Hope, das hilft

TDD erfordert, dass Sie planen, wie Ihre Klassen arbeiten, bevor Sie Code schreiben, diese Tests zu bestehen. Dies ist sowohl ein Plus und ein Minus.

Ich finde es schwer Tests in einem „Vakuum“ zu schreiben --Vor jeder Code geschrieben wurde. Nach meiner Erfahrung neige ich über meine Tests stolpern, wenn ich denke an etwas unvermeidlich, während meine Klassen zu schreiben, die ich vergessen habe, während meine ersten Tests zu schreiben. Dann ist es Zeit, um nicht nur meine Klassen Refactoring, sondern auch meine Tests. Wiederholen Sie diese drei oder vier Mal, und es kann sehr frustrierend sein.

Ich ziehe einen Entwurf meiner Klassen zu schreiben, zuerst, dann schreiben (und halten) eine Batterie von Unit-Tests. Nachdem ich einen Entwurf haben, arbeitet TDD für mich in Ordnung. Zum Beispiel, wenn ein Fehler gemeldet wird, werde ich einen Test schreiben, um diesen Fehler zu ausnutzt, und dann den Code zu beheben, damit der Test bestanden wird.

Prototyping mit TDD sehr schwierig sein - wenn Sie nicht sicher sind, welcher Weg Sie zu einer Lösung nehmen gehen, können die Tests Upfront-Schreiben schwierig sein (außer sehr breit ist). Dies kann ein Schmerz sein.

Ehrlich gesagt glaube ich nicht, dass für „Core-Entwicklung“ für die überwiegende Mehrheit der Projekte gibt es keinen wirklichen Nachteil, obwohl; es spricht viel mehr nach unten als es sein sollte, in der Regel von Menschen, die ihr Code glauben gut genug ist, dass sie Tests nicht brauchen (es nie ist) und Menschen, die schlicht einfach nicht gestört werden, sie zu schreiben.

Nun, und diese Dehnung, müssen Sie Ihre Tests debuggen. Außerdem gibt es eine gewisse Kosten in der Zeit für die Tests zu schreiben, obwohl die meisten Menschen sind sich einig, dass es sich um eine Vorab-Investitionen ist, die sowohl in der Zeit gespeichert Debuggen und Stabilität über die gesamte Lebensdauer der Anwendung auszahlt.

Das größte Problem, das ich habe persönlich mit ihm habe, obwohl, ist die Disziplin immer bis schreiben tatsächlich die Tests. In einem Team, vor allem eines eingespielten Team, kann es schwierig sein, sie zu überzeugen, dass die verbrachte Zeit lohnt.

Wenn Sie Ihre Tests nicht sehr gründlich sind Sie in ein falsches Gefühl fallen könnte von „alles funktioniert“, nur weil Sie Tests bestehen. Theoretisch, wenn Ihre Tests bestehen, wird der Code arbeiten; aber wenn wir Code perfekt zum ersten Mal schreiben könnten würden wir nicht Tests benötigen. Die Moral ist hier, um sicherzustellen, eine Plausibilitätsprüfung auf eigene Faust zu tun, bevor etwas abgeschlossen ist, ruft verlassen sich nicht nur auf die Tests.

In diesem Sinne, wenn Ihre Plausibilitätsprüfung etwas findet, das nicht geprüft wird, stellen Sie sicher, zurück zu gehen und einen Test für sie schreiben.

Der Nachteil TDD ist, dass es in der Regel eng mit ‚Agile‘ Methodik verknüpft ist, das legt Nein Bedeutung für die Dokumentation eines Systems, sondern das Verständnis hinter warum ein Test ‚sollte‘ eine Rückkehr spezifische Wert eher als jede andere wohnt nur im Kopf des Entwicklers.

Sobald der Entwickler verlässt oder vergisst, den Grund, dass der Test einen bestimmten Wert zurückgibt und nicht eine andere, du bist geschraubt. TDD ist in Ordnung, wenn es ausreichend dokumentiert ist und umgeben von Menschen lesbaren (dh. Spitzes haarigen Manager) Dokumentation, die in 5 Jahren bezeichnet werden kann, wenn sich die Welt verändert und Ihre App Bedürfnisse als auch.

Wenn ich die Dokumentation sprechen, dies ist kein Klappentext in Code ist dieses offizielles Schreiben, die die Anwendung, wie zum Beispiel Anwendungsfälle und Hintergrundinformationen extern vorhanden ist, die von den Managern bezeichnet werden können, Anwälte und der Armen Saft, der hat Ihren Code im Jahr 2011 aktualisieren.

Ich habe mehrere Situationen auftreten, wo TDD macht mich verrückt. Einige zu nennen:

Testfall Wartbarkeit:

Wenn Sie in einem großen Unternehmen sind, sind viele Chancen, dass Sie müssen nicht die Testfälle selbst schreiben oder zumindest die meisten von ihnen werden von jemand anderem geschrieben, wenn Sie das Unternehmen ein. AN Features Änderungen der Anwendung von Zeit zu Zeit und wenn Sie nicht über ein System eingerichtet, wie HP Quality Center haben, sie zu verfolgen, können Sie in kürzester Zeit verrückt drehen werden.

Das bedeutet auch, dass es neue Teammitglieder eine angemessene Menge an Zeit in Anspruch nehmen werde zu packen, was mit den Testfällen vor sich geht. Im Gegenzug kann dies in mehr Geld übersetzt werden muß.
Die Testautomatisierung Komplexität:

Wenn Sie einige oder alle der Testfälle in maschinen runnable Test-Scripts automatisieren, werden Sie sicher, dass diese Testskripte sind synchron machen müssen mit ihren manuellen Testfällen und in Übereinstimmung mit den Anwendungsänderungen entsprechen.

Sie werden auch Zeit zum Debuggen die Codes ausgeben, die Sie Bugs fangen helfen. Meiner Meinung nach kommen die meisten dieser Fehler aus dem Scheitern des Testteam die Anwendung Änderungen im Automatisierungstestskript zu reflektieren. Änderungen in der Geschäftslogik, GUI und andere interne Sachen können Ihre Skripte nicht mehr ausgeführt oder laufen unzuverlässig machen. Manchmal sind die Veränderungen sehr subtil und schwer zu erkennen. Sobald alle meine Skripte berichten Scheitern, weil sie ihre Berechnung auf Informationen aus der Tabelle auf Basis 1, während Tabelle 1 jetzt war Tabelle 2 (weil jemand den Namen der Tabelle Objekte im Anwendungscode ausgetauscht).

Das größte Problem sind die Menschen, die nicht wissen, wie man eine gute Unit-Tests zu schreiben. Sie schreiben Tests, die voneinander abhängig sind (und sie arbeiten sehr Laufen mit Ant, aber dann alle plötzlich fehlschlagen, wenn ich sie von Eclipse-laufen, nur weil sie in einer anderen Reihenfolge ausgeführt werden). Sie schreiben Tests, die insbesondere testen alles nicht - sie den Code nur debuggen, überprüfen Sie das Ergebnis, und ändern Sie es in Test, nannte es „Test1“. Sie erweitern den Umfang von Klassen und Methoden, nur weil es einfacher für sie Unit-Tests zu schreiben. Der Code der Einheit Tests ist allerdings nicht mit allen klassischen Programmierproblemen (schwerer Kupplung, Methoden, die 500 Zeilen lang sind, hartcodierte Werte, Code-Duplizierung) und ist ein hell zu halten. Aus irgendeinem seltsamen Grund behandeln Menschen Unit-Tests als etwas schlechter als die „echten“ Code, und sie über ihre Qualität überhaupt nicht. : - (

Sie verlieren viel Zeit Tests verbracht zu schreiben. Natürlich bis zum Ende des Projektes gespeichert werden könnte dies durch Fehler schneller zu erreichen.

Sie verlieren die Fähigkeit zu sagen Sie „fertig“ sind, bevor alle Ihre Code zu testen.

Sie verlieren die Fähigkeit, Hunderte oder Tausende von Zeilen Code zu schreiben, bevor es ausgeführt wird.

Sie verlieren die Möglichkeit, durch das Debuggen zu lernen.

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

Sie verlieren die Freiheit zu eng Paar Ihre Module.

Sie verlieren Option überspringen niedrige Level-Design-Dokumentation zu schreiben.

Sie verlieren die Stabilität, die mit dem Code kommt, dass jede Angst zu ändern.

Sie verlieren den Titel "Hacker".

Der größte Nachteil ist, dass, wenn Sie wirklich TDD tun wollen richtig müssen Sie eine Menge scheitern, bevor Sie Erfolg haben. Bedenkt man, wie viele Software-Unternehmen arbeiten (Dollar pro KLOC) Sie werden schließlich gefeuert. Selbst wenn Ihr Code ist schneller, leichter, sauberer zu halten und hat wenige Fehler.

Wenn Sie in einem Unternehmen arbeiten, das Sie durch die KLOCs (oder Anforderungen umgesetzt - auch wenn nicht getestet) zahlt bleiben von TDD entfernt (oder Code-Reviews oder Paar-Programmierung, oder Continuous Integration, etc. etc. etc. ).

Ich zweite die Antwort über anfängliche Entwicklungszeit. Sie verlieren auch die Fähigkeit, ohne die Sicherheit der Tests confortably zu arbeiten. Ich habe auch als TDD Nutbars beschrieben worden ist, so könnte man ein paar Freunde verlieren;)

Refokussierung auf schwierigen, unvorhergesehene Anforderungen ist die ständige bane des Programmierers. Testgetriebene Entwicklung zwingt Sie zu den bereits bekannten, banalen Anforderungen zu konzentrieren, und schränkt die Entwicklung zu dem, was bereits vorgestellt wurde.

Denken Sie darüber nach, sind Sie wahrscheinlich auf bestimmte Testfälle, um am Ende der Gestaltung, so dass Sie nicht kreativ und anfangen zu denken „es wäre cool, wenn der Benutzer X tun könnte, Y und Z“. Daher wird, wenn der Benutzer beginnt alle begeistert von X Potential kühle Anforderungen bekommen, Y und Z, Ihr Design zu starr an bereits festgelegten Testfällen fokussiert werden kann, und es wird schwierig sein, zu justieren.

Dies ist natürlich ein zweischneidiges Schwert. Wenn Sie verbringen Ihre Zeit für jede denkbare Gestaltung vorstellbar, X, Y und Z, die ein Benutzer sich nur wünschen kann, werden Sie unweigerlich nie vollständig nichts. Wenn Sie komplette etwas tun, wird es für jedermann unmöglich sein (einschließlich sich selbst) eine Ahnung zu haben, was Sie in Ihrem Code / Design tun.

Es ist percieved als langsamer. Langfristige, die in Bezug auf die Trauer nicht wahr wird es Ihnen die Straße zu retten unten, aber Sie werden mehr Code zu schreiben am Ende so wohl bist du Zeit die Ausgaben für „Testen nicht Codierung“. Es ist ein fehlerhaftes Argument, aber du hast fragen!

Es kann schwierig und zeitaufwändig sein Schreiben von Tests für „random“ Daten wie XML-Feeds und Datenbanken (nicht schwer). Ich habe einige Zeit in letzter Zeit verbringt die Arbeit mit Wetterdaten-Feeds. Es ist ziemlich verwirrend Schreiben von Tests für das, zumindest, wie ich mit TDD nicht zu viel Erfahrung haben.

Sie werden große Klassen mit mehreren Aufgaben verlieren. Sie werden auch verlieren wahrscheinlich große Methoden mit mehreren Aufgaben. Sie können eine gewisse Fähigkeit verlieren, Refactoring, aber Sie werden auch einige der Notwendigkeit verlieren Refactoring.

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

Ich sage dies eine verpasste Abstraktion zeigt - wenn der private Code wirklich getestet werden muss, ist es wahrscheinlich in einer separaten Klasse sein sollte

Dave Mann

Sie haben Anwendungen auf eine andere Weise schreiben: eine, die sie überprüfbar macht. Sie werden überrascht sein, wie schwierig dies zunächst ist.

Einige Leute finden das Konzept darüber nachzudenken, was sie gehen zu schreiben, bevor sie es zu schwer zu schreiben. Konzepte wie spöttische kann für einige zu schwierig sein. TDD in Legacy-Anwendungen kann sehr schwierig sein, wenn sie nicht für den Test entwickelt wurden. TDD um Frameworks, die nicht TDD freundlich sind, kann auch ein Kampf sein.

TDD ist eine Fertigkeit, so Junior-Entwickler auf dem ersten kämpfen kann (vor allem, weil sie nicht gelehrt hat, auf diese Weise zu arbeiten).

Insgesamt aber die werden Nachteile wie Menschen gelöst werden qualifizierte und Sie am Ende die ‚stinkende‘ Code abstrahiert weg und haben ein stabileres System.

Es dauert einige Zeit in sie zu erhalten und einige Zeit tut es in einem Projekt zu starten, aber ... Ich habe immer bereue nicht einen Test Driven Ansatz zu tun, wenn ich dumme Fehler feststellen, dass ein automatisierter Test sehr schnell gefunden haben könnte. Darüber hinaus verbessert TDD Codequalität.

Unit-Test sind mehr Code zu schreiben, damit eine höhere Vorlaufkosten der Entwicklung
es mehr Code zu pflegen
zusätzliches Lernen erforderlich

Gute Antworten alle. Ich würde ein paar Möglichkeiten, fügen Sie die dunkle Seite der TDD zu vermeiden:

Ich habe apps geschrieben, ihren eigenen randomisierten Selbsttest zu tun. Das Problem mit spezifischen Tests zu schreiben, auch wenn Sie viele von ihnen schreiben sie nur die Fälle decken Sie denken. Random-Testgeneratoren finden Probleme, die Sie nicht gedacht.
Das gesamte Konzept der viele Unit-Tests bedeutet, dass Sie haben Komponenten, die in ungültigen Zustände, wie komplexe Datenstrukturen erhalten. Wenn Sie weg von komplexen Datenstrukturen bleiben gibt es viel weniger zu testen.
In dem Maß Anwendung erlaubt es, von Design schüchtern sein, die auf der richtigen Reihenfolge der Meldungen, Ereignisse und Nebenwirkungen beruhen. Diese können leicht fallen gelassen oder verschlüsselt bekommen, so dass sie eine Menge Tests benötigen.

TDD erfordert eine bestimmte Organisation für Ihren Code. Dies könnte ineffizient oder schwer zu lesen. Oder auch architektonisch falsch; da private Methoden nicht außerhalb einer Klasse zum Beispiel genannt werden können, müssen Sie Methoden nicht-privat machen sie prüfbar zu machen, was nur falsch ist.

Wenn Änderungen am Code, müssen Sie auch die Tests ändern. Mit diesem Refactoring kann sein, viel zusätzliche Arbeit.

Lassen Sie mich hinzufügen, dass, wenn Sie BDD Prinzipien auf einem TDD-Projekt anwenden, Sie einige der größten Nachteile hier aufgeführten lindern kann (Verwirrung, Missverständnisse, etc.). Wenn Sie mit BDD nicht vertraut sind, sollten Sie Dan North Einführung lesen. Er kam das Konzept als Antwort auf einige der Fragen auf, die am Arbeitsplatz Anwendung TDD entstanden. Dans Intro BDD können hier .

ich nur diesen Vorschlag machen, weil BDD einige dieser Negativen Adressen und wirkt als spalt Anschlag. Sie wollen, dies zu berücksichtigen, wenn Sie mit Ihrem Feedback zu sammeln.

Sie müssen sicherstellen, dass Ihre Tests sind immer auf dem neuesten Stand, Sie in dem Moment rote Lichter zu ignorieren beginnen ist der Moment, die Tests sinnlos werden.

Sie müssen auch die Tests stellen Sie sicher sind umfassend, oder der Moment, ein großer Fehler erscheint, die verstopfte Management-Typ Sie schließlich überzeugt, Sie Zeit zu lassen, mehr Code schreiben beschweren verbringen.

Die Person, die mein Team agile Entwicklung gelehrt hat bei der Planung nicht glauben, Sie schrieb nur so viel für die kleinste Anforderung.

Sein Motto war refactor, Umgestalten, Refactoring. Ich kam zu verstehen, dass Refactoring ‚nicht vorausplanen‘ zu verstehen.

Die Entwicklungszeit erhöht: Jede Methode muss das Testen und wenn Sie eine große Anwendung mit Abhängigkeiten müssen Sie Ihre Daten für die Tests vorzubereiten und zu reinigen

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow