Tests von Controllern: Einheitentests für robustere Anwendungen
Wenn ich Tests von Controllern mache, geht es mir nicht um akademische Perfektion. Es geht mir um ein simples Ziel: weniger Bugs, weniger Angst beim Deployen, schnellere Entwicklung. Genau dafür sind Einheitentests für Controller stark. Sie geben mir Feedback, bevor kaputter Code in Produktion landet.
Warum ich Controller teste
Controller sind die Schicht, in der oft alles zusammenläuft: Request annehmen, validieren, Daten holen, Response bauen. Wenn hier etwas schiefgeht, merkt es der Nutzer sofort. Ich teste Controller deshalb nicht, weil es „sauber“ aussieht. Ich teste sie, weil sie ein Risiko sind.
Ein guter Controller-Test beantwortet nur eine Frage: Wenn ein Request reinkommt, kommt das Richtige raus? Mehr muss er nicht tun. Genau das macht ihn schnell und wertvoll.
Was ich mit Einheitentests für Controller absichere
Bei Einheitentests fuer robustere Anwendungen prüfe ich vor allem das Verhalten des Controllers selbst. Nicht die Datenbank. Nicht den kompletten Stack. Nur die Logik im Controller und die Interaktion mit seinen Abhängigkeiten.
- Validierung: Sind Pflichtfelder da? Werden falsche Eingaben sauber abgefangen?
- Weitergabe von Daten: Kommen Parameter korrekt im Service an?
- Response-Status: Liefert der Controller 200, 201, 400 oder 404, wenn er soll?
- Fehlerfälle: Was passiert bei leeren Eingaben, Exceptions oder ungültigen IDs?
- Mapping: Werden DTOs oder View-Modelle richtig aufgebaut?
Wenn diese Punkte stabil sind, wird die Anwendung robuster. Nicht perfekt. Robust.
So teste ich Controller in der Praxis
Ich halte Controller-Tests klein. Ein Test soll genau ein Verhalten prüfen. Nicht zehn. Nicht alles gleichzeitig. Sonst wird er teuer, fragil und nutzlos.
- Controller isolieren
Ich mocke Abhängigkeiten wie Services oder Repositories. Der Controller soll nicht an echte Infrastruktur gekoppelt sein. - Input definieren
Ich gebe dem Controller einen klaren Request oder ein Input-Objekt. - Erwartung formulieren
Ich prüfe Statuscode, Body, Weitergabe an den Service und Fehlerverhalten. - Edge Cases testen
Ich teste nicht nur den Happy Path. Gerade die kaputten Fälle bringen den Wert.
Das Prinzip ist simpel: wenig Setup, klare Erwartung, schneller Test. Genau das macht den Unterschied zwischen nützlichen Tests und Test-Müll.
Die häufigsten Fehler bei Tests von Controllern
Ich sehe immer wieder dieselben Probleme. Die meisten Teams testen zu viel oder das Falsche.
- Zu viele Abhängigkeiten: Wenn der Test die halbe Anwendung startet, ist es kein Einheitentest mehr.
- Zu viel Mocking: Wenn alles gemockt ist, prüfst du oft nur deine Erwartungen, nicht das Verhalten.
- Zu große Tests: Ein Test mit vielen Assertions ist schwer zu lesen und schwer zu warten.
- Kein Fehlerfall: Nur Happy Paths zu testen ist gefährlich. Bugs sitzen meist im Randfall.
- Keine klare Struktur: Ohne Arrange, Act, Assert wird jeder Test unnötig chaotisch.
Was ich an Controller-Tests konkret mag
Ich mag Controller-Tests, weil sie mir Geschwindigkeit geben. Wenn ich eine Route ändere oder eine Validierung anpasse, weiß ich sofort, ob ich etwas kaputt gemacht habe. Das spart Zeit. Und Zeit ist Hebel.
Außerdem helfen sie mir beim Refactoring. Wenn ich intern Services umbauen will, aber die Controller-Tests grün bleiben, kann ich schnell arbeiten. Weniger Unsicherheit = mehr Output.
Wie viele Tests sind genug?
Die richtige Frage ist nicht: „Wie viele Tests brauche ich?“ Die richtige Frage ist: Welche kritischen Pfade müssen abgesichert sein?
Ich teste zuerst alles, was Umsatz, Nutzererlebnis oder Stabilität direkt beeinflusst:
- Login und Authentifizierung
- Formular-Validierung
- kritische API-Endpunkte
- Fehlerbehandlung bei externen Aufrufen
- Schlüssel-Workflows mit vielen Abhängigkeiten
Wenn diese Wege stabil sind, habe ich den größten Teil des Risikos abgedeckt.
Ein gutes Testmuster für Controller
Ich nutze gern ein einfaches Muster, das fast immer funktioniert:
- Given: Ich bereite Eingabe und Mock-Verhalten vor.
- When: Ich rufe die Controller-Methode auf.
- Then: Ich prüfe Response, Aufruf an Abhängigkeiten und Fehlerfälle.
Das ist nicht fancy. Muss es auch nicht sein. Es funktioniert.
Welche Ressourcen ich dafür nutze
Wenn ich Controller-Tests schreibe, arbeite ich oft mit den offiziellen Doku-Seiten der verwendeten Tools. Für allgemeine Testprinzipien ist die Test Pyramid von Martin Fowler ein guter Startpunkt. Für Java-Teams ist JUnit 5 direkt hilfreich. Für Mocking schaue ich auf Mockito. Und bei Spring-Controllern ist die Spring Test Documentation die saubere Referenz.
Mein Fazit zu Tests von Controllern
Ich will keine perfekten Tests. Ich will Tests, die mir schnell sagen, ob mein Controller das tut, was er soll. Genau deshalb sind Tests von Controllern so wertvoll. Sie sind klein, schnell und direkt. Richtig eingesetzt machen sie Anwendungen robuster, Refactoring leichter und Releases sicherer.
Wenn du nur einen Teil deiner Anwendung konsequent testest, dann fang hier an. Controller sind nah am Nutzer. Fehler hier sind teuer. Gute Einheitentests fuer robustere Anwendungen zahlen sich sofort aus.