Die relative Kosteneffizienz einer (Akzeptanz-) testgetriebenen Entwicklung

15

Ich möchte wissen, wie sich die Ressourcenplanung insgesamt auf ein Softwareprojekt auswirkt, bei dem die Anforderungen und das Design des Projekts durch automatisierte Abnahmetests und Komponententests im Gegensatz zu einem eher "traditionellen" Ansatz bei der Softwareentwicklung bestimmt werden.

Bildbeschreibung hier eingeben

Wie wirkt sich Ihrer Erfahrung nach die Gesamtwirkung auf den Ressourcenbedarf für die Fertigstellung eines Softwareprojekts im Rahmen von TDD im Gegensatz zu "traditionelleren" Entwicklungsmethoden aus? Für mich ist es selbstverständlich, dass die Qualität zunimmt und die Unsicherheit abnimmt, da die Tests früher durchgeführt werden. Es scheint jedoch, als würde die Durchführung von Tests im Vorfeld mehr Entwicklerstunden erfordern. Wie stark steigt der Entwicklungsaufwand oder sinkt er tatsächlich aufgrund der Beseitigung von Fehlern im Vorfeld?

Wie viel mehr Aufwand verlangt der Kunde? Müssen sie ihre Beziehung zum Projekt ändern, insbesondere wenn sie es gewohnt sind, im Vorfeld große Designs zu entwerfen? Erhöht sich der Arbeitsaufwand des Kunden insgesamt oder verringert er sich tatsächlich?

Ich würde mir vorstellen, dass Zeitschätzungen in einem iterativen TDD-Prozess zu Beginn eines TDD-Projekts sehr vage sind (da es keinen Softwareentwicklungsplan gibt). Gibt es einen Punkt, sagen wir 20% in einem Projekt, an dem das Vertrauen genug steigt, dass dem Kunden schließlich eine mehr oder weniger stabile Zeit- und Geldschätzung zur Verfügung gestellt werden kann?

Hinweis: Ich suche hier nicht nach subjektiven Meinungen oder Theorien, bitte spekulieren Sie nicht. Ich suche mehr nach realer Erfahrung in TDD.

Robert Harvey
quelle
Ich bin sicher, dass es keine realen Daten gibt. Sie erhalten nur subjektive Meinungen und Theorien, die auf der realen Erfahrung von Menschen basieren.
Euphoric
1
@Euphoric: Ich suche nach objektiven Beobachtungen und Realitäten, die auf realen Erfahrungen basieren. Entschuldigung, das habe ich nicht klargestellt. Ich brauche jedoch keine harten Zahlen; Ich akzeptiere allgemeine Eindrücke wie: "Während sich unsere Entwicklungszeit erheblich verlängerte, verringerten sich unsere Wartungskosten, weil die Software zuverlässiger war und der Kunde die Software besser verstand, weil sie während des gesamten Entwicklungsaufwands am Design beteiligt war."
Robert Harvey
2
Also, ist das eine meinungsbasierte Frage? Es klingt sicherlich wie eine
BЈовић
@ BЈовић: Siehe den letzten Absatz in meinem Fragekörper.
Robert Harvey

Antworten:

11

Zunächst ist festzustellen, dass TDD die Qualität der Software (aus Sicht des Benutzers) nicht unbedingt erhöht. Es ist keine Silberkugel. Es ist kein Allheilmittel. Das Verringern der Anzahl von Fehlern ist nicht der Grund, warum wir TDD machen.

TDD wird hauptsächlich durchgeführt, weil es zu besserem Code führt. Insbesondere führt TDD zu Code, der einfacher zu ändern ist .

Ob Sie TDD verwenden möchten oder nicht, hängt mehr von Ihren Projektzielen ab. Wird dies ein kurzfristiges Beratungsprojekt sein? Müssen Sie das Projekt nach dem Go-Live unterstützen? Ist es ein triviales Projekt? In diesen Fällen lohnt sich der zusätzliche Aufwand möglicherweise nicht.

Ich habe jedoch die Erfahrung gemacht, dass das Wertversprechen für TDD exponentiell zunimmt, wenn der Zeit- und Ressourcenaufwand für ein Projekt linear zunimmt.

Gute Unit-Tests bieten folgende Vorteile:

  1. Unit-Tests warnen Entwickler vor unbeabsichtigten Nebenwirkungen.
  2. Unit-Tests ermöglichen die schnelle Entwicklung neuer Funktionen auf alten, ausgereiften Systemen.
  3. Unit-Tests ermöglichen neuen Entwicklern ein schnelleres und genaueres Verständnis des Codes.

Ein Nebeneffekt von TDD sind möglicherweise weniger Fehler, aber nach meiner Erfahrung werden die meisten Fehler (insbesondere die schlimmsten) in der Regel durch unklare oder schlechte Anforderungen verursacht oder würden nicht unbedingt in der ersten Runde der Komponententests behandelt.

Zusammenfassen:

Die Entwicklung in Version 1 ist möglicherweise langsamer. Die Entwicklung auf Version 2-10 wird schneller sein.

Stephen
quelle
1
Ich mag die explizite Gegenüberstellung von "besserem Code", die sich von der Steigerung der "Qualität der Software" unterscheidet, das heißt, dass die Dinge, die Programmierer im Code schätzen, nicht unbedingt das sind, was der Kunde will.
1
Sollen Vorab-Abnahmetests und Unit-Tests die Anforderungen nicht klären ?
Robert Harvey
@RobertHarvey Sie sollten sein , sind aber nicht unbedingt . Die Komponententests und Abnahmetests geben das Verständnis des Entwicklers für die Anforderungen zum Zeitpunkt der Erstellung wieder. Die Entwickler haben möglicherweise ein umfassendes Verständnis der Anforderungen, wenn sie mit dem Schreiben der Software beginnen. Dieser Teil der Gleichung hängt mehr vom Kunden und Produktmanager ab als alles andere. Theoretisch sollten die Tests viel helfen. In der Praxis kommt es darauf an.
Stephen
1
Ich sollte klarstellen, wir sprechen hier isoliert von TDD und nicht von einer SCRUM-Implementierung, die TDD enthält. Bei TDD geht es isoliert darum, Tests zu schreiben, damit Sie besseren Code schreiben und später schneller und sicherer umgestalten können.
Stephen
1
@Stephen: Vielleicht hätte ich klarer machen sollen, dass ich über den Geschmack von TDD spreche, das Akzeptanztests als Teil des Anforderungserfassungsprozesses beinhaltet. Ich habe der Frage eine Grafik hinzugefügt, um dies zu verdeutlichen.
Robert Harvey
6

Es gibt ein Kapitel in Making Software über testgetriebene Entwicklung, in dem das hier diskutierte Papier zitiert wird .

Fallstudien wurden mit drei Entwicklerteams bei Microsoft und einem bei IBM durchgeführt, die TDD übernommen haben. Die Ergebnisse der Fallstudien zeigen, dass die Fehlerdichte vor der Freigabe der vier Produkte im Vergleich zu ähnlichen Projekten, bei denen die TDD-Praxis nicht angewendet wurde, zwischen 40% und 90% abnahm. Subjektiv konnten die Teams nach der Einführung von TDD eine Verlängerung der anfänglichen Entwicklungszeit um 15–35% verzeichnen.

Ob diese Ergebnisse für Ihren Fall verallgemeinerbar sind, ist natürlich etwas, das Befürworter von TDD argumentieren, und Kritiker von TDD argumentieren, ist unwahr.


quelle
4
Das Problem bei dieser Studie ist, dass sie den Code vor der Anpassung von TDD nicht getestet haben. TDD ist kein magisches Werkzeug, das die Anzahl der Fehler um 40-90%
reduziert,
1
@ BЈовић Ich glaube nicht, dass sie irgendwo in dieser Zeitung "Magie" behaupten. Sie behaupten, dass einige Teams TDD übernommen haben, andere nicht, ihnen "ähnliche" Arbeiten übertragen wurden und einige Fehlerdichten und Entwicklungszeiten aufgezeichnet wurden. Wenn sie die Nicht-TDD-Teams dazu gezwungen hätten, Komponententests zu schreiben, nur um allen Komponententests zu ermöglichen, wäre dies keine ökologisch gültige Studie.
Eine ökologisch valide Studie? Sorta hängt davon ab, was Sie messen. Wenn Sie , ob das Schreiben der Tests wissen wollen vorne Angelegenheiten, dann muss jeder schreiben Unit - Tests sein, nicht nur die TDD - Gruppe.
Robert Harvey
1
@robert Harvey Das ist eine Frage der Verwechslung von Variablen, nicht der ökologischen Gültigkeit. Um ein gutes Experiment zu entwerfen, müssen die Teilnehmer abgestuft werden. Wenn die Kontrollgruppe beispielsweise post-hoc Unit-Tests schrieb, argumentierten die Leute, dass das Experiment nicht stichhaltig sei, da die Kontrollgruppe auf eine Weise arbeitete, die in der freien Natur ungewöhnlich ist.
2
Zum Glück habe ich das nicht gesagt.
5

Ich habe keine Forschungsarbeiten oder Statistiken, aber ich werde meine Erfahrungen aus der Arbeit in einem Team / einer Organisation, die in der Vergangenheit nur eine geringe bis durchschnittliche Abdeckung durch Unit-Tests und keine End-to-End-Tests aufwiesen, schrittweise wiedergeben Bewegen Sie die Messlatte dorthin, wo wir jetzt sind, mit mehr ATDD-Ansatz (aber ironischerweise nicht mit herkömmlichem TDD).

Dies ist insbesondere die Art und Weise, in der Projektzeitpläne abgespielt wurden (und weiterhin für andere Teams / Produkte in derselben Organisation abgespielt werden):

  • Bis zu 4 Wochen Analyse und Implementierung
  • 2 Wochen Regressionstest, Fehlerbehebung, Stabilisierung und Release-Vorbereitung
  • 1-2 Wochen nach der Behebung bekannter Mängel
  • 2-3 Wochen Code-Bereinigung und Probleme / Support nach der Produktion (unbekannte Fehler / ungeplante Ausfälle)

Dies scheint ein lächerlicher Aufwand zu sein, ist jedoch tatsächlich sehr verbreitet. In vielen Organisationen wird dies nur häufig durch fehlende oder ineffektive Qualitätssicherung maskiert. Wir haben gute Tester und eine Kultur intensiver Tests, so dass diese Probleme frühzeitig erkannt und (meistens) im Voraus behoben werden, anstatt sich über einen Zeitraum von vielen Monaten / Jahren langsam zu entwickeln. 55-65% Wartungsaufwand ist geringer als die allgemein akzeptierte Norm von 80% der Zeit auf dem Debuggen ausgegeben werden - was sinnvoll erscheint, weil wir hatten einige Unit - Tests und funktionsübergreifende Teams (einschließlich QA).

Während der ersten Veröffentlichung unseres neuesten Produkts durch unser Team hatten wir begonnen, Abnahmetests nachzurüsten, aber sie waren nicht ganz auf dem neuesten Stand und wir mussten uns immer noch auf viele manuelle Tests verlassen. Die Veröffentlichung war etwas weniger schmerzhaft als andere, IMO teilweise aufgrund unserer willkürlichen Akzeptanztests und auch teilweise aufgrund unserer sehr hohen Abdeckung durch Komponententests im Vergleich zu anderen Projekten. Dennoch haben wir fast zwei Wochen für die Regression / Stabilisierung und zwei Wochen für die Nachbearbeitung aufgewendet.

Im Gegensatz dazu hatte jede Veröffentlichung seit dieser ersten Veröffentlichung frühe Akzeptanzkriterien und Akzeptanztests, und unsere aktuellen Iterationen sehen folgendermaßen aus:

  • 8 Tage Analyse und Implementierung
  • 2 Tage Stabilisierung
  • 0-2 Tage kombinierter Support und Bereinigung nach der Produktion

Mit anderen Worten, wir sind von 55-65% des Wartungsaufwands auf 20-30% des Wartungsaufwands gestiegen. Gleiches Team, gleiches Produkt, der Hauptunterschied ist die fortschreitende Verbesserung und Straffung unserer Abnahmetests.

Die Kosten für die Wartung betragen pro Sprint 3-5 Tage für einen QA-Analysten und 1-2 Tage für einen Entwickler. Unser Team besteht aus 4 Entwicklern und 2 QA-Analysten. (Ohne UX, Projektmanagement usw.) Das sind maximal 7 von 60 Manntagen. Dies wird auf einen Implementierungsaufwand von 15% aufgerundet die sichere Seite.

Wir verbringen 15% jeder Veröffentlichungsperiode damit, automatisierte Abnahmetests zu entwickeln. Dabei können wir 70% jeder Veröffentlichung reduzieren, indem wir Regressionstests durchführen und Fehler vor und nach der Produktion beheben.

Sie haben vielleicht bemerkt, dass die zweite Zeitachse viel genauer und auch viel kürzer ist als die erste. Dies wurde durch die Akzeptanzkriterien und Akzeptanztests im Vorfeld ermöglicht, da dies die "Definition von erledigt" erheblich vereinfacht und es uns ermöglicht, viel sicherer auf die Stabilität einer Veröffentlichung zu vertrauen. Kein anderes Team hat (bis jetzt) ​​einen zweiwöchentlichen Release-Zeitplan erhalten, außer vielleicht bei relativ einfachen Wartungs-Releases (nur Bugfixes usw.).

Ein weiterer interessanter Nebeneffekt ist, dass wir unseren Release-Zeitplan an die Geschäftsanforderungen anpassen konnten. Einmal mussten wir es auf ungefähr 3 Wochen verlängern, um es mit einem anderen Release zu vereinbaren, und konnten dies tun, während wir mehr Funktionalität lieferten, ohne zusätzliche Zeit für Tests oder Stabilisierung aufzuwenden. Ein anderes Mal mussten wir es aufgrund von Feiertagen und Ressourcenkonflikten auf ungefähr 1½ Wochen verkürzen. wir mussten weniger entwicklungsarbeit leisten, konnten aber erwartungsgemäß entsprechend weniger zeit für tests und stabilisierungen aufwenden, ohne neue mängel einzuführen.

Aus meiner Erfahrung heraus sind Abnahmetests, insbesondere wenn sie sehr früh in einem Projekt oder Sprint durchgeführt werden und die vom Product Owner festgelegten Abnahmekriterien eingehalten werden, eine der besten Investitionen, die Sie tätigen können. Im Gegensatz zu herkömmlichen TDD, die richtig andere Menschen konzentrierten mehr darauf hin , auf der Schaffung von prüfbaren Code als fehlerfreien Code - ATDD tut wirklich Hilfe Fang Mängel viel schneller; Es ist das organisatorische Äquivalent zu einer Armee von Testern, die jeden Tag einen vollständigen Regressionstest durchführt, aber viel billiger.

Hilft Ihnen ATDD bei längerfristigen Projekten im RUP- oder (ugh) Waterfall-Stil, die 3 Monate oder länger dauern? Ich denke, die Jury ist immer noch nicht damit einverstanden. Nach meiner Erfahrung sind die größten und hässlichsten Risiken bei langfristigen Projekten unrealistische Fristen und sich ändernde Anforderungen. Unrealistische Fristen führen dazu, dass Benutzer Verknüpfungen verwenden, einschließlich Testverknüpfungen, und signifikante Änderungen an den Anforderungen machen wahrscheinlich eine große Anzahl von Tests ungültig, sodass sie neu geschrieben werden müssen und möglicherweise den Implementierungsaufwand erhöhen.

Ich bin mir ziemlich sicher, dass ATDD eine fantastische Auszahlung für agile Modelle oder für Teams hat, die nicht offiziell agil sind, aber sehr häufige Veröffentlichungspläne haben. Ich habe es noch nie bei einem Langzeitprojekt ausprobiert, hauptsächlich, weil ich noch nie von einer Organisation gehört habe, die bereit ist, es bei einem solchen Projekt auszuprobieren. Fügen Sie daher hier den Standard-Haftungsausschluss ein. YMMV und das alles.

PS In unserem Fall ist kein zusätzlicher Aufwand für den "Kunden" erforderlich, aber wir haben einen engagierten, hauptberuflichen Product Owner, der die Akzeptanzkriterien tatsächlich schreibt. Wenn Sie im Bereich "Consultingware" tätig sind, könnte es meiner Meinung nach viel schwieriger sein, die Endbenutzer dazu zu bringen, nützliche Akzeptanzkriterien zu schreiben. Ein Product Owner / Product Manager scheint ein ziemlich wesentliches Element für ATDD zu sein, und obwohl ich wieder nur aus eigener Erfahrung sprechen kann, habe ich noch nie davon gehört, dass ATDD erfolgreich praktiziert wird, ohne dass jemand diese Rolle übernimmt.

Aaronaught
quelle
Das ist sehr nützlich, danke. Mir ist nicht in den Sinn gekommen, dass ATTD den Charakter der TDD-Bemühungen verändern könnte, aber es ist sinnvoll, insbesondere wenn man von Leuten hört, die in der Lage sind, gut geschriebene, relativ fehlerfreie Software pünktlich und kostengünstig ohne zu produzieren unbedingt ausgiebig Unit-Tests nutzen.
Robert Harvey
@RobertHarvey: Ich sollte klarstellen, dass wir immer noch Komponententests erstellen, nur nicht als Teil eines TDD-Prozesses. In der Regel werden die Abnahmetests zuerst oder parallel zur anfänglichen Entwicklung durchgeführt, dann wird der Code vervollständigt, dann werden die Komponententests durchgeführt und das Refactoring durchgeführt. Ich habe manchmal gedacht, dass TDD bestimmten Entwicklern helfen würde, besseren Code zu schreiben, aber ich kann das (noch) nicht sichern. Obwohl ich für mich selbst sprechen kann, stoße ich beim Schreiben der Komponententests häufig auf Fehler und Designmängel in meinem eigenen Code.
Aaronaught
1

Ressourcenanforderungen

Wie wirkt sich Ihrer Erfahrung nach die Gesamtwirkung auf den Ressourcenbedarf für die Fertigstellung eines Softwareprojekts im Rahmen von TDD im Gegensatz zu "traditionelleren" Entwicklungsmethoden aus?

Meiner Erfahrung nach werden die Kosten für Vorabprüfungen sofort gesenkt, indem zunächst klare Akzeptanzkriterien festgelegt und dann in den Test geschrieben werden. Ich habe festgestellt, dass nicht nur die Kosten für die Vorabprüfung gesenkt werden, sondern auch die Gesamtentwicklung insgesamt beschleunigt wird. Obwohl diese Geschwindigkeitsverbesserungen möglicherweise durch eine schlechte Projektdefinition oder sich ändernde Anforderungen zunichte gemacht werden. Wir sind jedoch immer noch in der Lage, ohne gravierende Auswirkungen auf diese Art von Änderungen zu reagieren. In den folgenden Fällen reduziert ATDD den Entwickleraufwand bei der Überprüfung des korrekten Systemverhaltens mithilfe der automatisierten Testsuite erheblich:

  • große refactors
  • Plattform- / Paket-Upgrades
  • Plattformmigration
  • Toolchain-Upgrades

Dies setzt ein Team voraus, das mit den Abläufen und Praktiken vertraut ist.

Einbeziehung der Kunden

Wie viel mehr Aufwand verlangt der Kunde?

Sie müssen ständig viel mehr einbezogen werden. Ich habe eine enorme Reduzierung der Anfangsinvestitionen gesehen, aber eine noch viel größere Nachfrage. Ich habe nicht gemessen, aber ich bin mir ziemlich sicher, dass dies eine größere Zeitinvestition für den Kunden darstellt.

Ich habe jedoch festgestellt, dass sich die Kundenbeziehung nach etwa fünf Demos, bei denen die Software langsam Gestalt annimmt, erheblich verbessert. Das zeitliche Engagement des Kunden nimmt mit der Zeit etwas ab, da ein Rapport entwickelt wird, an den sich jeder gewöhnt und an die damit verbundenen Erwartungen.

Projektschätzung

Ich würde mir vorstellen, dass Zeitschätzungen in einem iterativen TDD-Prozess zu Beginn eines TDD-Projekts sehr vage sind (da es keinen Softwareentwicklungsplan gibt).

Ich habe festgestellt, dass dies in der Regel eine Frage ist, wie gut die Frage definiert ist und ob der / die technische (n) Lead (s) in der Lage ist (einschließlich Kartenschätzung), das Projekt auszuwerten. Vorausgesetzt, das Projekt ist gut durchdacht und Sie haben einen angemessenen Geschwindigkeitsdurchschnitt und eine angemessene Standardabweichung. Wir haben festgestellt, dass es einfach ist, eine anständige Schätzung zu erhalten. Je größer das Projekt ist, desto größer ist natürlich die Unsicherheit, weshalb ich ein großes Projekt in der Regel in ein kleines Projekt aufspalte, mit dem Versprechen, es später fortzusetzen. Dies ist viel einfacher, wenn Sie eine Beziehung zum Kunden hergestellt haben.

Beispielsweise:

Die "Sprints" meines Teams dauern eine Woche und wir haben einen laufenden Durchschnitt und Standard. Abweichung der letzten 14 Wochen. Wenn das Projekt 120 Punkte hat, haben wir einen Mittelwert von 25 und einen Standardwert. Eine Abweichung von 6, die den Abschluss eines Projekts schätzt, ist:

Project Total / (Mean Velocity - (2 * Std. Deviation) = 95% Time Estimate
120           / (25            - (2 * 6             ) = 9.2 weeks

Wir verwenden die 2 Std. Faustregel für die Abweichung unserer 95% -Konfidenzschätzung. In der Praxis schließen wir das Projekt in der Regel unter dem ersten Standard ab. Abweichung, aber über unseren Durchschnitt. Dies ist normalerweise auf Verbesserungen, Änderungen usw. zurückzuführen.

dietbuddha
quelle
Sie sagen also im Grunde, dass TDD die Entwicklungsbemühungen verbessert, indem es die Stakeholder dazu auffordert, die Dinge zu tun, die sie sowieso tun sollten, wie beispielsweise klare, umsetzbare Anforderungen und Akzeptanzkriterien.
Robert Harvey
1
Nun, nicht nur das. Im Verlauf des Projekts ermöglicht die verstärkte Beteiligung eine bessere Konversation zwischen Entwicklern und Stakeholdern. Es ermöglicht beispielsweise, dass Entwickler kostengünstigere Alternativen anbieten, da ihr Verständnis der Wünsche der Stakeholder weiter verfeinert wird. Es ermöglicht den Stakeholdern, Anforderungen früher zu ändern, wenn sie feststellen, dass Dinge fehlen oder ohne eine solche antagonistische Reaktion von dev nicht funktionieren. und ohne viele der unangemessenen Erwartungen, die normalerweise von den Stakeholdern kommen.
Dietbuddha
-1

Das Erfordernis von Tests im Vorfeld scheint mehr Entwicklerstunden zu erfordern. Wie stark steigt der Entwicklungsaufwand oder sinkt er tatsächlich aufgrund der Beseitigung von Fehlern im Vorfeld?

Das stimmt eigentlich nicht. Wenn Ihre Entwickler Komponententests schreiben (und das sollten sie), sollte die Zeit ungefähr gleich oder besser sein. Ich sagte es besser, da Ihr Code vollständig getestet wird und sie nur den Code schreiben müssen, um die Anforderungen zu erfüllen.

Das Problem bei Entwicklern ist, dass sie dazu neigen, auch Dinge zu implementieren, die nicht erforderlich sind, um die Software so allgemein wie möglich zu gestalten.

Wie viel mehr Aufwand verlangt der Kunde? Müssen sie ihre Beziehung zum Projekt ändern, insbesondere wenn sie es gewohnt sind, im Vorfeld große Designs zu entwerfen? Erhöht sich der Arbeitsaufwand des Kunden insgesamt oder verringert er sich tatsächlich?

Das sollte keine Rolle spielen. Wer die Anforderungen erfüllt, sollte es so gut wie möglich machen.

Wenn Sie eine agile Entwicklungsweise verfolgen, bedeutet dies nicht, dass Sie im Vorfeld viel Design haben. Je besser jedoch die Anforderungen, die Architektur und das Design sind, desto höher ist die Codequalität und desto kürzer ist die Zeit bis zur Fertigstellung der Software.

Deshalb, wenn sie BDUF machen möchten, lassen Sie sie es machen. Dies erleichtert Ihnen das Leben als Entwickler.

BЈовић
quelle
1
Nach meinem Verständnis sind TDD und BDUF im Allgemeinen nicht miteinander kompatibel.
Robert Harvey
3
BDUF ist im Allgemeinen nicht mit einer guten Entwicklungsmanagementpraxis kompatibel. Es wäre jedoch möglich, ein BDUF-Projekt auf TDD-Weise durchzuführen. TDD ist eine Technik zum Erstellen von Software mit besserer Qualität, während BDUF eine Technik zum Ermitteln von Anforderungen ist. Eine schlechte Technik, aber dennoch eine Technik.
Stephen
@RobertHarvey Richtig, aber wenn sie BDUF machen wollen, ist es ihre Wahl. Wenn Sie wirklich agil sind, können Sie das Design verbessern und trotzdem TDD durchführen.
BЈовић
Sie sagen also, wenn ich Unit-Test schreibe, wird mein Code vollständig getestet und wenn alle Tests bestanden werden, bedeutet das natürlich, dass die Software fehlerfrei ist (oder zumindest besser). Also muss ich einfach jede Methode meiner Software testen, zB "function testSqr () {int a = 3; assertTrue (mySqr (a) == 9);} function mySqr (int a) {return 9;}"
Dainius
@Dainius Nein, lies nochmal. 100% Code-Abdeckung ist nicht fehlerfrei. Ja, Sie müssen jede Methode einem Komponententest unterziehen. Natürlich macht ein Unit-Test des Datenbankzugriffs, der Benutzeroberfläche usw. keinen Sinn. Unit-Tests sind nichts für solche.
BЈовић