Property-based Testing: Eigenschaften prüfen statt Beispiele durchspielen
Beispielbasierte Tests prüfen drei Fälle, an die jemand gedacht hat. Eigenschaftsbasierte Tests prüfen eine Aussage über alle Fälle, indem sie hunderte davon erzeugen. Der Unterschied klingt akademisch und ist praktisch der zwischen „läuft bei uns" und „gilt".
Eigenschaftsbasierte Tests formulieren eine Aussage, die für alle gültigen Eingaben gelten muss, und erzeugen daraufhin hunderte Fälle — inklusive der Ränder, an die niemand denkt. Bei generiertem Code wirken sie besonders, weil dieser plausibel ist und vor allem bei unangenehmen Randfällen versagt. Einstieg über eine Funktion mit klarer fachlicher Aussage, zwei bis drei Eigenschaften. Sie prüfen nicht, ob die fachliche Regel richtig ist.
Der Unterschied an einem Beispiel
Beispielbasiert: Ein Rabatt von zehn Prozent auf hundert Euro ergibt neunzig Euro. Eigenschaftsbasiert: Für jeden gültigen Betrag und jeden gültigen Rabattsatz gilt, dass der Endpreis nie negativ ist, nie höher als der Ausgangspreis, und dass zwei aufeinanderfolgende Rabatte dasselbe Ergebnis liefern wie ihr kombinierter Satz. Der Rahmen erzeugt daraufhin hunderte Kombinationen, darunter die Null, die Zahl mit vielen Nachkommastellen und den Grenzfall bei hundert Prozent.
Warum das bei generiertem Code besonders wirkt
Generierter Code ist plausibel. Er sieht richtig aus, folgt den Konventionen und hat für die offensichtlichen Fälle meist recht. Was fehlt, ist die Erfahrung mit den unangenehmen Rändern: leere Mengen, doppelte Einträge, Zeitzonen, negative Werte, gleichzeitige Zugriffe. Genau dort setzen Eigenschaftstests an, und sie tun es ohne dass jemand vorher an den Fall denken muss.
Wie man anfängt, ohne die Codebasis umzubauen
Mit einer Funktion, die eine klare fachliche Aussage trägt: eine Berechnung, eine Umwandlung, eine Validierung. Man formuliert zwei bis drei Eigenschaften und lässt sie laufen. In der Praxis fällt schon dabei etwas auf — meistens ein Grenzfall, der seit Jahren im System steckt und nie aufgefallen ist, weil ihn niemand ausgelöst hat. Von dort ausgehend wächst die Sammlung entlang der Bereiche mit dem höchsten Schaden.
Was Eigenschaftstests nicht können
Sie sagen nicht, ob die fachliche Regel richtig ist. Wenn Sie festlegen, dass ein Rabatt nie über fünfzig Prozent gehen darf, prüft der Test genau das — auch wenn der Fachbereich inzwischen siebzig zulässt. Die Eigenschaft ist eine Behauptung über Ihr System, und sie ist so gut wie das Gespräch, aus dem sie stammt.
Der Nebeneffekt, der oft wichtiger ist als die gefundenen Fehler
Um eine Eigenschaft zu formulieren, muss man aussprechen, was eigentlich gelten soll. Diese Gespräche zwischen Entwicklung und Fachbereich sind der eigentliche Ertrag: Sie fördern regelmäßig zutage, dass zwei Beteiligte unterschiedliche Vorstellungen davon hatten, was das System tut.
Häufige Fragen
Für welche Sprachen gibt es passende Rahmenwerke?
Für alle gängigen: Hypothesis für Python, jqwik für Java, fast-check für JavaScript und TypeScript, FsCheck für .NET, PropEr für Erlang. Die Konzepte sind identisch, der Einstieg dauert Stunden, nicht Tage.
Wie viele Eigenschaften braucht eine Funktion?
Zwei bis vier reichen fast immer. Mehr Eigenschaften bringen selten mehr Sicherheit, kosten aber Laufzeit. Wichtiger als die Zahl ist, dass eine davon eine echte fachliche Aussage trifft und nicht nur eine technische Selbstverständlichkeit.
Ersetzen Eigenschaftstests die vorhandenen Tests?
Nein, sie ergänzen sie. Beispieltests bleiben wertvoll als lesbare Dokumentation konkreter Fälle und für Regressionen, die einmal aufgetreten sind. Eigenschaftstests decken den Raum dazwischen ab.
Wie geht man mit langsamen Eigenschaftstests um?
Über die Zahl der erzeugten Fälle steuern: im normalen Build wenige hundert, in einem nächtlichen Lauf deutlich mehr. Fällt dort ein Fall durch, wird er als Beispieltest festgeschrieben und läuft ab dann in jedem Build mit.
Rechnen Sie Ihre Review-Lücke aus.
Vierzehn Fragen, fünf Minuten. Ihre Zahlen, kein Login.
AI Engineering Review ansehen →
