What Do Contribution Guidelines Say About Software Testing?

Stellen Sie sich Open-Source-Softwareprojekte wie riesige, geschäftige Gemeinschaftsküchen vor. Jeder kann hineinkommen, ein Messer in die Hand nehmen und anfangen, Gemüse zu schneiden (Code schreiben), um beim Kochen eines besseren Gerichts zu helfen. Aber um die Küche am Laufen zu halten, hinterlassen die Chefköche (Projekt-Maintainer) ein Regelwerk auf der Arbeitsplatte. Dieses Regelwerk sagt den neuen Helfern, wie sie sich die Hände waschen, wo sie die Zutaten finden und wie sie ihr geschnittenes Gemüse abgeben können, ohne die Suppe zu verderben.

Dieses Papier ist wie ein Team von Forschern, das in 200 dieser berühmten Gemeinschaftsküchen (speziell jene, die die Programmiersprachen Python und JavaScript verwenden) gegangen ist, um die Regelwerke zu lesen und zu sehen, was sie tatsächlich über das Testen aussagen.

In der Welt des Kochens ist „Testen“ wie das Probieren des Gerichts, bevor es serviert wird, um sicherzustellen, dass es nicht nach Seife schmeckt. Die Forscher wollten wissen: Lehren die Regelwerke die neuen Helfer tatsächlich, wie man das Essen probiert, oder setzen sie einfach voraus, dass jeder weiß, wie man es macht?

Hier ist das, was sie herausgefunden haben, vereinfacht dargestellt:

1. Die meisten Küchen haben einen „Probierschlüssel“ (aber nicht alle)

Die Forscher fanden heraus, dass 78 % der Küchen einen speziellen Abschnitt in ihrem Regelwerk hatten, der dem Probieren (Testen) gewidmet ist.

• Wo ist er? Meistens (58 %) befindet er sich in einer Datei namens „CONTRIBUTING“ (das Hauptinstruktionshandbuch). Manchmal ist er in einer separaten, schicken Broschüre (externe Dokumentation) zu finden, und selten steht er nur auf der Hauptkarte (README).
• Die Lücke: Etwa 22 % der Küchen hatten überhaupt keine Anweisungen zum Probieren. Wenn Sie diese Küchen betreten würden, müssten Sie selbst erraten, wie Sie prüfen, ob Ihr Essen gut ist.

2. Das Ungleichgewicht bei der „Anleitung“: Ausführen vs. Schreiben

Wenn die Regelwerke über das Probieren sprachen, waren sie in einer Sache sehr gut, in einer anderen jedoch schlecht.

• Das „Wie man es ausführt“ (83,5 %): Die meisten Regelwerke sagten klar: „Hier ist der Zauberspruch (Befehl), um den ganzen Topf zu probieren.“ Es ist, als würde man sagen: „Drücke diesen Knopf, um den Geschmack zu prüfen.“
• Das „Wie man es schreibt“ (37 %): Weitaus weniger Regelwerke erklärten, wie man tatsächlich einen neuen Geschmackstest erstellt. Es ist, als würde man sagen: „Drücke den Knopf“, aber einem nicht beibringen, wie man einen neuen Löffel herstellt oder wie man erkennt, was ein „schlechter“ Geschmack ist.
• Das Ergebnis: Die Helfer wissen, wie man das vorhandene Essen prüft, aber sie müssen oft selbst raten, wie sie eigene Tests für die neuen Zutaten erstellen, die sie hinzugefügt haben.

3. Das „Testpyramiden“-Problem

In der Software gibt es verschiedene Ebenen des Testens, ähnlich wie verschiedene Arten von Geschmackstests:

• Unit-Tests (71 %): Diese sind wie das Probieren einer einzelnen Zutat (z. B. „Schmeckt diese Karotte süß?“). Die Regelwerke sprachen viel darüber.
• Integrationstests (20,5 %): Diese sind wie das Probieren, wie die Karotte und die Zwiebel zusammen im Topf funktionieren. Die Regelwerke erwähnten dies selten.
• End-to-End-Tests (15,5 %): Dies ist wie das Probieren des fertigen, voll durchgegarten Mahls, um zu sehen, ob das ganze Gericht funktioniert. Die Regelwerke sprachen gutestgehend gar nicht darüber.

Die Metapher: Die Köche sind sehr besorgt darüber, ob die Karotten richtig schmecken, aber sie sagen den Helfern selten, wie sie prüfen können, ob der ganze Eintopf anbrennen wird oder ob sich die Aromen gut vermischen.

4. Die fehlenden „Geheimwaffen“

Die Forscher suchten auch nach fortgeschrittenen Kochtipps, die das Testen einfacher und zuverlässiger machen:

• Mocking (9,5 %): Manchmal kann man das echte Meerwasser nicht in seiner Suppe probieren; man muss stat einen gefälschten Salzstreuer benutzen, um es zu simulieren. Dies nennt man „Mocking“. Nur 1 von 10 Küchen hatte Anweisungen zur Verwendung dieser gefälschten Werkzeuge.
• Coverage/Abdeckung (25,5 %): Dies ist eine Punktetabelle, die zeigt, wie viel des Rezepts tatsächlich probiert wurde. Nur etwa ein Viertel der Küchen sagte den Helfern, welchen Wert sie anstreben sollten.
• Best Practices (9 %): Allgemeine Tipps wie „Probieren Sie immer, bevor Sie servieren“ waren sehr selten.

Das Fazit

Das Papier kommt zu dem Schluss, dass die meisten Open-Source-Projekte zwar wollen, dass ihre Helfer ihre Arbeit testen, die Anweisungen, die sie hinterlassen, jedoch unausgewogen sind.

Sie sind sehr gut darin zu sagen: „Hier ist, wie du den Test ausführst“, aber sie schweigen oft zu:

• Wie man einen neuen Test schreibt.
• Wie man komplexe Interaktionen testet (Integration).
• Wie man das gesamte System testet (End-to-End).
• Wie man fortgeschrittene Werkzeuge verwendet (Mocking) oder Qualitätsziele festlegt (Coverage).

Die Quintessenz: Wenn Sie ein neuer Helfer in einer dieser Küchen sind, wissen Sie vielleicht, wie man den „Probieren“-Knopf drückt, aber Sie werden oft sich selbst überlassen, um herauszufinden, wie man tatsächlich einen Geschmackstest für ein neues Rezept erstellt oder wie man sicherstellt, dass das neue Gericht nicht das ganze Mahl ruiniert. Die Autoren schlagen vor, dass Projektleiter klarere, vollständigere Anweisungen schreiben müssen, damit die Helfer nicht raten müssen.