Ein neuer Name für Unit-Tests [geschlossen]

9

Ich habe Unit-Tests nie gemocht. Ich dachte immer, es würde meinen Arbeitsaufwand erhöhen.
Es stellt sich heraus, dass dies nur in Bezug auf die tatsächliche Anzahl der von Ihnen geschriebenen Codezeilen zutrifft. Darüber hinaus wird dies vollständig durch die Zunahme der Anzahl nützlicher Codezeilen ausgeglichen, die Sie mit Tests und testgetriebener Entwicklung in einer Stunde schreiben können.

Jetzt liebe ich Unit-Tests, da sie mir erlauben, nützlichen Code zu schreiben, der ziemlich oft beim ersten Mal funktioniert! (auf Holz klopfen)

Ich habe festgestellt, dass Menschen nur ungern Unit-Tests durchführen oder ein Projekt mit testgetriebener Entwicklung starten, wenn sie sich unter strengen Zeitplänen befinden oder in einer Umgebung, in der andere dies nicht tun, also nicht. Ein bisschen wie eine kulturelle Weigerung, es überhaupt zu versuchen.

Ich denke, eines der mächtigsten Dinge beim Testen von Einheiten ist das Vertrauen, das Sie erhalten, um Refactoring durchzuführen. Es gibt auch neue Hoffnung, dass ich meinen Code jemand anderem geben kann, um ihn zu überarbeiten / zu verbessern, und wenn meine Komponententests immer noch funktionieren, kann ich die neue Version der Bibliothek, die sie geändert haben, so ziemlich ohne Angst verwenden.

Es ist dieser letzte Aspekt des Unit-Tests, der meiner Meinung nach einen neuen Namen braucht. Der Unit-Test ist eher ein Vertrag darüber, was dieser Code jetzt und in Zukunft tun soll.
Wenn ich das Wort Testen höre, denke ich an Mäuse in Käfigen, an denen mehrere Experimente durchgeführt wurden, um die Wirksamkeit einer Verbindung festzustellen. Dies ist nicht das, was Unit-Tests sind. Wir probieren keinen anderen Code aus, um herauszufinden, was der effektivste Ansatz ist. Wir definieren, welche Ausgaben wir mit welchen Eingaben erwarten. Im Beispiel der Mäuse ähneln Unit-Tests eher den Definitionen der Funktionsweise des Universums als den an den Mäusen durchgeführten Experimenten.

Bin ich auf dem Sprung oder sieht jemand diese Weigerung, Tests durchzuführen, und glaubt er, dass dies ein ähnlicher Grund ist, warum er es nicht tun möchte?
Welche Gründe geben Sie / andere an, nicht zu testen?
Was denkst du, sind ihre Motive darin, keine Unit-Tests durchzuführen?

Und als neuer Name für Unit-Tests, die einige der Einwände überwinden könnten, wie wäre es mit jContract? (Ein bisschen Java-zentriert, wie ich weiß :) oder Unit Contracts?

tdd unit-testing Wille
quelle
14
Was ist in einem Namen? das, was wir eine Rose nennen, würde bei jedem anderen Namen so süß riechen; - Shakespeare, Romeo und Julia, um 1600
Steven A. Lowe
8
Ich weiß nicht, ob Sie auf Crack sind. Ich habe noch nie versucht zu knacken oder du zu sein.
Tim Post
1
Ich denke, dass Ideen hauptsächlich aufgrund der damit verbundenen Ideen und Einstellungen an Wörter gebunden werden, nicht aufgrund der Wörter. Ich erinnere mich, dass ich herausgefunden habe, dass die Spastics Society ihren Namen in Scope geändert hat, weil der Name mit Vorurteilen verbunden war. Ich erinnere mich, weil es erklärte, warum ich Kinder gehört hatte, die sich früher an diesem Tag "Scopey" nannten. Wenn Sie die Einstellung ändern möchten, konzentrieren Sie sich auf die Einstellung, nicht auf den Namen - die Besessenheit über den Namen ist nur Zeitverschwendung.
Steve314
2
Design by Contract: en.wikipedia.org/wiki/Design_by_contract Hat eine bestimmte Konotation und Unit-Tests, nicht wahr? Wenn ich etwas mit Vertrag im Namen sehe, ist das (und die Schnittstellen) das, was mein Gehirn damit verbindet.
Berin Loritsch
@ Steve314 Scopey. Mag ich. :) Ich denke in diesem Fall ist das Wort Testen bereits definiert, und daher wäre es besser, Unit-Tests in einen undefinierten Begriff umzubenennen. Vertrag kann es nicht wegen der erwähnten "Schnittstelle" sein. Wie wäre es mit "bessere Programme schneller erstellen" oder CBPF.
Will

Antworten:

5

Bin ich auf dem Sprung oder sieht jemand diese Weigerung, Tests durchzuführen, und glaubt er, dass dies ein ähnlicher Grund ist, warum er es nicht tun möchte?

Das Wort Testen in Unit-Tests lässt die Leute denken, dass dies Integrationstests oder Benutzeroberflächentests sind, da dies die einzige Art von Tests ist, die sie jemals durchgeführt haben. Es ist wie Java in Javascript zu setzen.

Wenn etwas einen schlechten Ruf hat und das Denken der Leute beeinflusst, spricht man von einem Rahmenfehler. Rahmenfehler sind in der Regel oberflächlich - Menschen sind schlau und können alle Arten von schlechten Namen und Metaphern durchschauen.

Welche Gründe geben Sie / andere an, nicht zu testen?

Abhängigkeiten, die schwer zu verspotten / zu fälschen sind /

Was denkst du, sind ihre Motive darin, keine Unit-Tests durchzuführen?

Unit-Tests haben eine bescheidene Anzahl von Konzepten und es muss eine nicht triviale Menge an Arbeit erledigt werden, bevor man aufhört, schlechte Unit-Tests zu schreiben und gute schreibt. Wenn die Leute besser erklären können, was Unit-Tests sind, wird die Akzeptanz zunehmen. Nach meiner Erfahrung haben Unit-Tests einen nahezu magischen Effekt auf Produktivität und Codequalität. Aber so hat es nicht angefangen. Ich habe ursprünglich Unit-Testing-Frameworks verwendet, um Integrationstests bequem zu schreiben.

MatthewMartin
quelle
Tolle Punkte. Der Versuch zu erklären, warum Sie eine einfache get-Methode "testen" würden, ist schwierig. Es ist vertraglich wichtig für die Stabilität des gesamten restlichen Codes, dass die get-Methode immer das zurückgibt, was Sie erwarten. Dies ist ein einfacheres Argument
Will
3

Das Konzept einer Namensänderung wurde bereits umgesetzt. Es heißt Behavior Driven Development . Die Leute, die sich das ausgedacht haben, bemerkten viele der gleichen Argumente und die unnatürliche Fähigkeit, etwas zu testen, das noch nicht erstellt wurde. Stattdessen besteht ihr Konzept darin, eine ausführbare Spezifikation zu schreiben (worum es bei TDD sowieso wirklich geht).

Ich habe den gleichen Pushback bemerkt. Mir ist auch aufgefallen, dass einige Leute einfach nicht wissen, wie man Unit-Tests schreibt. Sie fehlen in den wissenschaftlichen Prozessdisziplinen und verwenden lediglich das Unit-Test-Framework, um alles miteinander zu verbinden und den Debugger zu starten. Kurz gesagt, sie verbessern die Nutzung ihrer Zeit nicht wirklich. Ich kann Ihnen nicht sagen, wie viele Unit-Tests ich gesehen habe, die mehrere zehn Zeilen lang waren (über 30 Zeilen) und keine einzige Aussage. Wenn ich das sehe, weiß ich, dass es Zeit ist, mit dem Entwickler zusammenzuarbeiten und ihm beizubringen, was eine Behauptung ist und wie man Unit-Tests schreibt, die tatsächlich testen.

Berin Loritsch
quelle
2
Die ausführbare Spezifikation liegt wahrscheinlich vor TDD / BDD / Agile / XP. Es könnte so alt sein wie CMMI. Früher war es eine Modeerscheinung mit UML, als die Leute dachten, UML sei die Sprache für das Schreiben von ES.
Rwong
BDD ist wie TDD ein Testansatz, keine Art von Test (funktional v Integration v Einheit v Akzeptanz). Der Autor fragt speziell nach einem "besseren" Namen für Unit-Tests.
Ybakos
0

Verträge werden hier in den meisten Fällen als "Schnittstellen" bezeichnet. Unit-Tests garantieren nicht die Verträge an sich, da Sie auch die Tests ändern können, sodass Sie nicht wissen, dass Sie die neue Version der Bibliothek verwenden können, nur weil die Bibliothek getestet wird. Sie müssen den Code testen, der auch die Bibliothek verwendet. Das unterscheidet sich nicht von anderen Unit-Tests, daher verstehe ich nicht, warum dies einen neuen Namen erfordern würde.

Ich denke, wie Sie, dass die meisten Leute, die Tests nur ungern durchführen, dies tun, weil sie denken, dass es mehr Arbeit und keinen Nutzen ist.

Lennart Regebro
quelle
0

Ich werde Ihnen sagen, warum ich TDD nicht mag: Es liegt nicht daran, dass ich den Wert darin nicht sehen oder die Vorteile einer Testsuite erkennen kann, die ich ausführen kann, um meinen gesamten Code nach jeder Änderung zu überprüfen.

Es ist, weil ich es nicht brauche. Ich bin ein ziemlich altmodischer Entwickler, als ich ein Junge war, hatten wir keine ausgefallenen integrierten Debugger mit dem Bearbeiten und Weiterschreiben von Code, und eine Kompilierung konnte ziemlich lange dauern, sodass wir Dinge besorgen mussten richtig, gleich von Anfang an. Angesichts eines solchen Trainings sehe ich nicht wirklich, dass das Schreiben einer Menge Unit-Tests mich produktiver oder meinen Code fehlerfreier machen würde.

Ich teste meinen Code, aber wie immer war dies eher die ganze Sache als die einzelnen Teile. Vielleicht habe ich "Unit-Tests", aber sie sind eher grobkörnig.

Das ist also mein Grund. Ich kann nicht sehen, dass ich es tun muss. Der Code, den ich produziere, ist gut genug. Wenn dies der Fall ist, warum sollte ich meine Prozesse ändern, um etwas zu reparieren, das nicht kaputt ist?

gbjbaanb
quelle
Sie müssen dann sehr einfachen Code schreiben. Die Anzahl der erreichbaren Zustände in den meisten modernen Systemen bedeutet, dass das Durchführen von End-to-End-Tests die Lebensdauer des Universums in Anspruch nehmen würde. Das Testen von zwei Teilen mit jeweils 4 Bit Status erfordert 16 Fälle, um sie zu testen, oder insgesamt 32 Testfälle. In ein End-to-End-System umgewandelt, erhalten Sie 8 Bit Status oder 256 Testfälle, um alle Status abzudecken. Persönlich würde ich lieber 1/8 der Arbeit machen.
Pete Kirkham
1
@PeteKirkham Die Konsequenz daraus ist, dass Sie eine große Anzahl von Komponententests schreiben und dann auch die Integrationstests schreiben müssen, um sicherzustellen, dass die Einheit immer noch miteinander funktioniert. Die Orte, an denen ich arbeitete und die Unit-Tests sehr mochten, verbrachten so viel Zeit damit, sie zu schreiben (und zu warten), dass sie die Codebasis in den Schatten stellten, und der Arbeitsaufwand war im Vergleich zu dem, was ich außerhalb dieser Umgebung erreiche, winzig. Nichts ist ein Wundermittel. Ich empfehle, einen pragmatischeren Ansatz zu finden, mit dem Sie sowohl die wichtigen Teile testen als auch etwas produzieren können.
Gbjbaanb