Wie testest du einen Spring-Service, der eine Datenbank nutzt und eine andere API aufruft?

Test die Domänenlogik mit schlichtem JUnit ohne Spring-Kontext, denn Constructor Injection macht das trivial. Test Persistenz gegen eine echte Datenbank in einem Container statt gegen einen In-Memory-Ersatz, denn Dialekte unterscheiden sich und Migrationen müssen ebenfalls getestet werden. Nimm Test Slices, statt für Controller- oder Repository-Tests die ganze Anwendung hochzufahren, und stub die externe API auf HTTP-Ebene, damit dein Client-Code, die Retries und das Parsing wirklich laufen.

Der Großteil der Logik bekommt schlichte Unit-Tests ganz ohne Framework: Constructor Injection heißt, ich kann die Klasse mit Test-Doubles für ihre Mitspieler instanziieren und sie läuft in Millisekunden. Für Persistenz nehme ich eine echte Datenbank derselben Engine und Version in einem Container, mit Migrationen als Teil des Test-Setups, damit die Migration selbst bei jedem Lauf verifiziert wird. Eine In-Memory-Datenbank ist schneller, aber sie lügt über Dialekte und Constraints, und ich habe deswegen schon eine Query ausgeliefert, die im Test lief und in Produktion scheiterte. Für die Web-Schicht nutze ich eine Slice, die nur den Controller und die Serialisierung lädt, nicht die ganze Anwendung, denn für jeden Test alles hochzufahren ist der Grund, warum Suites zwanzig Minuten brauchen. Die externe API wird auf HTTP-Ebene mit einem Mock-Server gestubbt, damit meine Client-Konfiguration, Timeouts, Retry-Logik und JSON-Mapping echt durchlaufen. Ich nutze Container über den Lauf hinweg wieder und rolle jeden Test in einer Transaktion zurück, was Isolation und Parallelisierbarkeit erhält.