Ihr macht Testing nicht erst seit gestern – In meinem Fall 27 Jahre Erfahrung heißt: Ihr habt jede Sorte Bug gesehen. Ihr wisst auch: Die meisten Fehler sterben nicht an „zu wenig Intelligenz“, sondern an zu wenig Variation. Man testet drei hübsche Beispiele, klopft sich auf die Schulter – und in Produktion kommt dann der eine krumme Edge-Case, den keiner auf dem Schirm hatte.
Genau da kommt Hypothesis zum Einsatz. Nicht als neues Spielzeug, sondern als Werkzeug, das eure Tests endlich dahin bringt, wo sie hingehören: systematisch auf Kante.
Was ist Hypothesis überhaupt?
Hypothesis ist eine Python-Bibliothek für Property-Based Testing.
Heißt übersetzt:
Ihr denkt nicht mehr in „Testfall A, B, C“, sondern in Eigenschaften, die immer gelten müssen.
- Ihr sagt: „Das Ergebnis muss diese Regeln erfüllen.“
- Hypothesis erzeugt dann automatisch massig Eingaben, auch die fiesen.
- Und wenn’s knallt, liefert Hypothesis euch den kleinstmöglichen Gegenbeweis (Das sogenannte „Shrinking“).
Das ist der Punkt, wo man oft laut „Ach du Scheiße…“ sagt – und dann den Bug fixt, der sonst monatelang durchgerutscht wäre.
Warum das besser ist als 100 handgebaute Testdaten
Handgebaute Tests sind oft:
- zu „vernünftig“
- zu „clean“
- zu nah am Entwicklerdenken
Hypothesis ist:
- unvernünftig
- gnadenlos
- und findet die Stellen, wo eure Annahmen falsch sind
- Die pure Anarchie
Wenn ihr mal ehrlich seid: Die richtig miesen Bugs kommen fast immer aus den Ecken, wo jemand gedacht hat: „Das passiert eh nie.“ Und das ist genau die Krux, man kann mehrere tausend Testfälle haben, Edge-Cases abgedeckt haben, aber dann ist da der eine Fehler der durchrutscht.
Mini-Beispiel: Sortieren – nicht nur abnicken, sondern prüfen
Ihr wollt z. B. testen: sortieren, bleibt sortiert und verliert keine Werte.
from hypothesis import given from hypothesis import strategies as st @given(st.lists(st.integers())) def test_sorting_is_consistent(xs): ys = sorted(xs) assert ys == sorted(ys) # ist geordnet assert sorted(xs) == ys # gleiche Multimenge
„Zu simpel?“ – ja. Und genau deswegen ist es gut. Hypothesis jagt das mit zig Varianten durch und findet, wenn irgendwo was krumm ist.
Der eigentliche Killer-Feature: Shrinking (Minimaler Gegenbeweis)
Wenn ein Test fehlschlägt, kommt oft sowas wie:
„Fehler bei Liste mit 378 Elementen…“
Hypothesis macht daraus:
„Fehler bei
[0, 0]“
Das spart euch Zeit, Nerven und diese typischen „Ich kann’s nicht reproduzieren“-Diskussionen.
Wo Hypothesis euch richtig hilft
Hypothesis lohnt sich brutal bei allem, was Kombinatorik hat:
- Parser / Serializer (JSON, CSV, eigene Formate)
- Validatoren (Input-Checks, Regeln, Datenmodelle)
- Business-Logik mit vielen Kombinationen
- Refactoring-Schutz: Properties bleiben stabil, Beispieltests brechen gerne „aus Versehen.“
- fiese Bugs, die nur bei bestimmten Daten passieren
Kurz: überall da, wo ihr sonst Testdaten würfelt oder 40 Fixtures baut.
Strategien: So baut ihr euch realistische Daten
Hypothesis arbeitet mit Strategies (st.*). Das sind Generatoren für Inputs.
Beispiel mit einem simplen User-Objekt:
from dataclasses import dataclass from hypothesis import given, strategies as st @dataclass class User: name: str age: int user_strategy = st.builds( User, name=st.text(min_size=1, max_size=50), age=st.integers(min_value=0, max_value=120), ) @given(user_strategy) def test_user_age_is_valid(u: User): assert 0 <= u.age <= 120
Ihr gebt vor, was „gültig“ ist – Hypothesis liefert die Varianten.
assume: Filtern, aber nicht übertreiben
Manchmal braucht ihr Voraussetzungen, z. B. „b darf nicht 0 sein“:
from hypothesis import assume, given, strategies as st @given(st.integers(), st.integers()) def test_division_roundtrip(a, b): assume(b != 0) q = a / b assert q * b == a
Achtung: wenn ihr zu viel filtert, wird’s langsam. Besser ist oft, gleich eine Strategy zu bauen, die nur gültige Werte liefert.
Einstellungen: Wie hart Hypothesis draufgeht
-
max_examples: mehr Fälle = mehr Chancen auf echte Bugs -
deadline: Zeitlimit pro Beispiel (bei langsamen Tests ggf. anpassen)
Hypothesis ist wie Fuzzing – nur alltagstauglich
Ihr kennt das: Die besten Tools sind die, die euch unangenehme Wahrheiten zeigen, bevor’s der Kunde tut. Hypothesis ist genau so ein Ding.
Es zwingt euch, Tests als Verhaltensregeln zu formulieren – und dann lässt es euren Code beweisen, dass er die Regeln auch wirklich einhält. Oder eben nicht.
Wenn ihr es einmal richtig im Projekt habt, fühlt sich vieles andere plötzlich wie „Testen mit Stützrädern“ an.
Weitere hilfreiche Informationen:
https://data-flair.training/blogs/hypothesis-testing-in-r/
https://hypothesis.works/articles/how-hypothesis-works/
Neueste Kommentare