Test Behaviors, Not Methods! Detecting Tests Obsessed by Methods
Dieses Paper schlägt ein neuartiges Test-Smell namens „Test Obsessed by Method“ vor, welches Tests identifiziert, die mehrere Ausführungspfade einer einzelnen Produktionsmethode abdecken, und dessen Detektion durch eine empirische Studie über die Python-Standardbibliothek validiert, die zeigt, dass solche Tests oft mehrere Verhaltensweisen verifizieren und in fokussiertere Einheiten refaktoriert werden können.
Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen
Stellen Sie sich vor, Sie sind ein Küchenchef, der ein Degustationsmenü für einen Food-Kritiker vorbereitet. Die goldene Regel der guten Küche lautet: Servieren Sie pro Gericht genau einen ausgeprägten Geschmack. Wenn Sie ein einzelnes Tellergericht servieren, das aus einem Steak, einem Stück Kuchen und einer Kugel Eis besteht, das alles wild vermischt ist, wird der Kritiker verwirrt sein. Er kann nicht feststellen, ob das Steak untergar, der Kuchen zu süß oder das Eis am Schmelzen ist. Wenn etwas schiefgeht, weiß er nicht, an welchem Teil der Mahlzeit er die Schuld suchen soll.
In der Welt der Software sind „Gerichte“ Tests und „Geschmacksrichtungen“ sind Verhaltensweisen (das, was die Software tun soll).
Dieses Paper mit dem Titel „Test Behaviors, Not Methods!“ argumentiert, dass viele Software-Tests derzeit wie dieses chaotische, gemischte Tellergericht serviert werden. Die Autoren Andre Hora und Andy Zaidman führen eine neue Methode ein, um diese verwirrenden Tests zu identifizieren, die sie als „Tests Obsessed by Methods“ (von Methoden besessene Tests) bezeichnen.
Hier ist die Aufschlüsselung ihrer Entdeckung unter Verwendung einfacher Analogien:
1. Der alte Weg: Die Zutaten zählen
Früher versuchten Experten, diese chaotischen Tests zu finden, indem sie einfach zählten, wie oft ein Test den Code „berührte“. Sie dachten: „Wenn ein Test den Produktionscode 3 oder mehr Mal aufruft, tut er wahrscheinlich zu viel.“
Die Autoren nennen diesen Geruch ein „Eager Test“ (eifriger Test). Sie fanden jedoch heraus, dass diese Methode der Beurteilung einer Mahlzeit allein durch das Zählen der verwendeten Löffel gleicht. Es ist ungenau. Ein Test kann eine Funktion viele Male aufrufen, nur um eine Szene vorzubereiten, ohne tatsächlich verschiedene Geschmacksrichtungen zu testen. Es ist eine unbeholfte Art, das Problem zu finden.
2. Die neue Idee: Den Film anschauen (Laufzeitanalyse)
Anstatt nur Löffel zu zählen, schlagen die Autoren vor, den Film des Tests zu beobachten, während er abläuft. Sie schlagen eine neue Regel vor: Wenn ein einzelner Test einen Teil des Codes dazu zwingt, mehrere verschiedene „Wege“ (Pfade) zu nehmen, um das Ziel zu erreichen, dann ist dieser Test „besessen“.
Betrachten Sie eine Produktionsmethode (ein Stück Code) als ein Labyrinth.
- Guter Test: Sie schicken einen Entdecker in das Labyrinth, um zu prüfen, ob die linke Tür funktioniert. Dann schicken Sie einen zweiten Entdecker, um zu prüfen, ob die rechte Tür funktioniert. Klar und fokussiert.
- Besessener Test: Sie schicken einen Entdecker, der durch die linke Tür läuft, dann zurückkehrt, durch die rechte Tür läuft und dann auch noch den geheimen Tunnel ausprobiert – alles in einem Rutsch.
Die Autoren nennen dies „Test Obsessed by Method“. Der Test ist „gierig“, weil er versucht, jeden möglichen Pfad eines einzelnen Labyrinths in einem Durchgang abzudecken, anstatt die Aufgabe aufzuteilen.
3. Das Experiment: Überprüfung der Python-Bibliothek
Um zu sehen, ob diese „Besessenheit“ ein echtes Problem darstellt, haben die Autoren eine Schatzsuche in der Python Standard Library (einer riesigen Sammlung von vorinstalliertem Code, der von Millionen von Entwicklern genutzt wird) durchgeführt.
Sie untersuchten 2.054 Tests. Hier ist das, was sie fanden:
- Die Suche: Sie fanden 44 Tests, die „besessen“ waren. Diese Tests versuchten, mehrere verschiedene Ergebnisse einer einzigen Funktion in einem Durchgang zu prüfen.
- Die Verbreitung: Diese chaotischen Tests wurden in 11 von 12 verschiedenen Bibliotheken gefunden, die sie überprüft haben. Es handelt sich nicht um einen seltenen Fehler; es ist eine verbreitete Gewohnheit.
- Die Lösung: Im Durchschnitt versuchten diese 44 chaotischen Tests tatsächlich zwei verschiedene Aufgaben zu erledigen. Wenn man sie aufgeteilt hätte, könnten aus diesen 44 Tests 118 saubere, fokussierte Tests geworden sein.
- Der „Aha-Moment“: In etwa 23 % dieser chaotischen Tests hatten die Programmierer tatsächlich Kommentare geschrieben, in denen sie zugaben: „Hey, wir testen hier zwei verschiedene Dinge!“ Sie wussten, dass es unordentlich war, machten es aber trotzdem.
4. Warum ist das wichtig?
Die Autoren argumentieren, dass wenn ein Test versucht, zu viele Pfade gleichzeitig abzudecken:
- Es ist schwer zu verstehen: Wie bei dem gemischten Teller kann man nicht sagen, welchen Geschmack man gerade schmeckt.
- Es ist fragil: Wenn Sie den Code für die „linke Tür“ ändern, könnten Sie versehentlich den Test für die „rechte Tür“ brechen, obwohl diese nicht miteinander verwandt sind.
- Es ist schwer zu beheben: Wenn ein Test fehlschlägt, wissen Sie nicht, welches spezifische Verhalten kaputtgegangen ist.
Das Fazsit
Das Paper behauptet nicht, jedes Testing-Problem lösen zu wollen. Stattdessen bietet es ein neues, schärferes Werkzeug (unter Verwendung von Laufzeitanalyse anstelle von bloßem Zählen), um Tests aufzuspüren, die versuchen, zu viel mit einem einzigen Stück Code zu machen.
Sie schlagen vor, dass ein Test aufgeteilt werden sollte, wenn er eine Funktion dazu zwingt, mehrere verschiedene Pfade zu nehmen. Genau wie ein Koch das Steak, den Kuchen und das Eis auf separaten Tellern servieren sollte, sollte ein Entwickler separate Tests für jedes unterscheidbare Verhalten schreiben.
Kurz gesagt: Seien Sie nicht gierig mit Ihren Tests. Testen Sie ein Verhalten, einen Pfad, einen Geschmack nach dem anderen.
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.