Was ist der wahre Aufwand für TDD, wenn das gesamte Team daran gewöhnt ist?

Welcher Prozentsatz an Zeit wird durch TDD eingespart und gekostet?

Ich gehe davon aus, dass sich dieser Prozentsatz an Kosten- und Belohnungsänderungen während eines Projektlebenszyklus ändert.

Ich würde mir vorstellen, dass die Anfangsphase viel mehr kostet, aber wenig Belohnungen mit sich bringt. Weiterhin (beim Refactoring ) profitieren Sie von Ihren Tests.

Ich habe gehört, dass 30-50% Ihrer Zeit Unit-Tests schreiben. Dies berücksichtigt jedoch nicht die Zeit, die durch das Schreiben dieser Tests eingespart wurde .

Wie ist die Erfahrung aller damit?

Wir s

BEARBEITEN Was ist die Zeit gespart sowie die Zeitkosten? In Bugfixing und Refactorablity?

Ich habe gehört, dass 30-50% Ihrer Zeit Unit-Tests schreiben. Dies berücksichtigt jedoch nicht die eingesparte Zeit

Nach meiner Erfahrung sind es mehr als 50%.

Sobald Sie den Test geschrieben haben, ist die Lösung in der Regel sehr einfach. Ich halte es nicht für ungewöhnlich, 70% - 75% Ihrer Zeit damit zu verbringen, Tests zu schreiben, aber Sie verbringen viel weniger Zeit damit, den 'Produktionscode' (Code, der getestet wird) zu schreiben und praktisch keine Zeit im Debugger zu verbringen .

Je früher Sie einen Fehler finden, desto billiger ist die Behebung, und TDD hilft dabei enorm. Ich habe an Projekten gearbeitet, bei denen die letzten 2 Monate (eines 8-monatigen Projekts) damit verbracht wurden, Fehler zu beheben, und diese Phase würde mit TDD fast vollständig beseitigt werden.

Für mich liegt der wahre Wert jedoch in der Wartung. Wenn Sie eine Codebasis mit Tests erben, haben Sie weniger Angst, sie zu ändern. Sie haben das Gefühl, dass Sie nichts kaputt gemacht haben, als die Tests noch bestanden wurden. Da Sie keine Angst vor Änderungen haben, sind Sie bereit, Änderungen vorzunehmen, wenn etwas nicht stimmt. Dies bedeutet, dass der Code übersichtlicher gestaltet werden kann, das Design besser passt und theoretisch Änderungen vorgenommen werden können. Vergleichen Sie das mit Voodoo-Code, den jeder anfassen kann.

Jedes Mal, wenn Sie Ihre Komponententests ausführen, sparen Sie sich die Zeit, die Sie zum manuellen Testen Ihres Codes benötigt hätten.

Die 30% bis 50% der Zeit, die Sie für das Schreiben Ihrer Tests angeben, werden auch durch die Vorteile eines besseren (testbaren) Softwaredesigns aufgewogen.

Angenommen, das Schreiben eines automatisierten Tests dauert viermal so lange wie das manuelle Ausführen des Tests. Das bedeutet, dass sich das vierte Mal, wenn Sie Ihren automatisierten Test ausführen, bezahlt macht. Jedes Mal, wenn Sie den automatischen Test danach ausführen, ist dies kostenlos.

Dies gilt unabhängig davon, ob der Test ein automatisierter Komponententest oder ein automatisierter Funktionstest ist. Nicht alle Funktionstests können automatisiert werden, aber viele von ihnen. Außerdem ist der automatisierte Test zuverlässiger als eine Person. Der Test wird jedes Mal auf die gleiche Weise ausgeführt .

Unit-Tests bedeuten, dass Sie die zugrunde liegende Implementierung einer Methode (aus Gründen der Leistung oder aus anderen Gründen) umgestalten können. Die Unit-Tests stellen sicher, dass sich die Funktionalität der Methode nicht geändert hat. Dies gilt insbesondere für TDD, bei dem der Komponententest die Funktionalität der Methode festlegt .

TDD wird oft eher an der Codequalität gemessen als an Zeit und Kosten. Mit einer besseren Codequalität können Entwickler und alle mit ihnen arbeitenden Personen jedoch besser arbeiten (weniger Zeitaufwand, geringere Kosten, zufriedener usw.). http://davidlongstreet.wordpress.com/2009/04/29/new-software-metric-wtfs-per-minute/

Das Schreiben von Tests ist ideal, um die Überprüfung von funktionalen und nicht funktionalen Anforderungen zu automatisieren. Ein Video, das mich überzeugt hat, TDD zu übernehmen (eigentlich BDD, High Level TDD): http://video.google.com/videoplay?docid=8135690990081075324#

• Das Schreiben von Funktionstests kann dazu beitragen, Fehler / Probleme bereits in der Entwicklungsphase zu erkennen . Angenommen, Sie haben eine große Codebasis. Bei Komponententests / Spezifikationen muss nur "Alle Tests bestanden" / "2 Tests fehlgeschlagen, siehe Zeile xyz" angezeigt werden. Sie brauchen nur ein Entwicklerteam , um sowohl zu entwickeln als auch zu testen. Ohne Unit-Tests / Spezifikationen müssen Sie gedruckte Anweisungen manuell mit erwarteten Anweisungen vergleichen und manuell nachverfolgen, welche Methoden / Klassen Fehler aufweisen. Dazu benötigen Sie wahrscheinlich zwei separate Teams (Entwickler und Tester) .

• Schriftliche Tests helfen Entwicklern dabei, Fortschritte und Probleme zu erklären.

• TDD hilft dabei, die Wartbarkeit, Anpassbarkeit und Flexibilität von Code zu erfüllen. Entwickler werden ermutigt, kleine testbare Blöcke zu schreiben und sie zu größeren testbaren Blöcken zusammenzufügen. Umgekehrt (Teil der Refactoring-Praxis) funktioniert dies auch, sofern wir solide Tests geschrieben haben. Infolgedessen können wir gut geschriebenen, modularen Code haben.

Mit TDD sind wir froh zu wissen, wann:

• Ein Kunde fordert Änderungen an den Anforderungen an (Erfüllung der Anforderungen)
• Es werden bessere Möglichkeiten zum Schreiben von Code entdeckt
• Teamkollegen haben Vorschläge zur Code-Verbesserung
• Wir müssen unseren Code anderen Leuten erklären / weitergeben

TDD kann langweilig sein, weil der Entwicklungsprozess kleine Schritte erfordert und somit vorhersehbar wird.

In unserem Fall würde ich schätzen, dass es fast 40% ist. Ich glaube jedoch nicht, dass wir eine Phase durchlaufen haben, in der es noch mehr war. Wir haben einen Code-Generator, der sowohl ein Code-Skelett ausspuckt, das von den Entwicklern ausgearbeitet wird, als auch eine Testsuite, die ebenfalls ausgearbeitet wird. Der größte Teil unserer Testbemühungen besteht darin, geeignete Testdaten aufzuspüren (oder zu erstellen), um sicherzustellen, dass wir eine vollständige Abdeckung erhalten.

Die wichtigsten langfristigen Maßnahmen sind nicht nur die Codequalität und das Code-Vertrauen, sondern auch die Tatsache , dass das Team keine sinnlosen Tests durchführt

Die kurzfristigen Maßnahmen wären der ROI der Automatisierung der Tests

Zum Beispiel: Letzte Woche habe ich über 1000 Codeänderungen aufgrund einer Verschiebung der internen Architektur vorgenommen, die automatisierte Testsuite gestartet und bin eingeschlafen.

Die Tests dauerten 28 Minuten. sie alle gingen vorbei. Das manuelle Durchführen derselben über 40 Abnahmetests würde ungefähr 6 Stunden dauern.

Ein weiteres Beispiel: In einer früheren Iteration hatte ich eines der Testszenarien mit einem subtilen Fehler überlistet, den manuelle Tests wahrscheinlich nicht gefunden hätten (die automatisierten Tests führen DB-Integritätsprüfungen durch, die manuelle Tester so gut wie nie durchführen). Ich musste dieses Testszenario ungefähr 50 Mal ausführen, bevor ich es herausfinden und reparieren konnte. Das manuelle Durchführen der Testszenariooperationen würde etwa 50 Minuten dauern. Das sind also 41,6 Arbeitsstunden, die an einem Tag eingespart werden

Es gibt keine Möglichkeit, den ROI automatisierter Tests im Voraus zu berechnen, da Sie nicht genau wissen können, wie oft Sie die Tests ausführen müssen.

Für mich ist der ROI automatisierter Tests nahezu unbegrenzt

Es kann sehr hilfreich sein, Komponententests auf komplexe Algorithmen, Fälle, in denen sie automatisch generiert werden können, und Regressionen zu beschränken.

Komponententests leisten oft gute Arbeit bei eher trivialem Code, und das Ändern der Implementierung ist viel billiger, da die Tests nur an die Schnittstelle gekoppelt sind.

Die vollständige Abdeckung mit feinkörnigen Komponententests verursacht einen enormen Aufwand für das Ändern oder Umgestalten einer Implementierung, was genau das ist, was sie für einfach halten.