Wie sieht deine Teststrategie in einer Full-Stack-Anwendung aus?

Gewichte nach Risiko statt nach Pyramiden-Dogma. Unit-Tests für reine Logik und Randfälle, eine solide Schicht Integrationstests gegen eine echte Datenbank im Container, und eine kleine Zahl End-to-End-Tests für die Abläufe, die Geld kosten, wenn sie brechen, etwa Registrierung, Checkout und Login. Mocke Fremdsysteme an der Netzwerkgrenze statt deine eigenen Module zu stubben.

Meine Leitregel ist, dass ein Test es wert ist, wenn er einen Bug gefangen hätte, den wir plausibel ausliefern. Reine Logik, Preisregeln, Datumsbehandlung, Berechtigungsprüfungen, bekommt schnelle Unit-Tests mit den fiesen Randfällen. Die Schicht, in die ich am meisten investiere, ist Integration: echter HTTP-Request in die App, echtes Postgres in einem Container, echte Migrationen, dann Response und resultierende Zeilen prüfen. Das fängt die Dinge, die Mocks verbergen, etwa eine Constraint-Verletzung oder eine Query, die still nichts zurückgibt. Fremdsysteme mocke ich an der Netzwerkgrenze, mit so etwas wie MSW oder einem aufgezeichneten Fixture, niemals indem ich meine eigene Service-Klasse stubbe, denn dann teste ich den Mock. End-to-End halte ich bewusst klein, vielleicht acht Journeys über Registrierung, Login, Checkout und den Kernworkflow, laufend bei jedem Merge. Bei Flakiness bin ich gnadenlos; ein Test, der zufällig scheitert, erzieht Leute dazu, die Pipeline neu zu starten, ich repariere oder lösche ihn also binnen eines Tages. Coverage sehe ich als Diagnose, nie als Ziel.