Wie entscheidest du, was du mit Unit Tests und was mit Integrationstests abdeckst?

Unit-teste Logik mit Verzweigungen und Randfällen: Preisregeln, Parsing, Zustandsautomaten. Integrationsteste die Nähte, an denen deine Annahmen auf die Realität treffen: Datenbankabfragen, Serialisierung, Auth-Middleware, Clients von Drittanbietern. Wenn ein Test fünf Mocks zum Laufen braucht, testet er vor allem deine Mocks, und der Wert steckt stattdessen in einem Integrationstest. Ziel sind viele schnelle Unit Tests plus ein kleinerer Satz Integrationstests über die kritischen Pfade.

Ich teile danach auf, wo das Risiko liegt. Liegt das Risiko in der Logik, in Verzweigungen, Rundung, Randfällen eines Zustandsautomaten, ist das ein Unit Test, und er sollte schnell genug sein, dass ich beim Speichern die ganze Datei laufen lasse. Liegt das Risiko an einer Naht, ob mein SQL wirklich zurückgibt was ich denke, ob JSON so serialisiert wie der Client es erwartet, ob die Middleware ein abgelaufenes Token ablehnt, ist das ein Integrationstest mit einer echten Datenbank im Container. Meine Heuristik ist die Mock-Zahl: Wenn ich vier Mocks brauche, damit ein Test läuft, assertiert dieser Test mein mentales Modell dieser vier Dinge, und genau mein mentales Modell ist das Falsche, wenn es in Produktion kracht. Ich versuche auch, ehrlich zu sein, was ich nicht teste. Ein dünner Controller, der nur durchreicht, oder ein Getter ist nebenbei abgedeckt, und ihn separat zu testen ist Wartungsaufwand ohne Signal. Die Suite, die ich will, sind viele schnelle Unit Tests und vielleicht zwanzig Integrationstests über die Pfade, an denen Geld oder Auth hängen.