Der traurige Zustand von Property-Based-Testing-Bibliotheken

• Property-Based Testing ist ein seltenes Beispiel dafür, dass sich akademische Forschung innerhalb von 30 Jahren im Mainstream etabliert hat.
• Unter dem Slogan „Schreibe keine Tests, sondern generiere sie“ hat es in den Communities vieler Programmiersprachen Unterstützung gewonnen.
• Auf der Wikipedia-Seite der ursprünglich für Haskell entwickelten Bibliothek QuickCheck sind 57 Neuimplementierungen in anderen Sprachen aufgeführt.

Untersuchung von Property-Based-Testing-Bibliotheken

• Es wurden die derzeit am häufigsten verwendeten Property-Based-Testing-Bibliotheken untersucht und mit dem Stand der Technik von vor 15 Jahren (2009) verglichen.
• Die meisten Bibliotheken bieten die fortgeschrittensten Funktionen des Property-Based Testing nicht an.

Warum sind Property-Based-Testing-Bibliotheken in diesem traurigen Zustand?

Zustandsbasierte und parallele Tests sind nicht so nützlich wie reine Tests

• Zustandsbasierte Modellierung erfordert Schulung.
• Es wird behauptet, dass Closed Source die Akzeptanz in der Industrie fördert.

Zustandsbasierte Modellierung erfordert Schulung

• Zustandsbasierte und parallele Tests verlangen eine andere Denkweise als gewöhnliche Tests.
• Wenn neue Nutzer mit diesen Werkzeugen arbeiten sollen, ist angemessene Schulung erforderlich.

Es wird behauptet, dass Closed Source die Akzeptanz in der Industrie fördert

• Es wird argumentiert, dass Open Source nicht funktioniert habe und dass Closed-Source-Produkte samt zugehörigen Dienstleistungen die Akzeptanz fördern.

Was wir tun können

• Kurze Open-Source-Implementierungen für zustandsbasiertes und paralleles Property-Based Testing bereitstellen.
• Den Teil mit formalen Spezifikationen einfacher machen, damit weniger Schulung für Entwickler nötig ist.

Zusammenfassung von reinem Property-Based Testing

• Das Testen neuer Funktionen oder Features gilt als gute Praxis.
• Wenn man zum Beispiel eine Funktion reverse zum Umdrehen einer verketteten Liste geschrieben hat, ist es sinnvoll, sie mit einigen Listen wie etwa der leeren Liste zu testen.
• Das Erzeugen zufälliger Eingaben ist eine Kernfunktion des Property-Based Testing.
• Die Idee ist, dass zufällige Eingaben irgendwann Corner Cases finden werden.

Zustandsbasiertes Property-Based Testing

• Beim Testen zustandsbehafteter Komponenten liefert dieselbe Eingabe nicht immer dieselbe Ausgabe.
• Im zustandsbasierten Testen werden Eingabesequenzen erzeugt, um zu prüfen, wie sich ein System im Zeitverlauf verändert.
• Der Zustand wird mithilfe einer In-Memory-Referenzimplementierung (Modell) explizit beschrieben.

Beispiel: Zähler

• Ein Zähler wird mithilfe einer globalen veränderbaren Variable implementiert.
• Das Modell wird als Integer dargestellt.
• Der Test erzeugt und führt eine Befehlssequenz aus und vergleicht dann die tatsächliche Ausgabe mit der Ausgabe des Modells.

Paralleles Property-Based Testing

• Paralleles Testen verwendet das Modell des zustandsbasierten Testens erneut, um Race Conditions zu erkennen.
• Paralleles Testen nutzt ein sequenzielles Zustandsmaschinenmodell, um parallele Tests über Lineariserbarkeit durchzuführen.

Fazit und zukünftige Arbeit

• Um den Zustand des Property-Based Testing zu verbessern, sind Open-Source-Implementierungen und einfacher nutzbare formale Spezifikationen erforderlich.

Meinung von GN⁺

• Dieser Artikel erklärt die Geschichte und den aktuellen Stand des Property-Based Testing gut.
• Er betont die Bedeutung von zustandsbasierten und parallelen Tests und weist auf die Notwendigkeit von Open-Source-Implementierungen hin.
• Er schlägt Wege vor, Property-Based Testing leichter zugänglich zu machen.
• Andere Projekte mit ähnlichen Funktionen sind Hypothesis (Python) und PropEr (Erlang).
• Er betont, dass bei der Einführung neuer Technologien oder von Open Source Schulung und Unterstützung nötig sind.

[GN⁺]

Hacker-News-Kommentare

• Die Erfahrungen mit clojure.spec.alpha und test.check waren gut
  • hypothesis für Python wurde nicht weiter verwendet, da es große Datensätze nicht verarbeiten konnte
• Go unterstützt coverage-basiertes Fuzzing gut
  • Mit Fuzzing-Tests und Invarianzprüfungen lassen sich ähnliche Ergebnisse wie mit Property-Tests erzielen
• Die Forderung, dass Forschungsarbeiten mit Open-Source-Tools reproduzierbar sein müssen, kann dazu führen, dass nützliche Informationen verloren gehen
• Für Rust wird häufig proptest verwendet, um zustandsbasierte Property-Tests zu schreiben
  • Parallele Tests sind manchmal nützlich, aber es kann einfacher sein, mehrere Tests parallel auszuführen
• Das Quviq-QuickCheck-Paper wurde gelesen, aber es könnte besser sein, zustandsbasierte Tests direkt selbst zu schreiben
  • StateModel erfordert zusätzlichen Framework-Code und ist dadurch nicht effizient
• Neben Zustandsmaschinen und Parallelitätsaspekten könnten coverage-basierte Property-Tests einen größeren Einfluss haben
  • Wichtig ist, beim Generieren von Werten alle Invarianten beizubehalten und zugleich automatisches Shrinking zu erhalten
  • Der Ansatz des „internen Shrinkings“ von Hypothesis ist am effektivsten
• Auch für Clojure gibt es eine zustandsbasierte QuickCheck-Bibliothek
  • Parallele Tests sind dort bislang noch kein großes Problem
• Property-Based Testing lässt sich besser in das Typsystem integrieren, wenn man strenge Tests schreiben kann
  • Für einfache „Smoke Tests“ ist es leichter, zufällige Eingaben zu verwenden
• Es gibt auch QuickCheck Mini, die kostenlose Version von QuviQ Erlang QuickCheck
• Es wird gefragt, ob sich in JavaScript mit einer Property-Based-Testing-Bibliothek zufällige Werte erzeugen lassen, die bestimmte Bedingungen nicht erfüllen können