Gibt es eindeutige Beweise für den ROI von Komponententests?

Question

Komponententests klingen gut für mich, aber ich bin mir nicht sicher, ob ich es wirklich lernen sollte, es sei denn, ich kann andere davon überzeugen, dass es einen signifikanten Wert hat. Ich muss die anderen Programmierer und, noch wichtiger, die Bean-Counter im Management davon überzeugen, dass die ganze zusätzliche Zeit, die ich damit verbracht habe, das Testframework zu lernen, Tests zu schreiben, sie auf dem neuesten Stand zu halten usw. sich bezahlt macht.

Welchen Beweis gibt es? Hat jemand tatsächlich die gleiche Software mit zwei separaten Teams entwickelt, von denen eines den Komponententest verwendet und der andere nicht, und die Ergebnisse verglichen hat? Ich bezweifle das. Soll ich das nur begründen mit: "Schaut es euch im Internet an, alle reden darüber, also muss es das Richtige sein"?

Wo ist der harte Beweis, der die Laien davon überzeugen wird, dass Unit Testing die Mühe wert ist?

Answer 1

Ja. Dies ist eine link einer Studie von Boby George und Laurie Williams bei NCST und eine another von Nagappan et al. Ich bin mir sicher, dass es mehr gibt. Dr. Williams publications beim Testen kann einen guten Ausgangspunkt für die Suche bieten.

[EDIT] Die beiden oben genannten Artikel beziehen sich spezifisch auf TDD und zeigen eine Zunahme der anfänglichen Entwicklungszeit um 15-35% nach der Einführung von TDD, aber eine 40-90% ige Abnahme der Vorabfreigabe-Defekte. Wenn Sie die Volltextversionen nicht lesen können, empfehle ich Ihnen, Google Scholar zu verwenden, um zu sehen, ob Sie eine öffentlich verfügbare Version finden können.

Answer 2

Es gibt Statistiken, die belegen, dass das Beheben eines im Unit/Integrationstest gefundenen Fehlers um ein Vielfaches weniger kostet als das Fixieren auf dem Live-System (sie basieren auf der Überwachung von Tausenden von realen Projekten).

bearbeitet: zum Beispiel, wie erwähnt, das Buch „Code Complete“ Berichte über solche Studien (Ziffer 20.3, „Relative Wirksamkeit der Qualitätstechnik“). Aber es gibt auch private Forschung im Consulting-Bereich, die das ebenfalls beweist.

Answer 3

Wir haben mit harten Beweisen bewiesen, dass es möglich ist, beschissene Software ohne Unit Testing zu schreiben. Ich glaube, es gibt sogar Beweise für schlechte Software mit Unit Testing. Aber das ist nicht der Punkt.

Unit Testing oder Test Driven Development (TDD) ist eine Konstruktionstechnik, keine Testtechnik. Code, der testgesteuert geschrieben wird, sieht völlig anders aus als Code, der nicht getestet wird.

Auch wenn dies nicht Ihre Frage ist, frage ich mich, ob es wirklich der einfachste Weg ist, die Straße hinunter zu gehen und Fragen zu beantworten (und Beweise bringen, die von anderen Berichten angefochten werden könnten), die falsch gestellt werden könnten. Selbst wenn Sie harte Beweise für Ihren Fall finden - jemand anderes könnte harte Beweise dagegen finden.

Ist es das Geschäft der Bean Counters zu bestimmen, wie die technischen Mitarbeiter arbeiten sollten? Gibt es in allen Fällen die billigsten Tools, weil sie glauben, dass Sie keine teureren benötigen?

Dieses Argument wird entweder basierend auf Vertrauen (einer der grundlegenden Werte agiler Teams) oder auf Basis der Rollenstärke der siegreichen Partei gewonnen. Selbst wenn die TDD-Befürworter auf der Grundlage von Rollenstärke gewinnen, würde ich es als verloren ansehen.

Answer 4

Ich nehme einen anderen Ansatz, um diese:

Welche Sicherheit haben Sie, dass der Code korrekt ist? Oder dass es Annahme X nicht bricht, wenn jemand in Ihrem Team func1() ändert? Ohne Unit-Tests, die dich "ehrlich" halten, bin ich mir nicht sicher, ob du viel Sicherheit hast.

Die Idee, Tests zu aktualisieren, ist interessant. Die Tests selbst müssen sich nicht oft ändern. Ich habe 3x den Testcode im Vergleich zum Produktionscode, und der Testcode wurde geändert sehr wenig. Es ist jedoch, was mich nachts gut schlafen lässt und die Sache, die es mir ermöglicht, dem Kunden zu sagen, dass ich zuversichtlich bin, dass ich die Y-Funktionalität implementieren kann, ohne das System zu brechen.

Vielleicht in der Wissenschaft gibt es Beweise, aber ich habe nie irgendwo in der kommerziellen Welt gearbeitet, wo jemand für einen solchen Test bezahlen würde.Ich kann Ihnen jedoch sagen, dass es gut für mich gearbeitet hat, nahm wenig Zeit, um sich an den Test-Framework zu gewöhnen und schreiben Test machte mich wirklich denke über meine Anforderungen und das Design, weit mehr als ich jemals bei der Arbeit Teams, die keine Tests geschrieben haben.

Hier ist, wo es sich auszahlt: 1) Sie haben Vertrauen in Ihren Code und 2) Sie fangen Probleme früher als Sie es sonst tun würden. Sie haben nicht die QA-Typ sagen "Hey, Sie haben nicht Grenzen Grenzen-checking die xyz() -Funktion, haben Sie? Er nicht bekommen, um diesen Fehler zu finden, weil Sie es vor einem Monat gefunden. Das ist gut für ihn, gut für dich, gut für die Firma und gut für den Kunden

Klar ist dies anekdotisch, aber es hat Wunder für mich bewirkt.Nicht sicher, ich kann Ihnen Tabellen zur Verfügung stellen, aber mein Kunde ist glücklich und das ist das Endziel.

Answer 5

Nun, es gibt einige große Unternehmen, die Sie benötigen Unit-Tests zu verwenden, aber wenn Sie sind ein kleines Unternehmen, warum imitieren großen?

Für mich, als ich vor vielen Jahren mit Komponententests begann, (heute verwenden wir meistens behavior Modell) war es, weil ich den ganzen Weg in einer Anwendung nicht kontrollieren konnte.

Ich wurde verwendet, um zuerst Programmierung und eine REPL, also wenn ich Unit Test (One Test für jede Funktion) bekam es war wie eine REPL zu Sprachen, die sehr viel kompilieren bringen. Es brachte den Spaß zurück zu jeder Codezeile, die ich schrieb. Ich fühlte Gott. Ich mochte es. Ich brauchte keinen Bericht, um mir zu sagen, dass ich besser Code schneller geschrieben habe. Mein Chef brauchte keinen Bericht, um zu bemerken, dass wir, weil wir verrückte Sachen machten, nie einen Termin verpasst haben. Mein Chef brauchte keinen Bericht, um zu bemerken, dass die Anzahl der "normalen" Bugs von (zu vielen) auf fast Null fällt, weil dieser sehr seltsame Code nicht produktiv ist.

Wie ein anderes Poster bereits geschrieben hat, verwenden Sie TDD nicht zum Testen (verifizieren). Sie schreiben es, um die Spezifikation, das Verhalten der Einheit (Objekt, Modul, Funktion, Klasse, Server, Cluster) zu erfassen.

Es gibt viele Misserfolge und Erfolgsgeschichten von Wechsel zu einem anderen Modell der Entwicklung von Software in vielen Unternehmen.

Ich habe gerade angefangen, es zu benutzen, wenn ich etwas Neues zu schreiben hatte. Es gibt ein altes Sprichwort, das etwas hart geht für mich auf Englisch zu übersetzen, aber:

Beginnen Sie mit etwas so einfach, dass Sie bemerken nicht, dass Sie es tun. Wenn Sie für einen Marathon trainieren, beginnen Sie 9 Meter zu laufen und 1 Meter laufen, wiederholen.

Answer 6

"Ich muss die anderen Programmierer und, noch wichtiger, die Bean-Counter im Management überzeugen, dass die ganze zusätzliche Zeit, die für das Erlernen des Test-Frameworks, das Schreiben von Tests, das Aktualisieren usw. aufgewendet wird. und dann einige. "

Warum?

Warum nicht einfach, leise und diskret. Sie müssen nicht alles auf einmal machen. Sie können dies in kleinen Stücken tun.

Das Rahmenlernen dauert sehr wenig Zeit.

Einen Test schreiben, nur einen, braucht sehr wenig Zeit.

Ohne Komponententests haben Sie nur ein gewisses Vertrauen in Ihre Software. Mit einem Unit-Test haben Sie immer noch Ihr Vertrauen und den Beweis, dass mindestens ein Test bestanden hat.

Das ist alles was es braucht. Niemand muss wissen, dass du es tust. Mach es einfach.

Answer 7

Hier ist eine tolle und unterhaltsame Lektüre eines Mannes, der seine Firma von innen verändert. Es ist nicht auf TDD beschränkt. http://jamesshore.com/Change-Diary/ Beachten Sie, dass er die "Counter" nicht lange überredet hat und stattdessen "Guerillataktiken" gemacht hat.

Answer 8

Ich habe einen Satz von Datenpunkten dafür - von einer Erfahrung, die mich auf Unit Tests verkauft.

Vor vielen Monden war ich ein frisch graduierter Absolvent, der an einem großen VB6-Projekt arbeitete und Gelegenheit hatte, eine große Menge gespeicherten Code zu schreiben. Von dem Subsystem, das ich schrieb, machte es ungefähr 1/4 der gesamten Codebasis aus - ungefähr 13.000 LOC von 50K oder so.

Ich schrieb eine Reihe von Komponententests für die gespeicherten Prozeduren, aber Unit Test VB6 UI-Code ist nicht wirklich ohne Werkzeuge wie Rational Robot machbar; zumindest war es damals nicht.

Die Statistiken von QA auf dem Stück waren, dass etwa 40 oder 50 Defekte auf das gesamte Teilsystem erhoben wurden, von denen zwei aus den gespeicherten Prozeduren entstanden. Das ist ein Fehler pro 6.500 Zeilen Code vs 1 pro 1.000-1.200 oder so über das ganze Stück. Bedenken Sie auch, dass etwa 2/3 des VB6-Codes Standardcode für die Fehlerbehandlung und -protokollierung war, der in allen Prozeduren identisch ist.

Ohne zu viel Handwaving können Sie mindestens eine Größenordnung der Verbesserung der Fehlerraten zu den Unit-Tests schreiben.

Answer 9

Mehr über TDD als streng Unit-Tests, hier ist ein Link zu der Realizing quality improvement through test driven development: results and experiences of four industrial teams Papier, von Nagappan, E. Michael Maximilien, Thirumalesh Bhat und Laurie Williams. Papier veröffentlicht von Microsoft Empirical Software Engineering and Measurement (ESM) Gruppe und bereits hier erwähnt.

Das Team fand heraus, dass die TDD-Teams Code produzierten, der zwischen 60% und 90% Prozent besser ist (in Bezug auf die Defektdichte) als Nicht-TDD-Teams. Jedoch TDD Teams nahmen zwischen 15% und 35% länger, um ihre Projekte abzuschließen.

Answer 10

Wenn Sie Beweise gegen Unit-Tests auch Interesse hier ist eine gut recherchiert und durchdachten Artikel:

Why Most Unit Testing is Waste By James O Coplien (lean and agile guru)

Answer 11

nur mehr Informationen zu diesen Antworten hinzuzufügen, gibt es zwei Meta-Analyse-Ressourcen, die

Einleitung Gastherausgeber: kann die Produktivität & Qualität Auswirkungen auf die akademischen und industriellen Hintergrund herauszufinden helfen out TDD-The Art of Fearless Programmierung [link]

Alle Forscher scheinen zuzustimmen, dass TDD einen besseren Fokus auf die Aufgaben und die Testabdeckung fördert. Die bloße Tatsache von mehr Tests nicht unbedingt bedeuten, dass Software-Qualität wird besser, aber die erhöhte Programmierer Aufmerksamkeit auf Test-Design ist dennoch ermutigend. Wenn wir betrachten Tests als Stichproben eine sehr große Population von Potenzial Verhaltensweisen, bedeuten mehr Tests eine gründlichere Probe. In dem Maße, wie jeder Test ein wichtiges Problem finden kann, das keiner der anderen finden kann, sind die Tests nützlich, besonders wenn Sie sie billig betreiben können.

Tabelle 1. Eine Zusammenfassung ausgewählter empirischer Studien von Test-Driven Entwicklung: Teilnehmer aus der Industrie *

Tabelle 2. Eine Zusammenfassung ausgewählter empirischer Studien von TDD: akademisch Teilnehmer *

Auswirkungen von Test Driv en-Entwicklung für Außen Qualität und Produktivität: Ein Meta-Analyse [link]

Abstract:

Dieses Papier bietet eine systematische Meta-Analyse von 27 Studien, die die Auswirkungen der Testgetriebene Entwicklung (TDD untersuchen ) auf externe Code Qualität und Produktivität.

Die Ergebnisse zeigen, dass TDD im Allgemeinen einen geringen positiven Effekt auf die Qualität, aber wenig oder keinen erkennbaren Effekt auf die Produktivität hat. Subgruppenanalyse hat jedoch gefunden, sowohl die Qualitätsverbesserung als auch die Produktivitätseinbuße, die in industriellen Studien im Vergleich zu akademischen Studien viel größer sind. Ein größerer Rückgang der Produktivität wurde in Studien festgestellt, in denen der Unterschied im Testaufwand zwischen dem TDD und dem Prozess der Kontrollgruppe signifikant war. Eine größere Verbesserung in der Qualität war auch in den akademischen Studien gefunden, wenn der Unterschied im Testaufwand wesentlich ist; Aufgrund fehlender Daten konnte jedoch keine Schlussfolgerung bezüglich der industriellen Studien gezogen werden.

Schließlich wird der Einfluss von Entwicklern Erfahrung und Aufgaben Größe als Moderatorvariablen war untersucht und eine statistisch signifikante positive Korrelation war zwischen Aufgabe und Größe der Größe der Verbesserung der Qualität gefunden.