Sieben Entscheidungskriterien

Unit, Integration, Contract oder E2E

0:00 Mehr Tests bedeuten nicht automatisch mehr Qualität. Das klingt zunächst wie ein Widerspruch, ist aber eine alltägliche Erfahrung: Eine Testsuite kann tausend Tests umfassen, eine halbe Stunde laufen, regelmäßig ohne echten Grund rot werden — und trotzdem genau den Fehler übersehen, der am Freitagabend in der Produktion auffällt.

0:18 Umgekehrt führt der Verzicht auf realitätsnahe Tests dazu, dass Probleme erst nach der Bereitstellung sichtbar werden. In den nächsten Minuten geht es deshalb nicht um Mengenverhältnisse, sondern um eine Entscheidung: Welches Risiko prüfen wir auf welcher Ebene? Sieben Kriterien führen dorthin. Am Ende haben Sie ein Raster, mit dem Sie Ihre eigene Testsuite durchgehen können.

Vier Testarten, eine Entscheidung

0:40 Bevor wir entscheiden, müssen wir wissen, worüber wir entscheiden. Die vier Begriffe Unit, Integration, Contract und E2E fallen in jedem Planungsgespräch — und bedeuten für jeden im Raum etwas leicht anderes. Dieses erste Kapitel sortiert sie. Nicht nach Framework, nicht nach Ordnerstruktur, sondern nach der Frage, welche Aussage ein Test am Ende tatsächlich belegt. Erst danach lohnt der Blick auf die Kriterien.

1:06 Hier kommt bewusst keine Testpyramide mit Prozentangaben. Der Grund ist einfach: Eine Pyramide beschreibt ein Ergebnis, nicht den Weg dorthin. Stellen Sie sich stattdessen einen Gutachter beim Hauskauf vor. Der misst nicht überall dasselbe, sondern prüft je Bauteil mit dem Mittel, das dort etwas aussagt — Feuchtigkeit anders als Statik.

1:25 Genau so funktioniert ein Entscheidungsprofil: Sie nehmen ein konkretes Risiko, gehen sieben Kriterien durch und bekommen heraus, auf welcher Ebene dieses Risiko zuerst zuverlässig sichtbar wird. Das Ergebnis gilt für Ihre Anwendung und Ihren Lieferprozess, nicht für alle. Die Spalte, auf die es ankommt, ist die mittlere.

1:45 Testarten unterscheiden sich nicht durch ihr Werkzeug, sondern durch ihren Prüfgegenstand — durch das, was am Ende tatsächlich belegt ist. Ein Unit-Test belegt, dass eine Regel stimmt. Ein Integrationstest belegt, dass Ihre Anwendung korrekt angeschlossen ist. Ein Contract Test belegt, dass zwei unabhängig ausgelieferte Releases noch zueinander passen. Und ein E2E-Test belegt, dass ein Nutzer sein Ziel erreicht.

2:11 Vier verschiedene Aussagen — deshalb ersetzt keine die andere. Wer das im Kopf hat, merkt schnell, dass die Frage nach dem richtigen Mengenverhältnis an der Sache vorbeigeht. Jetzt die unbequeme Nachricht: Diese vier Schubladen sind keine Normbegriffe. Es gibt keine Instanz, die festlegt, ab wann ein Test ein Integrationstest ist.

2:32 Ein Test kann drei Schichten durchlaufen, ohne einen Browser zu starten — ist das schon E2E? Ein anderer arbeitet mit einer echten Datenbank und prüft doch nur eine einzige Abfrage. Google löst das elegant, indem es zwei Achsen trennt: wie viel Code geprüft wird, und welche Ressourcen der Test dafür braucht. Das ist mehr als Begriffshygiene.

2:53 Für eine Teamentscheidung sind Umfang, beteiligte Prozesse und reale Abhängigkeiten aussagekräftiger als jedes Etikett. Damit sind wir bei der Umstellung, um die es in diesem Modul eigentlich geht. Die verbreitete Frage lautet: In welchem Verhältnis brauchen wir Unit-, Integrations- und E2E-Tests? Diese Frage ist nicht beantwortbar, weil sie Ihre Architektur, Ihre Risiken und Ihren Lieferprozess gar nicht kennt.

3:18 Die tragfähige Frage lautet: Welches Risiko müssen wir wann, wie zuverlässig und wie günstig erkennen? Der Unterschied ist praktisch, nicht philosophisch. Aus der ersten Frage folgt eine Quote, die niemand begründen kann. Aus der zweiten folgt für jeden einzelnen Test eine Entscheidung, die sich im Review verteidigen lässt.

3:39 In der Praxis hört man vier Argumente, die sich nach Begründung anhören und keine sind. Erstens eine Prozentvorgabe aus einem Konferenzvortrag — sie stammt aus einer anderen Architektur. Zweitens Coverage als Ziel; sie sagt, welcher Code ausgeführt wurde, nicht welches Risiko geprüft ist. Drittens die Testart am Framework-Wissen des Teams ausrichten — dann entscheidet der Werkzeugkasten über die Aussage.

4:04 Und viertens, der häufigste: alles mocken, weil das immer schnell ist und immer grün wird. Genau das sollte misstrauisch machen. Ein Test, der nie rot werden kann, hat auch nie etwas geprüft.

Risiko, Systemgrenze und Realitätsnähe

4:16 Jetzt zu den Kriterien. Die ersten drei gehören zusammen, weil sie dieselbe Entscheidung von drei Seiten beleuchten: Was wollen wir wissen, welche Grenze müssen wir dafür überschreiten, und wie echt muss die Umgebung dabei sein. Wer diese drei beantwortet hat, hat bei den meisten Tests die Ebene schon gefunden. Die restlichen vier Kriterien korrigieren dann nur noch.

4:37 Kriterium eins ist das wichtigste, und es ist eine Frage der Formulierung. Ein Test soll keine Codezeile abdecken, sondern eine benannte Unsicherheit verkleinern. Der Unterschied zeigt sich sofort im Gespräch: „Wir testen den Preisrechner" führt nirgendwohin. „Wir wollen wissen, ob angefangene Minuten falsch gerundet werden" führt direkt zur Ebene.

4:58 Typische Risiken sind falsche Geschäftsregeln, übersehene Grenzfälle, kaputte Migrationen, geänderte Schnittstellen, Framework-Konfiguration, Berechtigungen und gebrochene Abläufe. Behalten Sie die Leitfrage im Kopf: Auf welcher Ebene wird genau dieser Fehler erstmals zuverlässig sichtbar? Erstmals — und zuverlässig. Machen wir es konkret.

5:19 Radnetz begleitet uns durch die nächsten Minuten: ein stationsbasierter Fahrradverleih mit Terminals, einem Verleihdienst, einer Datenbank, einem Schließsystem und einer Partner-API. Lesen Sie die Tabelle nicht als Zuordnung von Themen zu Testarten, sondern als Entscheidungskette. Die Gebührenrundung ist reine Rechnung — dafür braucht niemand Infrastruktur.

5:41 Der verlorene Index dagegen existiert nur in einer echten Datenbank; ein gemockter Repository-Aufruf kann ihn gar nicht bemerken. Und ein umbenanntes Statusfeld im Schließsystem fällt erst dort auf, wo zwei Releases aufeinandertreffen. Jede Zeile hat einen Grund — nicht eine Gewohnheit. Kriterium zwei macht dasselbe etwas mechanischer. Die Schichtung hier ist keine Rangfolge von schlecht nach gut, sondern eine Reihe von Grenzen, und jede kostet etwas.

6:09 Ganz unten bleibt alles im eigenen Prozess — schnell und eindeutig. Eine Ebene höher kommt eine fremde Laufzeit dazu, mit Konfiguration und Transaktionen. Darüber liegt die Vereinbarung zwischen zwei Releases, die niemandem allein gehört. Und oben der komplette Weg durch das System. Die Leitfrage ist eng gestellt: Welche Grenze muss dieser Test wirklich überschreiten, damit seine Aussage trägt?

6:33 Jede Grenze darüber ist bezahlter Aufwand ohne zusätzlichen Nachweis. Hier wird eine Unterscheidung nachgeliefert, die überraschend viel Streit auflöst. Google trennt zwei Dinge, die im Alltag ständig vermischt werden: den Umfang — wie viel Code geprüft wird — und die Größe, also welche Ressourcen der Lauf braucht. Ein kleiner Test darf weder Netzwerk noch Dateisystem anfassen und nicht schlafen; er läuft, so schnell die CPU erlaubt.

6:59 Ein mittlerer darf mehrere Prozesse starten, aber nur auf der eigenen Maschine. Ein großer darf über Maschinen hinweg. Der praktische Gewinn dieser Trennung: Ein Test kann eng sein und trotzdem mittelgroß — etwa eine Repository-Prüfung mit echter Datenbank. Kriterium drei ist die Frage, an der sich die Gemüter erhitzen: mocken oder echt. Nüchtern betrachtet ist ein Test Double ein Protokoll Ihrer Annahmen.

7:24 Das ist wertvoll, solange die Annahme nicht selbst das Risiko ist. Sobald SQL-Dialekt, Constraints, Transaktionen oder eine Migration zur Sache gehören, prüft ein Mock nur noch, ob Sie sich konsistent geirrt haben. Dasselbe gilt für Serialisierung, Messaging, Caching, Authentifizierung und Framework-Konfiguration. Die Leitfrage ist deshalb nicht „echt oder nicht", sondern: Welche reale Komponente kann ich ersetzen, ohne die Aussage zu verlieren? Alles Übrige bleibt echt.

7:54 Und damit zur praktischen Seite. Beide Ausschnitte tun im Grunde dasselbe: Sie stellen genau so viel Umgebung bereit, wie der Prüfgegenstand braucht. Links ein Test Slice von Spring Boot — es lädt nur die Persistenzschicht, kein Web, keine Sicherheit. Das hält den Start kurz und den Fehler eindeutig zuordenbar. Rechts das Gegenstück für den Fall, in dem die Datenbank selbst das Risiko ist: Testcontainers startet eine echte, kurzlebige Instanz für den Testlauf und räumt sie danach wieder ab.

8:23 Achten Sie auf das Muster, nicht auf die Annotationen. Sie wählen bewusst, wie viel Realität Sie einkaufen — und bezahlen nur dafür.

Feedback, Stabilität und Kompatibilität

8:32 Die erste Hälfte hat bestimmt, was ein Test prüft. Die zweite bestimmt, ob das Ergebnis dem Team überhaupt etwas nützt. Denn ein Test, der zu spät antwortet, der unzuverlässig antwortet oder der die falsche Frage beantwortet, ist trotz richtig gewählter Ebene verlorene Arbeit. Die Kriterien vier, fünf und sechs gehen diese drei Fälle durch.

8:53 Kriterium vier räumt mit einer Annahme auf: Nicht jeder Test muss bei jedem Commit laufen. Entscheidend ist nicht Vollständigkeit, sondern wann ein Fehler spätestens auffallen muss, damit seine Behebung noch billig ist. Daraus ergibt sich eine Treppe. Während der Entwicklung läuft nur, was in Sekunden antwortet. Beim Commit die schnellen Tests plus einzelne komponentennahe. Im Pull Request die breiteren und die Vertragsprüfung.

9:18 Vor dem Deployment die Kompatibilität, danach ein paar Rauchproben. DORA nennt zehn Minuten als Richtwert für das Feedback aus automatisierten Tests — kein Naturgesetz, aber ein guter Maßstab für die eigene Pipeline. Kriterium fünf wird am häufigsten unterschätzt. Ein Test hilft nur, wenn das Team seinem Ergebnis glaubt.

9:38 Sobald sich die Gewohnheit einschleicht, eine rote Pipeline erst einmal neu zu starten, ist der Test praktisch abgeschafft — er läuft noch, aber er schützt nichts mehr. Dagegen hilft Handwerk: reproduzierbare Testdaten, Läufe, die sich nicht gegenseitig beeinflussen, kontrollierte Zeit und Zufälle, aussagekräftige Meldungen, nachvollziehbare Traces und eine klare Zuständigkeit für den Fehlschlag.

10:01 Und beachten Sie den Nebeneffekt der Ebene: Ein Unit-Test zeigt fast auf die Zeile. Bei einem breiten Test kommen zwanzig Ursachen infrage. An dieser Stelle lohnt ein realistischer Blick auf Werkzeuge, weil viele Teams hier zu viel erwarten. Playwright etwa gibt jedem Test einen eigenen Browser Context mit eigenem Speicher und eigenen Cookies — Tests können sich also nicht mehr über Anmeldezustände ins Gehege kommen.

10:26 Die Actionability-Prüfungen warten, bis ein Element wirklich sichtbar, stabil, aktiv und treffbar ist, statt ins Leere zu klicken. Wiederholende Assertions und Traces machen Fehlschläge in der Pipeline nachvollziehbar. Das alles beseitigt technische Wackelkandidaten. Was es nicht beseitigt: unklare Erwartungen und ungeeignete Testdaten. Die bleiben Ihre Arbeit.

10:48 Kriterium sechs ist der Punkt, an dem sich verteilte Systeme von allen anderen unterscheiden. Contract Tests werden dort interessant, wo Consumer und Provider in verschiedenen Teams entstehen, unabhängig voneinander ausgeliefert werden, verschiedene Release-Zyklen haben und sich nicht in jeder Pipeline gemeinsam starten lassen.

11:07 Kommuniziert wird über HTTP oder über Nachrichten — also über eine Vereinbarung, die eine Version hat. Und damit ändert sich die Frage grundlegend. Bisher hieß sie: Arbeitet dieser Dienst korrekt? Jetzt heißt sie: Bleiben zwei unabhängig ausgelieferte Releases zueinander kompatibel? Das ist eine andere Aussage, und keine der Ebenen von vorhin liefert sie.

11:29 Es gibt nicht einen Contract Test, sondern drei Wege — und sie unterscheiden sich darin, wer die Vereinbarung festlegt. Beim spezifikationsbasierten Weg ist es die veröffentlichte Beschreibung, etwa eine OpenAPI-Datei; geprüft wird gegen deren Struktur. Beim producer-driven Ansatz definiert der Provider, was er zusagt. Beim consumer-driven Ansatz halten die Consumer fest, was sie tatsächlich benutzen — oft ein Bruchteil dessen, was die Schnittstelle könnte.

11:56 Der praktische Vorteil dieses letzten Wegs: Sie erfahren, welche Änderung wirklich jemandem weh tut. Wichtig bleibt die Abgrenzung: Ein Vertrag prüft die Kommunikation, nicht das gesamte fachliche Verhalten. Genau an dieser Abgrenzung geht es am häufigsten schief. Wenn eine Prüfung aus hundert fachlichen Gründen scheitern kann, entstehen nicht hundert Verträge — sondern zwei, für den positiven und den negativen Fall der Schnittstelle.

12:22 Der Rest gehört in Unit-Tests. Zweiter Fehler: Stubs selbst schreiben. Dann prüfen Sie Ihre Vorstellung vom Provider, nicht den Provider; der Sinn des Verfahrens liegt darin, dass die Stubs auf der Providerseite entstehen und dort verifiziert sind. Dritter Fehler: Verträge ablegen, ohne sie zu einem Tor zu machen — Pact kann mit can-i-deploy vor dem Deployment beantworten, ob zwei Versionen zusammenpassen.

Wartungsaufwand, Matrix und KI-Leitplanken

12:46 Sechs Kriterien haben bestimmt, welcher Test etwas nachweist. Das siebte fragt, was er auf Dauer kostet — und das ist die Frage, die eine Testsuite vor dem Ersticken bewahrt. Danach fassen wir alles in einer Matrix zusammen und schauen zum Schluss darauf, wo KI in der Testentwicklung hilft und wo sie gefährlich wird. Kriterium sieben ist unbeliebt, weil es gegen den Reflex arbeitet, ein Test mehr sei immer gut. Geschrieben wird ein Test einmal.

13:13 Danach wird er verstanden, ausgeführt, analysiert, an fachliche Änderungen angepasst, bei technischen Umbauten stabilisiert und dauerhaft mit Testdaten und Umgebungen versorgt. Jeder Lauf kostet Zeit in der Pipeline, jeder Fehlschlag kostet Aufmerksamkeit. Deshalb die Leitfrage: Liefert dieser Test einen zusätzlichen Nachweis?

13:32 Oder wiederholt er langsamer, teurer und instabiler eine Prüfung, die weiter unten längst existiert? Im zweiten Fall ist Löschen die richtige Änderung — auch wenn sich das falsch anfühlt. Daraus wird eine Bewegung, und die Richtung ist immer dieselbe: nach unten, wo es geht. Fachliche Varianten und Grenzfälle gehören dorthin, wo sie in Millisekunden laufen.

13:55 Infrastrukturverhalten gehört in gezielte Integrationstests, nicht in den Browser. Schnittstellenkompatibilität gehört in Verträge mit einem Tor davor. Und für E2E-Tests bleiben die wenigen Abläufe, deren Ausfall wirklich Geld oder Vertrauen kostet. Was gar nicht automatisiert wird, ist die explorative und fachliche Prüfung — die bleibt menschliche Arbeit. Google nennt als Orientierung grob achtzig, fünfzehn und fünf Prozent.

14:22 Als Orientierung, nicht als Vorgabe. Diese Tabelle ist der Zettel, den Sie behalten sollten — aber lesen Sie sie richtig. Sie ist keine Regelsammlung, sondern das häufigste Ergebnis der sieben Kriterien, zusammengefasst. Wenn Ihr Fall anders liegt, gewinnen die Kriterien und nicht die Zeile. Der eigentliche Wert liegt im Gespräch: Wenn jemand einen Browser-Test für eine Rundungsregel vorschlägt, haben Sie eine Zeile, auf die Sie zeigen können, ohne über Geschmack zu diskutieren.

14:50 Und achten Sie auf die letzte Zeile. Viele Varianten desselben Ablaufs sind der klassische Weg, auf dem eine E2E-Suite unbemerkt auf vierzig Minuten Laufzeit wächst. Zum Schluss ein Thema, das gerade jede Teststrategie betrifft. KI-Assistenten sind bei bestimmten Aufgaben tatsächlich stark: Grenz- und Fehlerfälle sammeln, Tests aus Akzeptanzkriterien ableiten, Testdaten erzeugen, Coverage-Lücken sichten, Gerüste für Verträge vorbereiten und Traces fehlgeschlagener Läufe durchsehen.

15:18 Playwright hat das inzwischen in eigene Test-Agenten gegossen: Ein Planner erkundet die Anwendung und schreibt einen Plan, ein Generator macht daraus ausführbare Tests, ein Healer nimmt sich fehlschlagende Tests vor und flickt sie. Das ist echte Entlastung bei der mühsamen Hälfte der Arbeit — und genau deshalb lohnt der nächste Blick.

15:37 Denn der Healer ist auch das Beispiel, an dem das Verfahren kippen kann. GitHub formuliert es für seine Agenten ausdrücklich: Generierter Code kann gültig aussehen und trotzdem semantisch oder syntaktisch falsch sein, und er kann Sicherheitslücken enthalten. Ausgaben müssen geprüft und ausgeführt werden, bevor sie zusammengeführt werden. Für Tests hat dieser Satz eine besondere Schärfe. Bei normalem Code prüft der Test die Änderung.

16:02 Beim Test selbst fehlt diese zweite Instanz — er ist die Instanz. Wer hier ungeprüft übernimmt, verliert nicht ein Feature, sondern das Frühwarnsystem für alle künftigen. Daraus folgen vier Grenzen, und im Kern sind sie alle dieselbe. Erstens: Das Testorakel — also die Aussage, was richtig ist — darf nicht aus dem Implementierungscode kommen.

16:23 Sonst schreibt der Code seine eigene Prüfung, und jeder Fehler wird zur Spezifikation. Zweitens: Eine geheilte Assertion wird fachlich geprüft, denn ein Agent darf nicht entscheiden, dass verändertes Verhalten korrekt ist, nur weil ein Test sich anpassen lässt. Drittens: Ein Test, der noch nie nachweislich fehlschlagen konnte, hat nichts belegt. Und viertens: Coverage bleibt ein Hinweis auf ungeprüfte Stellen, nie ein Qualitätsbeweis.

Übung

16:50 Bleibt der Teil, der aus Zuhören eine Entscheidung macht. Sieben Kriterien einmal gehört zu haben, verändert wenig — angewandt auf eine konkrete Änderung in einer konkreten Anwendung verändern sie sofort, welche Tests Sie schreiben und welche Sie sich sparen. Nehmen Sie dafür am besten einen eigenen Fall. Wer gerade keinen zur Hand hat, nimmt unseren Fahrradverleih.

17:12 Zur Erinnerung der Aufbau: Radnetz betreibt einen stationsbasierten Fahrradverleih. An jeder Station steht ein Terminal, dahinter liegen ein Verleihdienst, eine PostgreSQL-Datenbank, ein Schließsystem, das ein anderes Team separat entwickelt und ausliefert, und eine Partner-API für Dritte. Neu eingeführt wird eine Kulanzfrist bei verspäteter Rückgabe — auf dem Papier eine Kleinigkeit, in der Wirkung ein Eingriff in Gebührenberechnung, Datenmodell, Schließvorgang und Abrechnung.

17:39 Genau solche harmlos aussehenden Änderungen sind die interessanten Fälle, weil sie quer durch alle vier Testebenen schneiden. Die Reihenfolge der Schritte ist bewusst so gewählt, dass die Ebene am Ende herausfällt und nicht am Anfang gesetzt wird. Zuerst also fünf Risiken benennen, und zwar jedes als konkret möglichen Fehler, nicht als Thema. Dann je Risiko die Ebene bestimmen, auf der es erstmals zuverlässig auffällt.

18:03 Dann entscheiden, welche Abhängigkeit ersetzt wird und wo echte Infrastruktur nötig ist. Dann jeden Test einer Stufe der Pipeline zuordnen. Und zuletzt der Schritt, den fast alle überspringen: markieren, welche vorhandenen Tests dieselbe Aussage teurer wiederholen. Dort liegt in den meisten Suiten die schnellste Verbesserung.

18:23 Die Fähigkeit, die hier geübt wird, ist nicht das Zuordnen — das geht schnell. Es ist das Begründen: Warum diese Ebene und nicht die darüber? Denn diese Begründung brauchen Sie später im Review, wenn jemand einen Browser-Test für eine Rechenregel möchte. Fertig sind Sie, wenn für fünf Risiken schriftlich festgehalten ist, welche Ebene sie prüft, welche Abhängigkeiten dabei ersetzt werden, in welcher Stufe der Pipeline der Test läuft und warum es genau diese Ebene sein muss.

18:51 Dazu drei Tests, die Sie als redundant markieren. Nehmen Sie sich die drei bewusst vor — sie sind der Teil, der Zeit zurückgibt.

Und jetzt?

18:59 Fassen wir zusammen: Was Sie mitnehmen, ist kein Mengenverhältnis, sondern ein Verfahren. Sie benennen ein Risiko, gehen sieben Kriterien durch und bekommen eine Ebene samt Begründung. Das ist unbequemer als eine Quote, hält aber auch dann, wenn sich Architektur und Team ändern. Wenn Sie an dieser Stelle merken, dass für die Umsetzung das Handwerk fehlt — Test Slices, Testcontainers, sauberes Stubbing, verlässliche Integrationstests —, dann ist das Seminar Java Testing mit JUnit, Mockito und Testcontainers der nächste Schritt.

19:30 Besonders lohnt es dort, wo die Suite lange läuft und Fehler trotzdem durchkommen. Alles Weitere finden Sie auf learning-master.de.