Programmable Property-Based Testing
Dieses Paper führt „deferred binding abstract syntax“ ein, eine neue Mixed-Embedding-Sprache für das property-based Testing, die Eigenschaften als Datenstrukturen reifiziert, um sie von der Ausführung zu entkoppeln und dadurch eine größere Flexibilität und Programmierbarkeit beim Entwurf benutzerdefinierter Property-Runner zu ermöglichen.
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 Qualitätsprüfer in einer Fabrik, die komplexe Maschinen baut. Ihr Job ist es, sicherzustellen, dass jede Maschine korrekt funktioniert.
In der Welt der Software wird dieser Job als Property-Based Testing (PBT) bezeichnet. Anstatt nur eine spezifische Maschine zu prüfen, schreiben Sie eine Regel (eine „Property“), die besagt: „Egal welche Art von Maschine du baust, sie muss immer X tun.“ Dann baut ein Computerprogramm (der „Runner“) automatisch tausende zufällige Maschinen, testet sie gegen Ihre Regel und versucht, eine defekte zu finden.
Das Problem: Der „Black Box“-Runner
Das Paper argumentt, dass aktuelle Testing-Tools wie eine starre, vorgefertigte Montagestraße sind.
- Die gute Nachricht: Es ist sehr einfach für Sie, die Regel (die Property) zu schreiben. Sie sagen einfach: „Prüfe, ob der Motor läuft.“
- Die schlechte Nachricht: Die Art und Weise, wie der Computer diese Maschinen tatsächlich baut und testet, ist in einer „Black Box“ eingeschlossen. Sie können nicht ändern, wie er sie baut.
- Vielleicht möchten Sie Maschinen bauen, die auf dem basiert, was aus vorherigen Fehlern gelernt wurde (wie ein smarter Roboter, der lernt, wo er suchen muss).
- Vielleicht möchten Sie versuchen, die Maschine auf eine bestimmte Weise zu manipulieren, um einen verborgenen Fehler zu finden.
- Vielleicht möchten Sie die Tests gleichzeitig auf 100 verschiedenen Arbeitern ausführen.
In aktuellen Tools können Sie die Montagestraße nicht einfach durch Ändern der Einstellungen anpassen. Sie müssen die gesamte Fabrik abreißen und eine neue bauen, nur um die Art des Testens zu ändern. Das ist frustrierend und begrenzt, wie „smart“ Ihr Testen werden kann.
Die Lösung: „Deferred Binding Abstract Syntax“ (DBAS)
Die Autoren schlagen einen neuen Weg vor, diese Testing-Tools zu bauen. Sie nennen ihre Methode Deferred Binding Abstract Syntax (DBAS).
Betrachten Sie DBAS nicht als eine starre Montagestraße, sondern als eine LEGO-Bauanleitung.
- Der alte Weg (Shallow Embedding): Die Bauanleitung ist nur ein Satz, der auf einem Stück Papier geschrieben steht. Man kann ihn lesen, aber man kann die Wörter nicht auseinandernehmen oder neu anordnen. Der Fabrikbesitzer (der Autor der Library) hat genau festgelegt, wie die Wörter gedruckt werden, und Sie müssen ihnen folgen.
- Der neue Weg (DBAS): Die Bauanleitung ist aus LEGO-Steinen gebaut.
- Sie schreiben Ihre Regel (die Property) immer noch so, dass sie wie normales Englisch aussieht.
- Aber darunter hat der Computer Ihre Regel als einen Stapel physischer LEGO-Steine gespeichert.
- Da sie aus Steinen besteht, können Sie (der Nutzer) den Stapel aufheben, die Teile betrachten und entscheiden, wie Sie sie interpretieren.
Wie es funktioniert: Der „Deferred“-Trick
Das Paper führt einen cleveren Trick namens „Deferred Binding“ ein.
- Normale Logik: Normalerweise, wenn Sie sagen: „Für jedes Auto, prüfe die Bremsen“, müssen Sie zuerst ein spezifisches Auto auswählen und dann die Bremsen prüfen.
- DBAS-Logik: Das System sagt: „Ich werde erst im allerletzten Moment ein spezifisches Auto auswählen.“ Stattdessen behält es eine Liste aller Regeln über Autos, und erst wenn der „Runner“ (die Person, die den Test durchführt) bereit ist, tatsächlich etwas zu testen, sagt er: „Okay, lass uns jetzt ein Auto auswählen und die Bremsen prüfen.“
Diese Trennung ist die Magie. Das bedeutet, dass die Regel (was Sie testen wollen) völlig von dem Runner (wie Sie testen) getrennt ist.
Was können Sie damit machen?
Da die Regel nun ein Stapel aus LEGO-Steinen (eine Datenstruktur) ist und nicht mehr ein festgeschriebener Satz, können Sie Ihre eigenen „Runner“ in Ihrem eigenen Code schreiben, ohne die Fabrik zu beschädigen. Das Paper zeigt, dass sie mehrere neue Arten von Runnern gebaut haben:
- Der „smarte“ Runner (Coverage-Guided Fuzzing): Anstatt zufällige Maschinen zu bauen, merkt sich dieser Runner, welche Maschinen er gebaut hat, die zu interessanten Stellen geführt haben. Er passt dann genau diese Maschinen an, um zu sehen, ob er einen neuen, defekten Pfad finden kann. Es ist wie ein Detektiv, der sich an die Hinweise erinnert und den vielversprechendsten Spuren folgt.
- Der „Team“-Runner (Parallel Testing): Dieser Runner teilt die Arbeit auf viele Arbeiter (Threads) auf, die ein gemeinsames Notizbuch teilen. Sie koordinieren sich, damit sie keine Zeit damit verschwenden, dieselbe Maschine zweimal zu bauen.
- Der „Custom Feedback“-Runner: Dieser Runner hört auf spezifische Signale von der Maschine (wie etwa wie viel Speicher sie nutzt oder wie lange sie braucht) und nutzt diese Informationen, um bessere Testfälle zu erstellen.
Die Ergebnisse
Die Autoren haben dieses neue System in zwei Sprachen (Rocq und Racket) getestet und mit den alten „festgeschriebenen“ Systemen verglichen.
- Geschwindigkeit: Es ist genauso schnell wie die alten Systeme. Es gibt keinen Nachteil durch die Flexibilität.
- Flexibilität: Sie waren in der Lage, all diese komplexen, smarten Runner (wie den „smarten“ oder den „Team“-Runner) zu bauen, indem sie einfach User-Level-Code geschrieben haben. Sie mussten nicht den Kern der Library neu bauen.
- Besseres Testen: In einem Experiment fanden sie heraus, dass sie durch die Änderung der Art und Weise, wie der „Seed Pool“ (die Liste der Hinweise) verwaltet wird, Bugs viel schneller finden konnten als mit den Standard-Tools.
Das Faz-Fazit
Dieses Paper führt eine neue Art ein, Softwaretests zu schreiben, die den „Testprozess“ von einer festgeschlossenen, vorgefertigten Maschine in ein programmierbares, anpassbares Werkzeug verwandelt. Es ermöglicht Entwicklern, ihre eigenen Teststrategien (wie smartes Fuzzing oder paralleles Testen) zu erfinden, ohne ein Experte für den internen Code der Testing-Library sein zu müssen. Es macht das Testen flexibler, leistungsfähiger und anpassungsfähiger an spezifische Bedürfnisse, ohne dabei die Geschwindigkeit zu drosseln.
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.