Test-Driven Development

Test-Driven Development (TDD) verlagert das Schreiben von Tests zeitlich vor die eigentliche Implementierung. In diesem Notebook betrachten wir verschiedene Werkzeuge im Python-Ökosystem, um die Korrektheit und Robustheit unseres Codes von einfachen interaktiven Beispielen bis hin zu massenhaft generierten Randfällen sicherzustellen.

Dies ist eine logische Fortführung unserer Beschäftigung mit Lintern und Typisierung. Wenn Typ-Checks die strukturelle Korrektheit gewährleisten, sichern Tests die semantische Korrektheit.

Worum es geht. Tests als Mittel, die semantische Korrektheit zu sichern — von einem ersten assert über den vollständigen TDD-Zyklus bis zu Werkzeugen, die Testfälle selbst erzeugen und die Tests ihrerseits auf die Probe stellen. Laufendes Beispiel ist die Berechnung der Shannon-Entropie.

Was Sie danach können. Einen Test vor der Implementierung schreiben und den Zyklus Rot–Grün–Refaktorisieren durchlaufen; mit parametrize und Fixtures Wiederholung vermeiden; Zeit, Zufall und Nutzereingaben testbar machen; Coverage richtig interpretieren; und mit Mutation Testing prüfen, ob die eigenen Tests überhaupt etwas prüfen.

Die Java-Entsprechung in einem Satz. pytest ist JUnit ohne Klassenzwang: Ein Test ist eine Funktion, deren Name mit test_ beginnt, und die Prüfung ist ein gewöhnliches assert, dessen Fehlermeldung das Framework aus dem Ausdruck selbst rekonstruiert.

Das durchgehende Beispiel: Berechnung der Shannon-Entropie¶

Wir nutzen als Running Example die Berechnung der Shannon-Entropie für eine diskrete Wahrscheinlichkeitsverteilung:

dabei soll calculate_entropy also eine Funktion sein, die die Verteilung (also die $p_i$) gegeben bekommt, und einen float zurück gibt, der die Entropie der gegebenen Verteilung ist.

Wir fügen nun eine Logik hinzu, die unsere Annahmen über den Parameter probs teilweise verifiziert, ergänzen Type Hints und betten jetzt Doctests ein. Das Modul Doctest sucht interaktive Python-Beispiele in den Docstrings und führt sie aus. Das automatisierte Prüfen von Doctests verhindert, dass diese Code-Beispiele veralten. Da der Docstring z.B. in IDEs oft eingeblendet wird, ist das sehr nützlich.

Wir sehen also: unser Doctest hat bereits erste Erfolge gezeigt, nämlich eine falsche Annahme aufgedeckt (dass die Null ohne Vorzeichen ist). Jetzt müssen wir uns fragen, ob der Test falsch geschrieben ist (also wir dort als Erwartung -0.0 hinschreiben sollten) oder ob wir unseren Code ändern, z.B. durch + 0.0, was gemäß IEEE 754 aus sowohl 0.0 als auch -0.0 einheitlich 0.0 macht.

Hier mag einigermaßen klar sein, was richtig ist; im Allgemeinen sollte man bei jeder verletzten Annahme in Ruhe darüber nachdenken, welche anderen Teile unseres Programm- und Weltmodells von diesem Fehler betroffen sein könnten.

Grundlagen: Unit Tests mit pytest¶

pytest ist das De-facto-Standard-Framework in der Python-Welt. Im Gegensatz zum eingebauten Modul unittest, welches stark objektorientiert ist, glänzt pytest durch eine minimale Syntax (wir nutzen ein simples assert) und aussagekräftige Fehlermeldungen.

Wir erstellen nun eine Datei für unsere Unit Tests, welche die entropy-Funktion isoliert testen. Dabei testen wir auch, ob unter bestimmten Bedingungen ein erwarteter Fehler auftritt (also testen wir nicht nur den Happy Path).

Unter der Haube nutzt pytest das Framework Pluggy, welches eine extrem flexible Plugin-Architektur ermöglicht. Dadurch gibt es hunderte Erweiterungen wie pytest-cov oder pytest-mock (s.u.). Pluggy kommt auch in anderen Testing-Frameworks (wie z.B. tox, s.u.) aber auch in Datenverarbeitungswerkzeugen zum Einsatz.

Der Zyklus: Rot, Grün, Refaktorisieren¶

Bis hierher sind wir code-first vorgegangen: erst die Funktion, dann die Tests. Das ist völlig legitim, aber es ist nicht TDD. Der eigentliche Zyklus besteht aus drei Schritten, und der erste ist der ungewohnte:

1. Rot — einen Test schreiben, der das gewünschte Verhalten beschreibt, und ihn fehlschlagen sehen.

2. Grün — die einfachste Implementierung schreiben, die ihn bestehen lässt. Nicht die schönste.

3. Refaktorisieren — den Code aufräumen, während die Tests grün bleiben.

Warum zuerst der Test? Vor allem, weil man sonst nie erfährt, ob der Test etwas prüft. Ein Test, den man nach der Implementierung schreibt und der sofort grün ist, kann grün sein, weil der Code stimmt — oder weil der Test nichts misst (falscher Import, vertippter Funktionsname, vergessenes assert). Diesen Unterschied sieht man nur, wenn man den Test einmal rot gesehen hat. Zweitens zwingt der Test dazu, die Schnittstelle aus der Sicht des Aufrufers zu entwerfen, bevor man sich in die Implementierung verliebt. Und drittens ist der rote Test die Definition von “fertig”: Wenn er grün ist, hört man auf.

Machen wir das an einer neuen Anforderung durch: Die Entropie soll auch in anderen Einheiten als Bit gemessen werden können — in nats (Basis e) oder dits (Basis 10). Die Schnittstelle soll calculate_entropy(probs, base=2) heißen, und der bisherige Aufruf muss unverändert funktionieren.

Schritt 1: Rot¶

Zwei rote Tests, einer grün — genau so soll es aussehen. Der grüne Test ist wertvoll: Er hält fest, dass wir die bestehende Schnittstelle nicht kaputtmachen dürfen. Und die Fehlermeldung ist nicht etwa ein falsches Ergebnis, sondern ein TypeError: Die Funktion kennt das Argument noch gar nicht. Auch das ist ein legitimer roter Test.

Schritt 2: Grün¶

Jetzt die kleinstmögliche Änderung. math.log(p, base) rechnet den Logarithmus zu beliebiger Basis; das ist nicht die beste Lösung, aber die schnellste.

Schritt 3: Refaktorisieren¶

Grün heißt nicht fertig. math.log(p, base) hat zwei Nachteile: Es berechnet für jedes Element zwei Logarithmen statt einen, und es verliert die numerische Genauigkeit, die math.log2 für die Basis 2 besonders sorgfältig herstellt. Die Mathematik erlaubt uns, den Basiswechsel einmal am Ende vorzunehmen, weil $H_b(X) = H_2(X) / \log_2 b$ gilt.

Beim Refaktorisieren ändert sich das Verhalten nicht — deshalb rühren wir die Tests nicht an. Sie sind jetzt das Sicherheitsnetz, das uns diese Umstellung überhaupt erst erlaubt.

Die Tests sind grün geblieben, und die Doctests aus dem ersten Abschnitt ebenfalls. Genau das ist der Gewinn: Wir haben die Implementierung ausgetauscht, ohne sie erneut von Hand prüfen zu müssen.

Der Zyklus ist bewusst klein gehalten — eine Anforderung, drei Schritte, wenige Minuten. Wer eine halbe Stunde lang rot ist, hat sich zu viel auf einmal vorgenommen.

pytest im Alltag: Parametrisierung und Fixtures¶

Zwei Mechanismen tragen in der Praxis den größten Teil einer Test-Suite. Ohne sie schreibt man denselben Test viermal mit anderen Zahlen und baut sich die Testumgebung in jedem Test von Hand auf.

Parametrisierung¶

@pytest.mark.parametrize erzeugt aus einer Testfunktion mehrere Tests — einen pro Datensatz. Der Unterschied zu einer Schleife im Test ist entscheidend: Jeder Fall wird einzeln ausgeführt und einzeln berichtet, und ein Fehlschlag stoppt die übrigen nicht.

In der Ausgabe steht hinter jedem Test der konkrete Datensatz in eckigen Klammern. Schlägt einer fehl, weiß man sofort, welcher — und kann ihn mit pytest "test_entropy_param.py::test_entropie_bekannter_verteilungen[probs3-1.5]" einzeln erneut ausführen.

Beachtenswert ist außerdem pytest.approx: Fließkommazahlen auf Gleichheit zu prüfen ist fast immer falsch. 0.1 + 0.2 == 0.3 ist False, und Entropiewerte entstehen aus Logarithmen.

Fixtures¶

Eine Fixture stellt einem Test seine Vorbedingungen bereit und räumt danach auf. Man fordert sie an, indem man ihren Namen als Parameter schreibt — pytest setzt ihn ein. Neben eigenen Fixtures gibt es eingebaute; drei davon braucht man ständig:

• tmp_path — ein leeres Verzeichnis (als pathlib.Path), das nach dem Test verschwindet. Damit muss kein Test mehr in das Projektverzeichnis schreiben.

• monkeypatch — setzt Attribute, Umgebungsvariablen oder Arbeitsverzeichnisse für die Dauer eines Tests und stellt sie danach zurück.

• capsys — fängt stdout und stderr ab, sodass man Ausgaben prüfen kann.

Der vierte Test ist der eigentliche Beweis: monkeypatch hat die Umgebungsvariable nach dem dritten Test wieder entfernt. Genau diese Aufräumgarantie ist der Grund, monkeypatch gegenüber einem selbstgebauten os.environ[...] = ... zu bevorzugen — auch dann, wenn der Test mittendrin mit einer Exception abbricht.

Eigene Fixtures können ebenfalls aufräumen, indem sie den Wert mit yield herausgeben und danach weiterarbeiten:

@pytest.fixture
def datenbank():
    con = sqlite3.connect(":memory:")
    yield con          # hier läuft der Test
    con.close()        # und danach das hier, auch bei Fehlern

Mit @pytest.fixture(scope="module") oder scope="session" wird sie einmal pro Datei bzw. pro Lauf statt pro Test ausgewertet — schneller, aber der Zustand ist dann geteilt, und Tests können sich gegenseitig beeinflussen.

Wohin mit den Testdateien?¶

Sobald es mehr als eine Handvoll Tests sind, gehören sie in ein eigenes Verzeichnis neben den Quelltext:

projekt/
├── pyproject.toml
├── src/
│   └── cyoa/
│       ├── __init__.py
│       └── engine.py
└── tests/
    ├── conftest.py          # Fixtures, die mehrere Testdateien teilen
    ├── test_engine.py
    └── test_speichern.py

conftest.py ist dabei eine Besonderheit: Was dort als Fixture definiert ist, steht allen Tests im selben Verzeichnis (und darunter) zur Verfügung, ohne dass man es importieren muss. Die Datei wird nie selbst als Test ausgeführt.

Damit pytest ohne Argumente das Richtige tut, trägt man die Konvention in die pyproject.toml ein:

[tool.pytest.ini_options]
testpaths = ["tests"]
addopts = "-q --strict-markers"

Die Namenskonventionen sind nicht verhandelbar: Dateien heißen test_*.py, Funktionen test_*, Klassen Test* (ohne __init__). Wer eine Testdatei entropy_tests.py nennt, wundert sich, warum pytest nichts findet.

Testabdeckung (Coverage)¶

Mit dem Plugin pytest-cov können wir messen, wie viel Prozent des Quellcodes während unserer Tests ausgeführt wurden. Eine niedrige Abdeckung ist ein Indikator für fehlende Tests, aber eine hohe Abdeckung keine absolute Garantie für Fehlerfreiheit.

Wie viele Tests sind genug?¶

Die Coverage-Zahl beantwortet diese Frage nicht — die Zelle darüber ist der Beleg: entropy.py steht bei 100%, obwohl keiner der beiden Tests jemals den Parameter base benutzt. Jede Zeile wurde ausgeführt, die halbe Schnittstelle ist ungeprüft. Sie misst, welche Zeilen ausgeführt wurden — nicht, ob dabei etwas geprüft wurde. Ein Test ohne einziges assert erzeugt 100% Abdeckung und findet nichts. Coverage ist eine Untergrenze: Was nie ausgeführt wurde, ist sicher ungetestet; was ausgeführt wurde, ist vielleicht getestet.

Drei brauchbare Regeln statt einer Zahl:

1. Ein Test pro Verhalten, nicht pro Methode. Eine Methode mit drei Sonderfällen braucht vier Tests; drei triviale Getter brauchen keinen. Die Frage lautet nicht “welchen Code habe ich geschrieben”, sondern “welche Zusagen mache ich dem Aufrufer”.

2. Ein Regressionstest pro gefundenem Fehler. Sobald ein Bug auftaucht, wird er zuerst zu einem roten Test — dann behoben. Das ist der billigste Test, den man je schreibt, denn die Arbeit (das Reproduzieren) hat man beim Debuggen ohnehin geleistet. Und es ist der einzige, von dem man sicher weiß, dass er einen echten Fehler findet.

3. Der unangenehme Fall zuerst. Die Happy-Path-Tests schreiben sich von selbst und finden selten etwas. Die Fehler sitzen an den Rändern: leere Eingabe, ein Element, doppelte Einträge, negative Zahl, fehlende Datei, abgebrochene Eingabe. Wer wenig Zeit hat, testet die Ränder und lässt die Mitte weg.

Als Untergrenze lässt sich Coverage automatisch erzwingen, damit sie nicht schleichend sinkt:

uv run pytest --cov=entropy --cov-fail-under=80
uv run coverage html        # erzeugt htmlcov/index.html mit Zeilenmarkierung

Der HTML-Bericht ist dabei nützlicher als die Prozentzahl: Er zeigt die nicht ausgeführten Zeilen rot, und die sind oft genau die Fehlerbehandlung, an die beim Testen niemand gedacht hat.

Für die Abschlussprojekte in diesem Kurs ist der Maßstab damit klar benannt — und er steht bewusst in dieser Reihenfolge: nachvollziehbare Tests für die Kernlogik, ein Regressionstest pro behobenem Fehler, und erst danach eine Zahl. Was die Bewertung im Einzelnen erwartet, steht im Projektbericht.

Mocking: Externe Abhängigkeiten isolieren¶

Gute Unit Tests müssen deterministisch und extrem schnell sein. Wenn unsere Funktion Daten über das Netzwerk lädt oder eine Datenbank abfragt, ersetzen wir diesen Aufruf im Test durch einen Mock. Das Modul unittest.mock ist Teil der Standardbibliothek und wird auch von pytest genutzt.

Oft reichen hartkodierte Werte wie [0.5, 0.5] nicht aus, um realistische API-Antworten oder Datenbankeinträge zu simulieren, insbesondere wenn Metadaten gefordert sind. Das Paket faker generiert realistische, randomisierte Mock-Daten (Namen, URLs, IP-Adressen etc.).

Zeit und Zufall testbar machen¶

Zwei Dinge machen Tests zuverlässig unzuverlässig: die Uhr und der Zufallsgenerator. Ein Test, der um 23:59 Uhr fehlschlägt oder alle zwanzig Läufe einmal rot wird, ist schlimmer als kein Test — er bringt dem Team bei, rote Tests zu ignorieren.

Die Lösung ist fast immer dieselbe und keine Test-Technik, sondern eine Entwurfsentscheidung: Zeit und Zufall sind Eingaben, keine Umwelt. Statt sie in der Geschäftslogik zu beschaffen, übergibt man sie.

Der Koffein-Tracker macht das konsequent: calculate_level_at(target_time) bekommt den Zeitpunkt übergeben und ruft nirgends datetime.now() auf. Der Aufruf von now() steht in der Oberfläche, nicht in der Logik. Deshalb braucht dieses Modul zum Testen kein einziges Hilfsmittel — man setzt einfach datetime(2026, 5, 22, 8, 0) ein.

Beim Zufall geht dasselbe, indem man einen eigenen Generator durchreicht statt das Modul random global zu benutzen:

Der Unterschied zu random.seed(42) ist wichtiger, als er aussieht: random.seed setzt den globalen Generator. Läuft ein anderer Test parallel (pytest -n auto) oder zieht zwischendurch selbst eine Zahl, ist die Reihenfolge dahin. Eine eigene random.Random-Instanz hat diesen Zustand nicht.

Der dritte Test zeigt außerdem eine Alternative zum festgeschriebenen Erwartungswert: Statt konkreter Zahlen prüft er eine Eigenschaft, die für alle Ziehungen gelten muss. Systematisch weitergedacht ist das Property-Based Testing — der nächste Abschnitt.

Wenn man nicht injizieren kann¶

Bei fremdem Code hat man die Wahl oft nicht. Dann ersetzt man die Quelle von außen. Für die Uhr gibt es dafür spezialisierte Werkzeuge, weil datetime.now als C-Funktion nicht einfach zu überschreiben ist:

import time_machine
from datetime import datetime

@time_machine.travel(datetime(2026, 5, 22, 8, 0))
def test_am_morgen():
    assert datetime.now().hour == 8

time-machine ist der schnellere Nachfolger von freezegun, das man in älteren Projekten häufiger antrifft; beide können auch als Kontextmanager benutzt werden und die Zeit während des Tests weiterlaufen lassen.

Für alles andere genügt monkeypatch — wichtig ist dabei, dort zu patchen, wo der Name benutzt wird, nicht dort, wo er definiert ist:

def test_zufall_von_aussen(monkeypatch):
    monkeypatch.setattr("mein_spiel.random.randint", lambda a, b: 6)
    assert mein_spiel.wuerfeln() == 6

Das Plugin pytest-mock bietet dieselbe Funktionalität als Fixture mocker an, mit der bequemeren Zusage, Aufrufe mitzuzählen (mocker.patch(...) liefert ein Mock, das assert_called_once_with kennt). Es ist Zucker über unittest.mock aus dem vorigen Abschnitt, mit automatischem Aufräumen nach dem Test.

Nutzeroberflächen und Ein-/Ausgabe testen¶

Dies ist die Lücke, die in studentischen Projekten am zuverlässigsten offen bleibt: Die Kernlogik hat Tests, das Spiel selbst nicht — mit der Begründung, dass man Eingaben und Bildschirmausgabe nun einmal nicht testen könne. Man kann.

Der erste Schritt ist kein Test, sondern ein Schnitt¶

Testbarkeit ist hier vor allem eine Architekturfrage. Solange input() und print() mitten in der Spiellogik stehen, testet man beides zusammen oder gar nicht. Trennt man Engine (was passiert) von UI (wie es erscheint), lässt sich die Engine mit gewöhnlichen Unit Tests prüfen, und für die UI bleibt eine dünne Schicht übrig, die man mit wenigen Tests abdeckt.

Genau diesen Schnitt vollzieht der Übergang von practical-0 zu practical-1 — dort als Frage der Lesbarkeit begründet. Die Testbarkeit ist das zweite, härtere Argument dafür: Sie ist der Grund, warum sich die Mühe auch dann lohnt, wenn nie eine zweite Oberfläche dazukommt.

Terminal-Ein-/Ausgabe: monkeypatch und capsys¶

Selbst eine klassische Eingabeschleife ist mit den beiden Fixtures aus dem vorigen Abschnitt vollständig testbar. input ist eine gewöhnliche Funktion in builtins und lässt sich ersetzen:

Drei Tests, und damit ist die Schleife abgedeckt: der Normalfall, die Fehlerbehandlung und — am wichtigsten — der Fall, dass die Eingaben ausgehen. Der letzte ist keine Spielerei: Ohne ihn hängt ein Test, der die Abbruchbedingung nie erreicht, bis zum Timeout. Mit iter(...) und next bekommt man stattdessen ein sauberes StopIteration.

capsys.readouterr() liefert ein Objekt mit .out und .err und leert den Puffer dabei. Wer die Ausgabe zeichengenau prüfen will, vergleicht mit ==; meistens ist in die bessere Wahl, weil der Test sonst bei jeder Formulierungsänderung bricht, ohne dass ein Fehler vorliegt.

Die übrigen Oberflächen¶

Für jede Art von UI aus dem Kapitel User Interfaces gibt es einen etablierten Weg. Keiner davon ist aufwendig, und alle laufen ohne Bildschirm in der CI:

Für Pygame genügt in der Praxis eine conftest.py mit zwei Zeilen, damit alle Tests headless laufen:

import os
os.environ.setdefault("SDL_VIDEODRIVER", "dummy")
os.environ.setdefault("SDL_AUDIODRIVER", "dummy")

Und noch einmal der entscheidende Punkt: Diese Tests prüfen die Verdrahtung — dass ein Tastendruck die richtige Methode auslöst und die Anzeige den Zustand zeigt. Ob die Spiellogik stimmt, gehört in Tests der Engine, wo weder Tastatur noch Bildschirm vorkommen. Wer die Trennung nicht vollzogen hat, schreibt beide Arten von Test in einem — und keine davon gut.

Snapshot-Tests und Golden Master¶

Alle Tests bisher hatten eine Erwartung, die jemand aufgeschrieben hat: assert "Es ist dunkel" in .... Dafür muss man wissen, was richtig ist. Es gibt eine Lage, in der man das nicht weiß und trotzdem testen will: fremder, gewachsener Code, den man ändern soll. Was er tut, ist unbekannt; dass er nach der Änderung dasselbe tut, ist die Anforderung.

Die Antwort darauf heißt Golden Master oder Snapshot-Test und dreht die Reihenfolge um: Man nimmt das aktuelle Verhalten auf, schreibt es in eine Datei, checkt sie ein — und vergleicht ab dann jeden Lauf damit. Der Test behauptet nicht, das Verhalten sei richtig. Er behauptet nur, es sei unverändert.

Selbst gebaut braucht das keine Bibliothek, sondern zwölf Zeilen:

Der erste Lauf hat noch keine Vergleichsdatei. Er legt sie an und meldet sich als skipped — nicht als passed, denn bestanden hat er nichts:

Jetzt kommt der Schritt, den man nicht überspringen darf: die aufgenommene Datei lesen. Ein Golden Master friert ein, was da ist — Fehler eingeschlossen. Wer ungeprüft einfriert, hat einen Test, der ab jetzt verlangt, dass der Bug bleibt.

Sieht plausibel aus — also einchecken. Ab dem zweiten Lauf ist es ein echter Test:

Und so sieht es aus, wenn sich das Verhalten ändert. Wir ändern einen Ausgabetext im Programm — eine Änderung, die kein bestehender Test der vorigen Abschnitte bemerkt, weil keiner auf genau diesen Satz prüft:

Der Test sagt genau, was sich geändert hat, und zwar als Diff. Das ist die Stärke des Verfahrens: ein Test deckt die gesamte Ausgabe ab, ohne dass jemand sie Zeile für Zeile beschreiben musste.

Dieselbe Stärke ist die Schwäche. Ein Golden Master sagt nicht, ob eine Änderung richtig ist — nur, dass es eine gibt. Der Arbeitsablauf lautet deshalb immer: Diff ansehen, entscheiden, und bei gewollter Änderung die Datei neu aufnehmen. Genau dafür gibt es Bibliotheken: syrupy ist die verbreitete für pytest, mit snapshot als Fixture und pytest --snapshot-update zum Neuaufnehmen. Der Gewinn gegenüber der Handarbeit oben ist die Verwaltung — viele Snapshots in einer Datei, brauchbare Diffs für Dicts und Objekte, und ein Befehl zum Aktualisieren. Das Prinzip bleibt dasselbe.

Vier Regeln entscheiden darüber, ob solche Tests helfen oder quälen:

• Nichts Schwankendes einfrieren. Zeitstempel, Zufallszahlen, Speicheradressen, Dictionary-Reihenfolgen aus Mengen — alles das macht den Test rot, ohne dass sich etwas geändert hat. Erst injizieren (siehe Zeit und Zufall), dann einfrieren.

• Klein halten. Ein Snapshot über 500 Zeilen wird beim ersten roten Lauf nicht gelesen, sondern aktualisiert. Damit ist der Test wertlos.

• Nie blind aktualisieren. --snapshot-update ohne Blick auf den Diff ist dasselbe wie den Test löschen, nur langsamer.

• Als Netz, nicht als Spezifikation. Ein Golden Master ersetzt keinen Test, der eine Regel festhält. Er ergänzt ihn dort, wo noch niemand die Regeln kennt.

Damit ist das Verfahren vor allem für eines gemacht: Charakterisierungstests für fremden Code, bevor man ihn anfasst. In den Übungen zu Wesen und BamBam ist das der erste Schritt — Verhalten einfrieren, dann refaktorisieren, und der Golden Master meldet, wenn das Refactoring doch keins war.

Property-Based Testing mit hypothesis¶

In der Mathematik und Statistik prüft ein Hypothesentest Daten auf Signifikanz. In der Programmierung meinen wir mit Paketen wie hypothesis jedoch etwas anderes: das Property-Based Testing.

Anstatt fixe Eingabewerte wie [0.5, 0.5] manuell vorzugeben, definieren wir Invarianten (Properties). Das Framework generiert dann systematisch Hunderte bis Tausende von (auch unüblichen) Eingabewerten.

Für unsere Entropie-Funktion gilt beispielsweise die mathematische Invariante: $H(X) \ge 0$ für jede gültige Verteilung.

Damit hypothesis nicht nur Eingaben, sondern sinnvolle Eingaben erzeugt, muss irgendwo stehen, was eine gültige Eingabe ist. Genau das leisten Vor- und Nachbedingungen: Im Kapitel Design by Contract schreiben wir sie an die Funktion, und die Werkzeuge dort leiten daraus die Testfälle ab, die wir hier noch von Hand beschreiben.

Symbolic Execution und formale Verifikation: CrossHair¶

Während hypothesis den Zustandsraum stochastisch abtastet (Property-Based Testing), wählt CrossHair einen analytischen Ansatz. Es übersetzt Python-Bytecode in logische Formeln und nutzt einen SMT-Solver (Z3), um mathematisch zu beweisen, ob ein Fehlerzustand erreichbar ist.

CrossHair harmoniert perfekt mit Design by Contract. Wir können Vor- und Nachbedingungen direkt im Code definieren:

Mutation Testing: Die Qualität der Tests testen¶

Wer testet eigentlich die Tests? Eine hohe Testabdeckung (Coverage) bedeutet nur, dass der Code ausgeführt wurde, nicht, dass die asserts sinnvoll sind. Mutation Testing verändert den Quellcode (die “Mutanten” – z.B. wird ein > durch ein >= ersetzt oder ein + durch ein -) und führt die Tests erneut aus. Wenn die Tests danach nicht fehlschlagen (der Mutant überlebt), fehlt uns ein spezifischer Testfall. Das Tool mutatest automatisierte dies, wird allerdings nicht mehr aktiv gepflegt. Alternativen sind pytest-gremlins, fest und mutmut, die sich durchaus in ihrer Herangehensweise und damit Performance unterscheiden.

Abschnitt für die pyproject.toml um gremlins zu benutzen:

[tool.pytest.ini_options]
addopts = "--gremlins"

Alternativ kann man direkt beim Aufruf von pytest ein --gremlins angeben.

Man muss ein bisschen aufpassen, denn wenn der Testcode selbst mutiert werden kann, gerade in Kombination mit hypothesis, kann es leicht zu Endlosschleifen kommen. Daher schränkt man ein, welche Dateien mutiert werden sollen (das geht leider nicht per Kommandozeilenoptionen):

[tool.pytest-gremlins]
paths = [ "part-tools/entropy.py" ]

Automatisierung und Ökosystem¶

Sobald unsere Test-Suite wächst, wollen wir sie automatisieren und strukturieren.

nox (und tox): Automatisieren das Testen über verschiedene Python-Versionen und getrennte virtuelle Umgebungen hinweg. tox nutzt statische tox.ini-Konfigurationen, während nox reine Python-Skripte (noxfile.py) nutzt.

Continuous Integration Testing¶

Eine exemplarische .gitlab-ci.yml um nur Commits zu erlauben, die erfolgreich alle Tests bestehen:

stages:
  - test

run_tests:
  stage: test
  image: python:3.13-slim
  script:
    - pip install uv
    - uv tool install nox
    - nox -s tests

Der Einsatz von Nox bietet hierbei den Vorteil, dass Testing in einer lokalen Umgebung mit hoher Wahrscheinlichkeit zu den gleichen Ergebnissen kommt wie Testing auf dem Gitlab Runner.

Konfigurationsmanagement mit Hydra¶

Insbesondere im Data Science Bereich und bei Deep Learning Modellen (aber auch in großen Test-Setups) stoßen Kommandozeilenargumente (argparse) schnell an ihre Grenzen. Hydra löst dieses Problem durch hierarchische Komposition von YAML-Dateien. Achtung: Das PyPI-Paket heißt hydra-core, während hydra ein veraltetes anderes Paket ist; das Python-Modul heißt dennoch hydra.

Wir definieren eine Basis-Konfiguration:

Der Clou an Hydra ist, dass wir nun Parameter über die Kommandozeile dynamisch überschreiben können, ohne den Code anzufassen:

Exkurs: Die Rolle von OmegaConf¶

In unserem Skript taucht der Typ DictConfig auf, der aus dem Paket OmegaConf stammt. Hydra nutzt OmegaConf unter der Haube als eigentliche Konfigurations-Engine. OmegaConf bietet weit mehr als nur das simple Einlesen von YAML-Dateien:

1. Variablen-Interpolation: Werte in der Konfiguration können dynamisch aufeinander verweisen (z. B. log_name: ${distribution.type}_experiment).

2. Structured Configs: Hier schließt sich der Kreis zur Typisierung. Durch die Kombination von OmegaConf mit Pythons dataclasses lässt sich ein striktes Schema für die Konfiguration definieren. Falsche Datentypen – etwa die Übergabe eines Strings statt einer Liste für probs – werden dadurch direkt beim Start des Programms abgefangen, noch bevor die erste Codezeile des eigentlichen Experiments ausgeführt wird.

Ausblick: End-to-End (E2E) Browser-Testing:¶

Geht es über reine Logik hinaus in Richtung Web-Anwendungen, sind Frameworks wie Selenium oder zunehmend Playwright der moderne Standard, um Klicks und User-Interaktionen in echten Browser-Engines programmatisch zu testen. Das ist sogar außerhalb von Tests interessant, wenn man Browser automatisieren möchte.

Empfehlenswerte Literatur:

• PyCQA (Python Code Quality Authority): Das Meta-Projekt hinter Tools wie autoflake, isort und bandit - GitHub.

• “Obey the Testing Goat”: Ein hervorragendes, kostenfrei online lesbares Buch über TDD in Python (insb. Webentwicklung): obeythetestinggoat.com.

• Software Engineering at Google: Speziell das Kapitel 11 (Testing Overview) von Adam Bender.

Zusammenfassung und Kontrollfragen¶

1. Der Test entsteht zuerst, und er muss aus dem richtigen Grund fehlschlagen — ein Test, der wegen eines Tippfehlers rot ist, prüft später nicht das, was man glaubt.

2. @pytest.mark.parametrize und Fixtures ersetzen kopierte Tests; tmp_path, monkeypatch und capsys decken genau die Fälle ab, für die man sonst eigene Hilfskonstruktionen baut.

3. Zeit und Zufall werden injiziert, nicht importiert: Ein übergebenes random.Random(seed) macht aus einem gelegentlich fehlschlagenden Test einen deterministischen.

4. Coverage ist eine Untergrenze und kein Qualitätsmaß — vollständig abgedeckter Code kann vollständig falsch sein, und Mutation Testing ist das Werkzeug, das diese Lücke sichtbar macht.

5. Ein Golden Master friert Verhalten ein, ohne es zu beschreiben: das richtige Mittel für fremden Code, bevor man ihn ändert, und wertlos, sobald man den Diff ungeprüft aktualisiert.

Kontrollfragen

1. Ein neu geschriebener Test ist beim ersten Lauf rot. Woran erkennen Sie, dass er aus dem richtigen Grund rot ist, und warum lohnt es sich, das zu prüfen?

2. Ein Test würfelt und schlägt etwa jedes zwanzigste Mal fehl. Was ändern Sie — und zwar an der getesteten Funktion, nicht am Test?

3. Ihre Test-Suite erreicht 100 % Coverage, und pytest --gremlins lässt trotzdem Mutanten überleben. Was bedeutet das, und was fehlt den Tests?