Unit-Tests klingen für mich großartig, aber ich bin mir nicht sicher, ob ich Zeit damit verbringen sollte, sie wirklich zu lernen, es sei denn, ich kann andere davon überzeugen, dass dies von erheblichem Wert ist. Ich muss die anderen Programmierer und vor allem die Bean-Counter im Management davon überzeugen, dass sich die zusätzliche Zeit, die für das Erlernen des Test-Frameworks, das Schreiben von Tests, das Aktualisieren usw. aufgewendet wird, amortisiert.

Welchen Beweis gibt es? Hat jemand tatsächlich dieselbe Software mit zwei separaten Teams entwickelt, eines mit Unit-Tests und das andere nicht, und die Ergebnisse verglichen? Ich bezweifle das. Soll ich es nur mit "Nachschlagen im Internet, alle reden darüber, also muss es das Richtige sein" rechtfertigen?

Wo sind die harten Beweise, die die Laien davon überzeugen, dass Unit-Tests die Mühe wert sind?

Ja. Dies ist ein Link zu einer Studie von Boby George und Laurie Williams bei NCST und einer anderen von Nagappan et al. Ich bin sicher, es gibt noch mehr. Dr. Williams- Veröffentlichungen zu Tests bieten möglicherweise einen guten Ausgangspunkt, um sie zu finden.

[EDIT] Die beiden obigen Veröffentlichungen beziehen sich speziell auf TDD und zeigen eine 15-35% ige Verlängerung der anfänglichen Entwicklungszeit nach der Einführung von TDD, aber eine 40-90% ige Abnahme der Defekte vor der Freisetzung. Wenn Sie nicht auf die Volltextversionen zugreifen können, empfehle ich die Verwendung von Google Scholar , um festzustellen, ob Sie eine öffentlich verfügbare Version finden.

"Ich muss die anderen Programmierer und vor allem die Bean-Counter im Management davon überzeugen, dass sich all die zusätzliche Zeit, die für das Erlernen des Test-Frameworks, das Schreiben von Tests, das Aktualisieren usw. aufgewendet wird, amortisiert. ""

Warum?

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

Das Framework-Lernen nimmt sehr wenig Zeit in Anspruch.

Das Schreiben eines Tests, nur eines, nimmt sehr wenig Zeit in Anspruch.

Ohne Unit-Tests haben Sie nur ein gewisses Vertrauen in Ihre Software. Mit einem Komponententest haben Sie immer noch Ihr Vertrauen und den Nachweis, dass mindestens ein Test bestanden wurde.

Das ist alles was es braucht. Niemand muss wissen, dass Sie es tun. Mach es einfach.

Ich gehe das anders an:

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

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

Vielleicht gibt es im akademischen Bereich Beweise, aber ich habe noch nie in der Geschäftswelt gearbeitet, wo jemand für einen solchen Test bezahlen würde. Ich kann Ihnen jedoch sagen, dass es für mich gut funktioniert hat, wenig Zeit gebraucht hat, um sich an das Test-Framework zu gewöhnen, und das Schreiben von Tests hat mich wirklich über meine Anforderungen und das Design nachdenken lassen, weit mehr als jemals zuvor, als ich in Teams gearbeitet habe schrieb keine Tests.

Hier zahlt es sich aus: 1) Sie haben Vertrauen in Ihren Code und 2) Sie haben Probleme früher als sonst. Der QS-Mitarbeiter hat nicht gesagt: "Hey, Sie haben sich nicht die Mühe gemacht, die xyz () -Funktion zu überprüfen, oder? Er kann diesen Fehler nicht finden, weil Sie ihn vor einem Monat gefunden haben. Das ist gut für er, gut für Sie, gut für das Unternehmen und gut für den Kunden.

Das ist natürlich anekdotisch, aber es hat Wunder für mich gewirkt. Ich bin nicht sicher, ob ich Ihnen Tabellenkalkulationen zur Verfügung stellen kann, aber mein Kunde ist zufrieden und das ist das Endziel.

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

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

Auch wenn dies nicht Ihre Frage ist, frage ich mich, ob es wirklich der einfachste Weg ist, Fragen zu beantworten (und Beweise zu bringen, die durch andere Berichte in Frage gestellt werden könnten), die möglicherweise falsch gestellt werden. Selbst wenn Sie harte Beweise für Ihren Fall finden, könnte jemand anderes harte Beweise dafür finden.

Ist es die Aufgabe der Bohnenzähler, zu bestimmen, wie die technischen Mitarbeiter arbeiten sollen? Bieten sie in allen Fällen die billigsten Werkzeuge an, weil sie glauben, dass Sie keine teureren benötigen?

Dieses Argument wird entweder aufgrund des Vertrauens (einer der Grundwerte agiler Teams) gewonnen oder aufgrund der Rollenmacht der siegreichen Partei verloren. Selbst wenn die TDD-Befürworter aufgrund ihrer Rollenstärke gewinnen würden, würde ich dies als verloren betrachten.

Wenn Sie auch an Beweisen gegen Unit-Tests interessiert sind, finden Sie hier einen gut recherchierten und durchdachten Artikel:

Warum die meisten Unit-Tests Verschwendung sind Von James O Coplien (schlanker und agiler Guru)

Hier geht es mehr um TDD als um reine Unit-Tests. Hier finden Sie einen Link zur Realisierung von Qualitätsverbesserungen durch testgetriebene Entwicklung: Ergebnisse und Erfahrungen von vier Industrieteams von Nagappan, E. Michael Maximilien, Thirumalesh Bhat und Laurie Williams. Artikel, der von der Microsoft Empirical Software Engineering and Measurement (ESM) -Gruppe veröffentlicht und hier bereits erwähnt wurde.

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

Hier ist eine großartige und unterhaltsame Lektüre eines Mannes, der seine Firma von innen heraus verändert. Es ist nicht auf TDD beschränkt. http://jamesshore.com/Change-Diary/ Beachten Sie, dass er die "Bohnenzähler" einige Zeit nicht überzeugt hat und stattdessen "Guerilla-Taktiken" durchgeführt hat.

Um diesen Antworten weitere Informationen hinzuzufügen, gibt es zwei Metaanalyse-Ressourcen, mit denen sich die Auswirkungen auf Produktivität und Qualität auf den akademischen und industriellen Hintergrund ermitteln lassen:

Einführung der Gastredakteure: TDD - Die Kunst der furchtlosen Programmierung [ Link ]

Alle Forscher scheinen sich einig zu sein, dass TDD eine bessere Aufgabenorientierung und Testabdeckung fördert. Die bloße Tatsache von mehr Tests bedeutet nicht unbedingt, dass die Softwarequalität besser wird, aber die erhöhte Aufmerksamkeit des Programmierers für das Testdesign ist dennoch ermutigend. Wenn wir das Testen als Stichprobe einer sehr großen Population potenzieller Verhaltensweisen betrachten, bedeuten mehr Tests eine gründlichere Stichprobe. In dem Maße, in dem jeder Test ein wichtiges Problem finden kann, das keiner der anderen finden kann, sind die Tests nützlich, insbesondere wenn Sie sie billig ausführen können.

Tabelle 1. Eine Zusammenfassung ausgewählter empirischer Studien zur testgetriebenen Entwicklung: Branchenteilnehmer *

Tabelle 2. Eine Zusammenfassung ausgewählter empirischer Studien zu TDD: akademische Teilnehmer *

Die Auswirkungen testgetriebener Entwicklung auf externe Qualität und Produktivität: Eine Metaanalyse [ Link ]

Abstrakt:

Dieses Papier bietet eine systematische Metaanalyse von 27 Studien, die die Auswirkungen der testgetriebenen Entwicklung (TDD) auf die Qualität und Produktivität des externen Codes untersuchen.

Die Ergebnisse zeigen, dass TDD im Allgemeinen einen geringen positiven Effekt auf die Qualität hat, aber nur einen geringen bis keinen erkennbaren Effekt auf die Produktivität. Die Subgruppenanalyse hat jedoch festgestellt, dass sowohl die Qualitätsverbesserung als auch der Produktivitätsabfall in Industriestudien im Vergleich zu akademischen Studien viel größer sind. Ein größerer Produktivitätsabfall wurde in Studien festgestellt, in denen der Unterschied im Testaufwand zwischen dem TDD und dem Prozess der Kontrollgruppe signifikant war. Eine größere Qualitätsverbesserung wurde auch in den akademischen Studien festgestellt, wenn der Unterschied im Testaufwand erheblich ist; Aufgrund fehlender Daten konnte jedoch keine Schlussfolgerung zu den Industriestudien gezogen werden.

Schließlich wurde der Einfluss der Entwicklererfahrung und der Aufgabengröße als Moderatorvariablen untersucht und eine statistisch signifikante positive Korrelation zwischen der Aufgabengröße und dem Ausmaß der Qualitätsverbesserung gefunden.

Nun, es gibt einige große Unternehmen, bei denen Sie Unit-Tests durchführen müssen. Wenn Sie jedoch ein kleines Unternehmen sind, warum sollten Sie große Unternehmen nachahmen?

Als ich vor vielen Jahren mit Unit-Tests begann (heute verwenden wir meistens Verhaltensmodelle ), lag das daran, dass ich nicht den gesamten Pfad in einer Anwendung steuern konnte.

Ich war es gewohnt, die erste Programmierung und eine REPL zu beenden. Als ich Unit Test (Ein Test für jede Funktion) bekam, war es, als würde ich eine REPL in Sprachen zurückbringen, in denen sehr viel kompiliert wurde. Es brachte den Spaß zurück zu jeder Codezeile, die ich schrieb. Ich fühlte Gott. Ich mochte es. Ich brauchte keinen Bericht, um zu erfahren, dass ich schneller besseren Code geschrieben habe. Mein Chef brauchte keinen Bericht, um zu bemerken, dass wir plötzlich nie eine Frist verpasst haben, weil wir verrückte Sachen gemacht haben. Mein Chef brauchte keinen Bericht, um zu bemerken, dass die Anzahl der "einfachen" Fehler aufgrund dieser sehr seltsamen Sache, unproduktiven Code zu schreiben, von (zu vielen) auf fast null sinkt.

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

Es gibt viele Misserfolge und Erfolgsgeschichten beim Wechsel zu einem anderen Modell für die 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 mir schwer ins Englische zu übersetzen ist, aber:

Beginnen Sie mit etwas so Einfachem, dass Sie nicht bemerken, dass Sie es tun. Wenn Sie für einen Marathon trainieren, gehen Sie zunächst 9 Meter und laufen Sie 1 Meter. Wiederholen Sie diesen Vorgang.

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

Bearbeiten : Wie bereits erwähnt, berichtet beispielsweise das Buch " Code Complete " über solche Studien (Absatz 20.3, "Relative Wirksamkeit von Qualitätstechniken"). Aber auch private Beratung im Beratungsbereich beweist dies.

Ich habe einen Satz Datenpunkte dafür - aus einer Erfahrung, die mich bei Unit-Tests verkauft hat.

Vor vielen Monden war ich ein frisch Absolvent, der an einem großen VB6-Projekt arbeitete, und hatte Gelegenheit, einen großen Teil des Codes für gespeicherte Prozeduren zu schreiben. Von dem Subsystem, das ich geschrieben habe, machte es ungefähr 1/4 der gesamten Codebasis aus - ungefähr 13.000 LOC von ungefähr 50.000.

Ich habe eine Reihe von Unit-Tests für die gespeicherten Prozeduren geschrieben, aber Unit-Tests für VB6-UI-Code sind ohne Tools wie Rational Robot nicht wirklich möglich. Zumindest war es damals nicht so.

Die Statistiken der Qualitätssicherung zu dem Stück ergaben, dass etwa 40 oder 50 Fehler im gesamten Teilsystem aufgetreten sind, von denen zwei aus den gespeicherten Prozeduren stammten. Das ist ein Fehler pro 6.500 Codezeilen gegenüber 1 pro 1.000 bis 1.200 im gesamten Teil. Beachten Sie auch, dass etwa 2/3 des VB6-Codes ein Boilerplate-Code für die Fehlerbehandlung und -protokollierung war, der über alle Verfahren hinweg identisch war.

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