Teststrategie für APIs entwickeln

Teststrategie für APIs entwickeln

0:00 Willkommen zum dritten Tag. Bis hierher haben wir entworfen und beschrieben — heute geht es darum, wie man beides absichert. Und ich möchte gleich mit einer Umformulierung der üblichen Frage beginnen. Sie lautet nicht: Wie viel testen wir? Sie lautet: Welche Zusage prüfen wir auf welcher Stufe? Denn die typische Krankheit gewachsener Testlandschaften ist nicht zu wenig Testen, sondern dasselbe dreimal zu testen und das Entscheidende gar nicht.

0:26 Am Ende dieses Moduls haben Sie eine Teststrategie auf einer Seite.

Teststrategie für APIs entwickeln

0:31 Der dritte Tag hat ein klares Ziel: Verträge automatisiert prüfen und kontrolliert weiterentwickeln. Wir beginnen mit der Landkarte — welche Testarten gibt es und welche Frage beantwortet jede. Danach klären wir, welche Testfälle eine API wirklich braucht und wie Testdaten beherrschbar bleiben. Und zum Schluss die Quality Gates: Welche Prüfung darf eine Auslieferung aufhalten? Auf dieser Grundlage kommen dann Pact und Spring Cloud Contract.

Testarten einordnen

0:58 Fangen wir mit der Einordnung an. Contract Tests sind heute unser Hauptthema, und um sie zu verstehen, muss man wissen, wovon sie sich abgrenzen — und was sie ausdrücklich nicht leisten. Denn Contract Tests sind kein Ersatz für funktionale Tests, sondern eine eigene Stufe mit einer eigenen Frage. Wer beides vermischt, bekommt Tests, die ständig brechen.

1:19 Die Pact-Dokumentation formuliert die Abgrenzung sehr klar: Contract Tests prüfen die Nachrichten zwischen Consumer und Provider — funktionale Tests prüfen zusätzlich, dass die richtigen Wirkungen eingetreten sind. Das ist der ganze Unterschied, und er ist folgenreich. Ein Contract Test stellt fest, dass die Bestellung im richtigen Format angefragt und beantwortet wird.

1:41 Ob danach wirklich eine Kiste gepackt wird, prüft er nicht — und soll er auch nicht. Wer das vermischt, bekommt Contract Tests, die bei jeder Logikänderung brechen. Die mittlere Spalte ist der Kern dieser Tabelle: Jede Stufe hat genau eine Frage. Wenn Sie eine bestehende Testlandschaft aufräumen wollen, gehen Sie jeden Test durch und fragen, welche dieser Fragen er beantwortet.

2:03 Sie werden feststellen, dass viele Tests zwei oder drei gleichzeitig beantworten wollen — und deshalb langsam und instabil sind. Die Fußnote nennt den Preis der oberen Stufen: Sie sind teurer, und ein roter Lauf sagt selten, wo das Problem liegt. Deshalb schiebt man Prüfungen nach unten, wo es geht. Der erste Punkt ist der praktische Hauptgewinn: Sie brauchen die Gegenseite nicht laufend.

2:26 Kein gemeinsames Testsystem, keine Terminabstimmung, keine Frage, welcher Stand gerade dort deployt ist. Der dritte Punkt ist der zeitliche: Ein Bruch fällt vor dem Deployment auf, nicht danach. Und der vierte ist eine Warnung, die die Pact-Dokumentation selbst ausspricht: Contract Tests ersetzen keine funktionalen Tests des Providers.

2:46 Wer nach der Einführung von Contract Tests seine Providertests abbaut, hat die Sache missverstanden. Der zweite Punkt greift der morgigen Diskussion vor und ist der häufigste Anfängerfehler bei Contract Tests: Validierungsregeln zu prüfen. Wenn Ihr Contract Test die genaue Fehlermeldung bei einem zu langen Namen festschreibt, dann bricht er, sobald der Provider seinen Text ändert — obwohl sich am Vertrag nichts geändert hat.

3:10 Der dritte Punkt beschreibt eine schleichende Entwicklung: Fehlt eine Stufe, wandern ihre Fragen nach oben. Meist landen sie in End-to-End-Tests, und die werden dann immer länger und immer wackliger.

Testfälle und Testdaten

3:22 Weiter mit der Frage, was man eigentlich testet. Und mit dem Thema, das in jeder Retrospektive vorkommt und trotzdem selten systematisch angegangen wird: Testdaten. Dabei geht es weniger um Vollständigkeit als um Auswahl: Welche Arten von Fällen braucht eine API wirklich, und wie hält man die Daten dafür beherrschbar? Der Konformitätstest ist die direkte Fortsetzung dessen, was wir gestern in Modul 8 offen gelassen haben.

3:47 Er prüft die laufende Anwendung gegen ihre OpenAPI-Beschreibung: Stimmen Statuscodes, Medientypen und Antwortschemas mit dem überein, was der Vertrag zusagt? Damit schließt er die Lücke zwischen Beschreibung und Wirklichkeit — und zwar automatisiert, ohne dass jemand beide Seiten von Hand vergleicht. Es ist die günstigste Prüfung dieser Art, weil sie den Vertrag nutzt, den Sie ohnehin schon haben.

4:10 Vier Kategorien, und die Reihenfolge ist bewusst gewählt. Der Erfolgsfall ist selbstverständlich. Grenzwerte gehören dorthin, wo Ihr Schema Grenzen zieht — nicht überall, sondern genau dort. Der dritte Punkt ist der, den ich für den wichtigsten halte: je Fehlerantwort ein Fall. Denn Fehlerantworten sind die Zusagen, auf die sich Consumer im Betrieb verlassen, und sie sind fast immer die am schlechtesten getesteten.

4:35 Und der vierte adressiert die Lücke aus Modul 9: ein Berechtigungsfall, der die Objektebene wirklich trifft — nicht nur einen fehlenden Token. Der erste Schritt ist der entscheidende und wird am häufigsten verletzt: Ausgangszustand ausdrücklich herstellen. Tests, die einen vorhandenen Datenbestand voraussetzen, funktionieren so lange, bis jemand die Umgebung neu aufsetzt.

4:57 Der zweite Schritt ist ein eleganter Nebeneffekt: Wenn Sie Testdaten über die eigene API anlegen, testen Sie das Anlegen gleich mit. Und der letzte Schritt ist keine Empfehlung, sondern eine Pflicht — Produktivdaten in Testumgebungen sind ein Datenschutzproblem, unabhängig davon, wie gut die Umgebung abgesichert ist. Der erste Punkt beschreibt den Zustand, in dem viele Projekte irgendwann sind: Tests hängen an handgepflegten Datenbeständen, die niemand mehr anzurühren wagt.

5:25 Der dritte Punkt ist die Verschwendung, die man beim Aufräumen zuerst findet — dieselbe Prüfung auf drei Stufen. Sie kostet dreimal Laufzeit und bringt einmal Erkenntnis. Und der vierte ist die unangenehme Variante des Testdatenproblems: ein Produktivauszug mit echten Namen. Das passiert nie mit böser Absicht, sondern weil realistische Daten so praktisch sind.

Quality Gates festlegen

5:46 Zum Abschluss die Frage der Konsequenz. Eine Prüfung, die läuft, aber nichts aufhält, ist Beschäftigung. Sehen wir uns an, was ein Gate ausmacht — und was es kaputt macht. Die Frage dahinter ist unbequem: Welche Ihrer heutigen Prüfungen würde eine Auslieferung tatsächlich stoppen — und welche produzieren nur Ausgaben, die niemand liest?

6:07 Die Definition nennt drei Bedingungen, und alle drei müssen erfüllt sein. Schnell genug, damit niemand in Versuchung kommt, es zu umgehen. Verlässlich, denn ein Gate, das gelegentlich grundlos rot ist, wird nach dem dritten Mal ignoriert. Und mit klarer Handlungsfolge — wer rot sieht, muss wissen, was jetzt zu tun ist. Fehlt eine dieser Bedingungen, entsteht kein Gate, sondern ein Ärgernis.

6:31 Und Ärgernisse werden in Organisationen zuverlässig umgangen, meist mit einer gut gemeinten Sonderregel. Die Reihenfolge dieser Kette ist nicht beliebig, sondern nach Kosten sortiert. Validieren dauert Sekunden, Linting auch. Contract Tests brauchen länger. Wenn schon die Validierung fehlschlägt, muss niemand auf die teuren Schritte warten.

6:52 Diese Sortierung klingt banal und macht in der Praxis den Unterschied zwischen einer Pipeline, die in zwei Minuten Bescheid gibt, und einer, die zwanzig Minuten läuft, um dann an einem Tippfehler zu scheitern. Die Freigabe am Ende füllen wir im nächsten Modul mit Leben. Der erste Punkt räumt mit einer beliebten Kennzahl auf: Die Zahl geprüfter Endpunkte sagt nichts über die Qualität der Zusagen.

7:15 Vierzig Endpunkte mit je einem Erfolgsfall sind hundert Prozent Endpunktabdeckung und trotzdem kaum etwas wert. Der zweite Punkt ist die konkrete Lücke dahinter — Fehlerpfade sind meist ungetestet, obwohl Consumer sie am ehesten treffen. Und der dritte ist ein Klassiker: Tests laufen mit Administratorrechten, und die gesamte Berechtigungsprüfung ist damit blind.

7:36 Was Sie prüfen wollen, ist gerade der eingeschränkte Fall. Die ersten drei Punkte beschreiben die drei Wege, auf denen ein Gate seine Wirkung verliert: Es steht auf Warnung, es dauert zu lang, oder ein instabiler Test wird so lange wiederholt, bis er grün ist. Der dritte ist der gefährlichste, weil er wie Pragmatismus aussieht — und weil ein instabiler Test irgendwann ein echtes Problem verdeckt.

7:58 Und der vierte ist die organisatorische Lücke: Wenn niemand zuständig ist, bleibt ein rotes Gate im Hauptzweig stehen, und alle gewöhnen sich daran.

Übung

8:07 Jetzt bringen Sie das zusammen. Eine Seite, die im Team gilt — nicht ein Konzept, das niemand liest, sondern eine Zuordnung, an die man sich hält. Und sie soll auf eine einzige Seite passen. Was länger ist, wird nicht gelesen — und gilt damit im Alltag auch nicht. Ihre Aufgabe ist, die Zusagen der Hofkiste-API aus den bisherigen Modulen auf Teststufen zu verteilen.

8:30 Für jede Stufe halten Sie fest, was sie prüft und — das ist der ungewöhnliche Teil — was sie ausdrücklich nicht prüft. Dazu benennen Sie, welche Prüfung eine Auslieferung aufhalten darf. Als Erweiterung nehmen Sie zwei bestehende Tests aus Ihrem eigenen Projekt und entscheiden, ob sie eine Stufe tiefer gehören. Diese Frage ist meist die produktivste des ganzen Tages.

8:52 Der dritte Schritt ist der, an dem es interessant wird: die Nicht-Ziele. Aufzuschreiben, was eine Stufe nicht prüft, fühlt sich zunächst überflüssig an. Es ist aber das Einzige, was verhindert, dass die Stufen wieder zusammenwachsen — denn im Alltag ist die Versuchung groß, eine Prüfung dort zu ergänzen, wo gerade ein Test steht.

9:11 Der vierte Schritt zwingt zur Ehrlichkeit über Laufzeiten. Ein Gate, dessen Laufzeit Sie nicht abschätzen können, haben Sie nicht durchdacht. Der erste Punkt ist der Reflex, dem fast jede Gruppe erliegt: Jede Zusage landet auf mehreren Stufen, weil sich niemand traut zu streichen. Das Ergebnis ist keine Strategie, sondern eine Wunschliste.

9:31 Der zweite Punkt ist eine Verwechslung von Mittel und Zweck — eine Strategie, die Werkzeuge aufzählt, sagt nichts über Aussagen. Und der dritte ist die Konsequenz eines fehlenden dritten Schritts: Ohne Nicht-Ziele wachsen die Stufen innerhalb weniger Monate wieder zusammen.