Welche Auswirkungen hat die Erstellung von Komponententests während der Entwicklung auf die Entwicklungszeit sowie auf die Zeit, die für Wartungsarbeiten aufgewendet wird?

Ich bin ein Berater und werde allen Entwicklern bei meinem Kunden Unit-Tests vorstellen. Mein Ziel ist es sicherzustellen, dass für alle neuen Anwendungen Komponententests für alle erstellten Klassen durchgeführt werden.

Der Client hat ein Problem mit hohen Wartungskosten durch das Beheben von Fehlern in seinen vorhandenen Anwendungen. Ihre Anwendungen haben eine Lebensdauer zwischen 5 und 15 Jahren, in denen sie kontinuierlich neue Funktionen hinzufügen. Ich bin ziemlich zuversichtlich, dass sie von den ersten Tests in großen Teilen profitieren werden.

Ich interessiere mich für die Auswirkung von Komponententests auf Zeit und Kosten der Entwicklung:

• Wie viel Zeit wird das Schreiben von Komponententests im Rahmen des Entwicklungsprozesses in Anspruch nehmen?
• Wie viel Zeit wird bei Wartungsaktivitäten (Testen und Debuggen) durch gute Komponententests gespart?

Gibt es Statistiken darüber, wie lange die Entwicklung von Anwendungen beim Erstellen von Komponententests während der Entwicklung im Vergleich zur reinen Codierung dauert?

Es gibt einige sehr interessante Untersuchungen dazu. Lesen Sie das folgende Whitepaper:

Qualitätsverbesserung durch testgetriebene Entwicklung: Ergebnisse und Erfahrungen von vier Industrieteams

Das Whitepaper und andere Forschungsergebnisse eines seiner Autoren, Nachi Nagappan , werden hier diskutiert: http://research.microsoft.com/en-us/news/features/nagappan-100609.aspx

Die Studie und ihre Ergebnisse wurden in einem Artikel mit dem Titel "Qualitätsverbesserung durch testgetriebene Entwicklung" veröffentlicht: Ergebnisse und Erfahrungen von vier Industrieteams von Nagappan und Forschungskollegen E. Michael Maximilien vom IBM Almaden Research Center; Thirumalesh Bhat, leitender Softwareentwickler bei Microsoft; und Laurie Williams von der North Carolina State University. Das Forschungsteam stellte fest, dass die TDD-Teams Code produzierten, der in Bezug auf die Defektdichte 60 bis 90 Prozent besser war als Nicht-TDD-Teams. Sie stellten auch fest, dass TDD-Teams länger brauchten, um ihre Projekte abzuschließen - 15 bis 35 Prozent länger.

„In einem Entwicklungszyklus von 12 Monaten sind 35 Prozent weitere vier Monate, was enorm ist“, sagt Nagappan. „Der Nachteil ist jedoch, dass Sie die Wartungskosten nach der Veröffentlichung erheblich reduzieren, da die Codequalität so viel besser ist. Auch dies sind Entscheidungen, die Manager treffen müssen - wo sollten sie den Treffer hinnehmen? Aber jetzt haben sie tatsächlich quantifizierte Daten, um diese Entscheidungen zu treffen. “

Zusätzlich Jason Gorman hat ein solches Experiment vorgeschlagen für die Software Craftsmanship Konferenz in diesem Jahr. Er hat ein Experiment versucht, bei dem dieselbe Anwendung mit einem TDD- und einem Nicht-TDD-Ansatz erstellt wurde, und hat kürzlich über seine Ergebnisse gebloggt :

In 3 Iterationen betrug die durchschnittliche Zeit für die Fertigstellung der Kata ohne TDD 28 Minuten und 40 Sekunden. Durchschnittliche Zeit mit TDD war 25m 27s. Ohne TDD schaffte ich im Durchschnitt 5,7 Durchgänge (Abnahmeprüfung). Mit TDD habe ich im Durchschnitt 1,3 Durchgänge gemacht (in zwei Versuchen haben sie das erste Mal bestanden, in einem waren es 2 Durchgänge).

Das war natürlich ein Babyexperiment. Und nicht gerade Laborbedingungen. Aber ich stelle trotzdem ein paar interessante Dinge fest.

Es wird interessant sein, die vollständigen Ergebnisse dieses Experiments zu sehen, wenn mehr Leute es durchführen.

Gibt es Statistiken, aus denen hervorgeht, wie viele Stunden die Wartung bei (guten) Komponententests abnimmt?

Aus dem obigen Whitepaper:

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.