Pipelineschritte mit Assertions testen

Eine Datenpipeline kann ohne Fehler durchlaufen und dennoch unbemerkt falsche Ausgaben erzeugen: etwa wenn Zeilen durch den falschen Filter entfernt werden, eine Spalte mit dem falschen Faktor multipliziert wird oder ein Merge Zeilen dupliziert, weil der Join-Schlüssel nicht eindeutig war. Die einzige Möglichkeit, solche unbemerkten Fehler zu erkennen, besteht darin, Assertions einzubauen, die erwartete Eigenschaften der Daten in jeder Pipelinestufe überprüfen. Assertions machen logische Fehler laut und sofort sichtbar.

Prüfen Sie nach jedem Filterschritt per Assertion, ob die resultierende Zeilenanzahl innerhalb eines erwarteten Bereichs liegt. Zu wenige Zeilen bedeuten, dass der Filter zu aggressiv war; zu viele Zeilen weisen darauf hin, dass ein Join Datensätze dupliziert hat. Drücken Sie den erwarteten Bereich als Anteil der Eingabe aus: Bei fehlerfreien Daten sollte ein Schritt zum Entfernen von Nullwerten beispielsweise nie mehr als 30 % der Zeilen entfernen. Dieser Schutz erkennt unerwartete Änderungen der Datenqualität in vorgelagerten Quellen.

Prüfen Sie nach jeder Transformationsfunktion per Assertion, ob alle erwarteten Ausgabespalten vorhanden sind. Wenn ein Umbenennungsschritt versehentlich den falschen Schlüssel verwendet, fehlt die resultierende Spalte – der Fehler tritt jedoch möglicherweise erst viel später auf, wenn ein anderer Schritt sie verwenden möchte. Eine Assertion direkt nach der Transformation erkennt das Problem an seiner Quelle statt drei Schritte später mit einem verwirrenden KeyError.

Prüfen Sie nach der Berechnung einer Umsatzspalte per Assertion, dass sie nicht negativ ist. Prüfen Sie nach dem Parsen von Datumsangaben, dass diese im erwarteten Jahresbereich liegen. Prüfen Sie nach der Kodierung von Kategorien, dass keine unerwarteten Codes vorkommen. Jede Assertion ist ein Datenvertrag, der das erwartete Verhalten dokumentiert und Verstöße frühzeitig erkennt. Schreiben Sie sie als Assertions und nicht als Print-Anweisungen, damit sie bei automatisierten Pipeline-Ausführungen Fehler auslösen.

Ein häufiger Datenfehler ist ein Many-to-many-Merge, durch den sich die Zeilenanzahl versehentlich vervielfacht. Prüfen Sie nach jedem pd.merge() per Assertion, ob die Zeilenanzahl dem erwarteten Wert entspricht – bei einem Left-Join typischerweise also die Zeilenanzahl des linken DataFrames nicht überschreitet. Prüfen Sie außerdem per Assertion, ob die Schlüsselspalte eindeutig ist, sofern sie es sein sollte, damit Sie versehentliche Cross-Joins sofort erkennen.

Bestimmte Spalten dürfen zu keinem Zeitpunkt der Pipeline Nullwerte enthalten. Prüfen Sie mit df['key_col'].notna().all() nach jedem Schritt, der versehentlich Nullwerte einführen könnte – etwa nach einem Merge, bei dem einige Zeilen nicht zugeordnet werden (wodurch in den verbundenen Spalten NaN entsteht), oder nach einem map()-Aufruf, der für nicht zugeordnete Werte NaN zurückgibt. Machen Sie diese Assertions zu den letzten beiden Zeilen jeder Transformationsfunktion, die diese Spalten verarbeitet.

Schreiben Sie für jede Pipelinefunktion Unit-Tests mit kleinen, von Hand erstellten DataFrames, die die zu testende Logik isolieren. Jeder Test sollte eine minimale Eingabe vorbereiten, die Funktion aufrufen und die Eigenschaften der Ausgabe per Assertion prüfen. Für einfache Pipelines reicht Pythons eingebautes assert aus; bei größeren Projekten verwenden Sie pytest, um vor der Bereitstellung alle Tests automatisch auszuführen.

Gute Tests decken nicht nur den Normalfall, sondern auch Sonderfälle ab: Eingaben mit ausschließlich Nullwerten, leere DataFrames, DataFrames mit einer einzigen Zeile und Spalten mit Extremwerten. Ein leerer DataFrame sollte einen leeren DataFrame zurückgeben und keinen Fehler auslösen. Ein DataFrame mit einer einzigen Zeile sollte das korrekte Ergebnis berechnen. Testen Sie diese Fälle ausdrücklich, damit die Pipeline sie in der Produktion problemlos verarbeitet, wenn ungewöhnliche Daten eintreffen.

Schreiben Sie zusätzlich zu Unit-Tests für einzelne Funktionen einen Integrationstest, der die vollständige Pipeline mit einer kleinen, repräsentativen Stichprobe realer Daten ausführt. Prüfen Sie per Assertion, dass die Ausgabe die erwartete Anzahl von Spalten enthält, die Schlüsselspalte eindeutig ist und der Gesamtumsatz in einem plausiblen Bereich liegt. Diese End-to-End-Prüfung erkennt Fehler im Zusammenspiel der einzelnen Schritte, die Unit-Tests nicht aufdecken.

Wenn die Pipeline wächst, sammeln Sie alle Tests in einem Verzeichnis tests/ und führen Sie sie über die Kommandozeile mit pytest aus. Eine Datei conftest.py kann gemeinsam verwendete Fixtures wie Beispieldaten-Frames erstellen. Integrieren Sie pytest in Ihre CI/CD-Pipeline, damit bei jeder Codeänderung vor der Bereitstellung automatisch alle Tests ausgeführt werden. Ein fehlgeschlagener Test verhindert die Bereitstellung und damit, dass fehlerhafter Code die Produktion erreicht.

Jede Assertion in der Pipeline ist zugleich Schutzmechanismus und Dokumentation: Sie beschreibt in maschinenlesbarer Form, wie die Daten an dieser Stelle aussehen müssen. Wenn eine neue Analystin oder ein neuer Analyst zum Projekt hinzukommt und den Pipeline-Code liest, vermitteln die Assertions die Datenverträge, ohne dass ein separates Spezifikationsdokument erforderlich ist. Behandeln Sie jede Assertion wie einen Kommentar – formulieren Sie die Meldung so aussagekräftig, dass die darin durchgesetzte Geschäftsregel verständlich ist.

Testen Sie Ihr Verständnis der Konzepte zur Datenanalyse aus dieser Lektion.

In dieser Lektion haben Sie gelernt: Prüfungen der Zeilenanzahl, des Vorhandenseins von Spalten, des Wertebereichs und von Nullwerten als Assertions direkt in die Pipeline einzubetten, Unit-Tests für einzelne Transformationsfunktionen mit Abdeckung von Sonderfällen zu schreiben sowie Integrationstests auszuführen und Assertions als lebende Dokumentation von Datenverträgen zu behandeln. Als Nächstes untersuchen wir die Planung und Protokollierung von Pipeline-Ausführungen für die tägliche automatische Ausführung.