Exceptional Behaviors: How Frequently Are They Tested?
Diese Arbeit präsentiert eine empirische Studie von 25 Python-Systemen, die aufzeigt, dass zwar 21,4 % der ausgeführten Methoden Ausnahmen auslösen, diese Ausnahmebehaviors jedoch häufig beansprucht werden (Median 1 von 10 Aufrufen), aber dennoch oft ungetestet bleiben, was Empfehlungen für verbesserte Testwerkzeuge und eine Neubewertung der Seltenheit von Ausnahme auslösenden Szenarien nach sich zieht.
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 Chefkoch, der ein geschäftiges Restaurant leitet. Die meiste Zeit kochen Sie perfekte Mahlzeiten für glückliche Kunden (dies ist das normale Verhalten). Aber manchmal geht etwas schief: Der Ofen geht kaputt, ein Kunde bestellt eine Zutat, die Sie nicht vorrätig haben, oder eine Lieferung verspätet sich (dies sind Ausnahmen).
In der Welt der Computerprogrammierung werden diese „Dinge, die schiefgehen“ als Exceptions (Ausnahmen) bezeichnet. Entwickler schreiben speziellen Code, um diese Fehler abzufangen und sie kontrolliert zu handhaben, damit nicht das ganze Restaurant abbrennt.
Dieses Papier ist wie ein Team von Lebensmittelinspektoren, die 25 verschiedene, reale Restaurants (Softwaresysteme) besucht haben, um zu sehen, wie oft das Personal tatsächlich das Handeln bei diesen Katastrophen während ihrer täglichen Übungen (Test-Suites) geübt hat.
Hier ist das, was sie herausgefunden haben, einfach aufgeschlüsselt:
1. Die „Übungen“ vs. die „Realität“
Die Inspektoren fanden heraus, dass die Köche (Entwickler) zwar sehr gut darin sind, das Kochen der perfekten Mahlzeit zu üben, aber selten üben, was zu tun ist, wenn der Ofen Feuer fängt.
- Die Statistik: Von jeweils 100 Kochstationen (Methoden), die sie überprüften, stießen nur etwa 21 während der Übungen tatsächlich auf ein Problem.
- Die Analogie: Es ist wie eine Feuerübung, bei der 79 von 100 Personen niemals einmal so tun, als würde der Feueralarm schrillen. Sie kochen einfach weiter.
2. Wie oft passieren Fehler tatsächlich?
Für die Stationen, die ein Problem erlebten, untersuchten die Inspektoren, wie oft dieser Fehler auftrat.
- Die Statistik: Im Durchschnitt, für eine Station, die ein Problem haben kann, trat das Problem nur bei jedem 10. Versuch auf, wenn sie versuchten zu kochen.
- Die Analogie: Stellen Sie sich einen Koch vor, der ein Steak anbrennen lassen kann. Wenn er 100 Steaks kocht, verbrennt er nur 10 davon. Die anderen 90 sind perfekt. Meistens ist das „Anbrennen“ ein seltenes Ereignis.
3. Die „seltenen“ vs. die „häufigen“ Katastrophen
Die Inspektoren bemerkten zwei sehr unterschiedliche Arten von „katastrophenanfälligen“ Stationen:
- Die „seltenen“ Katastrophen (80 % der Fälle): Die meisten Stationen, die ein Problem haben können, tun dies fast nie. Zum Beispiel könnte eine Station die Regel haben: „Wenn ein Kunde einen ‚Einhorn-Burger‘ bestellt, wirf einen Wutanfall an.“ Aber da niemals jemand einen Einhorn-Burger bestellt, muss der Koch auch nie einen Wutanfall bekommen.
- Die „häufigen“ Katastastrophen (20 % der Fälle): Einige Stationen fallen die ganze Zeit aus. Stellen Sie sich eine Station vor, die sagt: „Wenn ein Kunde eine ‚glutenfreie Pizza‘ bestellt, wirf einen Wutanfall an.“ Wenn 90 % der Kunden eine glutenfreie Pizza bestellen, wirft dieser Koch ständig Wutanfälle an.
- Der Twist: In diesen seltenen Fällen ist das „Anfall-Werfen“ (das Auslösen einer Exception) tatsächlich die normale Art und Weise, wie die Station arbeitet! Das Papier argumentiert, dass nur weil ein Computercode einen Fehler auslöst, das nicht immer bedeutet, dass etwas „kaputt“ oder „abnormal“ ist. Manchmal ist der Fehler das erwartete Ergebnis.
4. Die „versteckten“ Fehler
Eine der interessantesten Erkenntnisse betrifft Fehler, die passieren, aber vom „Manager“ (der Test-Suite) nie gesehen werden.
- Die Analogie: Stellen Sie sich vor, ein Sous-Chef lässt einen Teller fallen, aber der Chefkoch trägt Noise-Cancelling-Kopfhörer und hört es nicht. Der Sous-Chef hebt den Teller schnell auf und kocht einfach weiter. Der Manager denkt, alles sei in Ordnung, aber der Teller wurde tatsächlich fallen gelassen.
- Die Realität: Die Studie fand heraus, dass viele Fehler im Code passieren, sofort von einem Sicherheitsnetz (einem
try/except-Block) abgefangen werden und niemals die oberste Ebene der Tests erreichen. Die Tests wissen nicht, dass diese Fehler aufgetreten sind, obwohl sie es taten.
5. Die „teuren“ Sicherheitsnetze
Schließlich weist das Papier auf eine Energieverschwendung hin.
- Die Analogie: Stellen Sie sich vor, ein Koch hält einen riesigen, schweren, teuren Feuerlöscher direkt neben dem Herd bereit, nur für den Fall. Aber er benutzt ihn nur einmal im Jahr. Er ist schwer zu tragen und nimmt Platz weg.
- Der Vorschlag: Das Papier schlägt vor, dass es für die Stationen, an denen Fehler sehr selten auftreten (wie im Beispiel mit dem „Einhorn-Burger“), besser sein könnte, einfach zu prüfen, ob die Bestellung gültig ist, bevor gekocht wird, anstatt den schweren Feuerlöscher bereit zu halten. Das macht die Küche schneller und effizienter.
Zusammenfassung
Das Papier sagt uns:
- Die meisten Fehler sind selten: Wir testen die „Was-wäre-wenn-es-schiefgeht“-Szenarien selten, weil sie im echten Leben nicht oft vorkommen.
- Manche Fehler sind normal: Für bestimmte Aufgaben ist das „Scheitern“ tatsächlich die Standardweise, wie das System arbeitet.
- Wir übersehen versteckte Fehler: Viele Fehler passieren und werden sofort behoben, sodass unsere Tests gar nicht wissen, dass sie stattgefunden haben.
- Wir können effizienter sein: Manchmal nutzen wir schwere, teure Sicherheitsmechanismen für Probleme, die fast nie auftreten, und wir könnten sie durch einfachere Prüfungen ersetzen.
Die Autoren schlagen vor, dass wir bessere Werkzeuge benötigen, um Köchen (Entwicklern) dabei zu helfen, jene seltenen Katastrophenszenarien zu üben und herauszufinden, welche Sicherheitsnetze zu schwer zum Tragen sind.
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.