Wie testest du, dass zwei Services noch zusammenarbeiten, ohne das ganze System hochzufahren?

Nimm Contract Testing. Der Consumer definiert die Requests, die er stellt, und die Antwortform, von der er abhängt, diese Erwartung wird als Contract veröffentlicht, und der Provider verifiziert sie in seiner eigenen Pipeline. Beide Seiten testen dann unabhängig und schnell, und eine brechende Änderung lässt den Build des Providers scheitern, statt Tage später in einer geteilten Umgebung aufzutauchen.

Volle End-to-End-Umgebungen skalieren nicht über eine Handvoll Services hinaus. Sie sind langsam, sie brauchen den neuesten Build jedes Teams gleichzeitig gesund, und wenn etwas rot wird, ist die erste Frage immer, ob es ein echter Defekt ist oder die Umgebung. Contract Testing umgeht das. Der Consumer schreibt Tests gegen einen lokalen Stub des Providers, und diese Interaktionen werden als Contract festgehalten: für diesen Request hänge ich von diesen Feldern mit diesen Typen ab. Dieser Contract wird veröffentlicht, und die eigene Pipeline des Providers spielt ihn gegen die echte Provider-Implementierung ab. Benennt jemand ein Feld um oder ändert einen Typ, scheitert sein Build, in seinem Repo, Minuten nach der Änderung, mit einer Meldung, die den brechenden Consumer benennt. Genau das ist der ganze Wert: das Feedback landet dort, wo die Änderung gemacht wurde. Die Nuance, die man sagen sollte, ist, dass ein Contract nur abdeckt, was der Consumer tatsächlich nutzt, nicht die volle Oberfläche des Providers, er ersetzt also nicht dessen eigene funktionale Tests, und er verifiziert Kompatibilität und nicht fachliche Korrektheit. Eine kleine End-to-End-Suite behalte ich weiterhin für die wenigen Journeys, die wirklich über Services hinweg belegt werden müssen.