property-based-testing

Überblick über die property-based-testing-Skill

Wofür diese Skill gedacht ist

Die property-based-testing-Skill hilft dir dabei, Property-based-Tests zu schreiben, zu prüfen und zu verbessern, wenn beispielbasierte Tests nicht mehr genug Vertrauen geben. Besonders nützlich ist die property-based-testing-Skill, wenn du Roundtrips, Invarianten, Parser, Validatoren, Normalisierer, Sortierlogik oder Zustandsregeln von Smart Contracts absichern musst.

Wer am meisten davon profitiert

Am besten geeignet ist sie für Engineers in Sprachen mit ausgereiften PBT-Bibliotheken, für Reviewer, die schwache Tests bewerten, und für Entwickler, die Funktionen von Anfang an als Eigenschaften spezifizieren wollen. Wenn du gerade abwägst, ob du property-based-testing installieren solltest, lautet die Schlüsselfrage: Hat dein Code wiederverwendbare Struktur, umkehrbare Transformationen oder Regeln, die über viele Eingaben hinweg gelten müssen?

Was die Skill anders macht

Anders als ein generischer Testing-Prompt ist diese Skill um Erkennung, Property-Auswahl, Strategie-Design und die Interpretation von Fehlern herum aufgebaut. Das ist wichtig, weil die größte Hürde bei der Einführung nicht die Syntax ist, sondern eine nützliche Eigenschaft zu finden und gültige Eingaben zu erzeugen, ohne zu stark zu filtern. Die Skill ist außerdem breit genug für property-based-testing for Skill Testing über mehrere Ökosysteme hinweg, einschließlich Smart Contracts.

So verwendest du die property-based-testing-Skill

Die richtige Kontextbasis installieren und laden

Installiere sie mit npx skills add trailofbits/skills --skill property-based-testing und öffne zuerst SKILL.md. Für schnellere Entscheidungen solltest du außerdem README.md und die Referenzdateien lesen, die für deine Aufgabe am relevantesten sind: references/generating.md, references/reviewing.md und references/interpreting-failures.md.

Eine grobe Idee in einen brauchbaren Prompt verwandeln

Ein guter property-based-testing usage-Prompt sollte Ziel, Operation und die Garantie benennen, die dir wichtig ist. Besserer Input: „Füge PBT für decode(encode(x)) in diesem Serializer hinzu und halte die Eingaben innerhalb gültiger UTF-8- und Größenlimits.“ Schlechterer Input: „Schreibe Property-Tests für dieses Modul.“ Im ersten Fall bekommt die Skill eine echte Eigenschaft, sinnvolle Eingrenzungen des Wertebereichs und eine klare Zielstruktur.

Was du in deiner Anfrage mitgeben solltest

Nenne Sprache, Testbibliothek, Funktionssignatur, bekannte Invarianten, das Verhalten bei ungültigen Eingaben sowie Beispiele oder Spezifikationen. Wenn du den property-based-testing-Leitfaden für ein Review nutzt, füge den aktuellen Test ein und erkläre, ob du Fehlersuche, Refactoring oder ein Qualitätsaudit möchtest. Wenn der Code Parsing- oder Validierungspfade hat, sage dazu, was bei fehlerhaften Daten passieren soll; das verhindert vage Tests und den falschen Einsatz von assume().

Empfohlener Workflow

Ordne den Code zuerst einem Property-Typ zu: Roundtrip, Idempotenz, Invariante, Sortierung oder Oracle. Definiere dann Strategien, die gültige Eingaben konstruktiv erzeugen, statt stark zu filtern. Interpretiere Fehler schließlich mit references/interpreting-failures.md, bevor du sie als Bugs behandelst. Bei Smart Contracts solltest du die EVM-spezifischen Hinweise prüfen und das Zustandsmodell explizit halten.

Häufige Fragen zur property-based-testing-Skill

Ersetzt property-based-testing normale Tests?

Nein. Die Skill ist besonders wertvoll dort, wo herkömmliche Beispiele Randfälle übersehen oder wo eine Property viele Verhaltensweisen abdecken kann. Behalte Beispieltests für schmale Regressionen bei und nutze property-based-testing dort, wo eine allgemeine Regel klarer ist als eine Handvoll Einzelfälle.

Ist dieser property-based-testing-Leitfaden anfängerfreundlich?

Ja, wenn das Zielverhalten einfach und die Eigenschaft offensichtlich ist, etwa bei einem Roundtrip oder einem Idempotenz-Check. Schwieriger wird es, wenn die Spezifikation unscharf ist, denn PBT braucht einen klaren Vertrag, bevor ein Generator wirklich nützlich wird.

Wann sollte ich diese Skill nicht verwenden?

Greife nicht zuerst zu ihr, wenn das Verhalten vor allem UI-getrieben, stark nicht-deterministisch oder nicht als stabile Eigenschaft formulierbar ist. Ebenfalls ungeeignet ist sie, wenn das einzige Oracle eine lange Kette aus Nachimplementierungen ist, die die Produktionslogik nur spiegelt.

Passt sie zu meiner Sprache oder meinem Framework?

Die Skill unterstützt viele Ökosysteme, darunter Hypothesis, fast-check, proptest, jqwik, ScalaCheck, FsCheck, StreamData, QuickCheck sowie Smart-Contract-Fuzzer wie Echidna und Medusa. Liegt dein Stack außerhalb dieser Liste, hilft die zugrunde liegende Methode trotzdem, aber du musst Syntax und Strategy-APIs möglicherweise anpassen.

So verbesserst du die property-based-testing-Skill

Gib die stärkste Eigenschaft an, nicht nur das Ziel

Die besten Ergebnisse entstehen, wenn du die genaue Garantie benennst. Zum Beispiel ist „normalize(normalize(x)) == normalize(x) für Unicode-Strings“ besser als „normalize testen“. Die property-based-testing-Skill arbeitet besser, wenn die Property konkret, falsifizierbar und an einen bekannten Vertrag gekoppelt ist.

Teile die Einschränkungen mit, die Generatoren formen

Typische Fehlerquellen sind ungültige Eingaben, zu stark gefilterte Strategien und Properties, die zu schwach sind, um echte Bugs zu finden. Verbessere die Qualität des Outputs, indem du zulässige Bereiche, Formatregeln, Größenlimits und die erwartete Behandlung von Ausnahmen nennst. Wenn eine Property erst nach der Validierung gelten soll, sag das ausdrücklich.

Arbeite von fehlschlagenden Beispielen aus weiter

Wenn der erste Test fehlschlägt, bitte nicht einfach nur um einen Fix. Gib das verkleinerte Gegenbeispiel, die beabsichtigte Regel und jede Dokumentation an, die das Verhalten an Randfällen definiert. So kann die Skill einen echten Bug von einer schlechten Property unterscheiden und im zweiten Durchlauf einen stärkeren Test oder einen fundierten Refactoring-Vorschlag liefern.