Einzeln getestete Module sind kein Beweis dafür, dass das Gesamtsystem funktioniert. Genau an den Schnittstellen entstehen die Fehler, die im Unit-Test unsichtbar bleiben: falsche Datenformate, unerwartete Statuscodes, brüchige Verträge zwischen Services. Der Integrationstest deckt diese Lücken auf, bevor sie in Produktion landen. Für DACH-Unternehmen mit vielen unabhängig deployten Microservices – etwa im Banking – entscheidet er über Stabilität und Auditierbarkeit. Dieser Leitfaden zeigt Ihnen die vier Integrationsstrategien, den sauberen Unterschied zwischen Stub, Treiber und Mock sowie modernes Contract Testing mit Pact. Außerdem: wie Sie Integrationstests konkret in Ihre CI/CD-Pipeline einbinden und mit Self-Healing stabil halten.

Kurz gefasst: Der Integrationstest prüft das Zusammenspiel integrierter Komponenten und ihrer Schnittstellen. Er sitzt in der Testpyramide zwischen Komponenten- und Systemtest. Bei 74 % API-first-Organisationen (Postman, 2024) wird Contract Testing mit Pact zum Schlüssel für unabhängig deploybare Microservices.

Abbildung 1: Der Integrationstest sitzt zwischen Komponenten- und Systemtest.

Was ist ein Integrationstest?

Der Integrationstest hat laut ISTQB das Ziel, Fehlerzustände in den Schnittstellen und im Zusammenspiel zwischen integrierten Komponenten aufzudecken (ISTQB-Glossar, 2024). Er prüft also nicht einzelne Bausteine, sondern deren Kommunikation. Genau dort scheitern Systeme: bei Datenübergaben, Aufrufreihenfolgen und Vertragsgrenzen zwischen Modulen.

Man unterscheidet zwei Ebenen. Der Komponentenintegrationstest prüft das Zusammenspiel zwischen Komponenten innerhalb eines Systems und liegt meist beim Entwicklungsteam – direkt nach dem Unit-Test. Der Systemintegrationstest prüft das Zusammenspiel zwischen Systemen, Paketen, Microservices und externen Schnittstellen.

Warum reicht der Unit-Test nicht? Weil ein Modul isoliert korrekt sein kann und trotzdem mit seinem Nachbarn nicht spricht. Schnittstellenfehler sind Beziehungsfehler – sie existieren nur im Zusammenspiel. Der Integrationstest macht dieses Zusammenspiel zur Prüfgröße.

Mehr Kontext finden Sie in unserem Überblick zu den Testarten im Software-Testing.

Wo steht der Integrationstest in der Testpyramide?

Der Integrationstest sitzt in der Testpyramide zwischen Komponententest (Basis) und System- bzw. End-to-End-Test (Spitze) (Martin Fowler, 2018). Das Modell geht ursprünglich auf Mike Cohn zurück. Die Logik: viele schnelle Unit-Tests unten, weniger, aber breitere Tests nach oben.

Diese Position hat praktische Folgen. Integrationstests laufen langsamer als Unit-Tests, weil sie echte Abhängigkeiten einbinden – Datenbanken, Queues, Nachbarservices. Sie laufen aber schneller und gezielter als vollständige End-to-End-Tests, die das gesamte System durch die Oberfläche prüfen.

Ein häufiger Fehler in der Praxis: Teams ersetzen fehlende Integrationstests durch immer mehr E2E-Tests. Das Ergebnis sind langsame, brüchige Suiten. Besser ist eine bewusste Verteilung – Schnittstellen integrativ, Geschäftsflüsse end-to-end.

Den Unterschied zur Spitze der Pyramide vertiefen wir im Beitrag zum End-to-End-Test.

Welche Integrationsstrategien gibt es?

Abbildung 3: Die vier Integrationsstrategien im Ueberblick.

Vier Strategien dominieren die Praxis: Big-Bang, Top-Down, Bottom-Up und Sandwich. Sie unterscheiden sich darin, in welcher Reihenfolge Module zusammengeführt werden und welche Hilfsmittel – Stubs oder Treiber – das ermöglichen (Qytera, 2026). Die Wahl bestimmt, wie früh Sie aussagekräftiges Feedback erhalten.

In unserer Erfahrung wählen Enterprise-Teams selten reines Big-Bang. Der Ansatz spart vorab Aufwand, kostet ihn aber doppelt zurück, sobald ein Fehler auftritt und niemand weiß, welche der gleichzeitig integrierten Schnittstellen schuld ist. Top-Down und Bottom-Up liefern isolierbares Feedback; Sandwich verbindet beides für komplexe Architekturen.

Stub, Treiber oder Mock – was ist der Unterschied?

Die drei Begriffe werden ständig verwechselt, bezeichnen aber klar getrennte Werkzeuge – alle im deutschen ISTQB-Glossar definiert (GTB-Glossar, 2024). Der Unterschied liegt in der Aufrufrichtung und im Prüfziel. Wer ihn kennt, baut sauberere Tests.

Merkhilfe: Ein Stub steht unten und antwortet, ein Treiber steht oben und ruft. Ein Mock geht weiter – er prüft nicht nur Rückgaben, sondern ob und wie er aufgerufen wurde. Mocks dienen damit der Verhaltensverifikation, Stubs der reinen Zustandsantwort.

Wie funktioniert Integrationstest bei APIs und Microservices?

Abbildung 2: 74 % der Organisationen arbeiten API-first (Postman, 2024).

Bei verteilten Systemen prüft der Integrationstest die Interaktion über HTTP, REST, gRPC oder Messaging via Kafka und RabbitMQ. Im Fokus stehen Schemas, Statuscodes, Authentifizierung, Fehlerbehandlung und Verträge. Das ist heute Kerngeschäft: 74 % der Organisationen arbeiten 2024 API-first, gegenüber 66 % im Vorjahr (Postman, 2024).

APIs sind längst Geschäftsmodell, nicht nur Technik. 62 % der Unternehmen erzielen Umsatz direkt über APIs (Postman, 2024). Gleichzeitig steigt das Tempo: 63 % der Entwickler können eine API binnen einer Woche bereitstellen, vorher waren es 47 % (Postman, 2024).

Schnellere Auslieferung bei mehr Schnittstellen heißt: mehr Stellen, an denen Verträge brechen können. Für die Praxis empfiehlt sich:

• Abhängigkeiten containerisieren (Docker, Testcontainers) statt geteilter Test-Umgebungen

• Vertrags- und Schema-Prüfungen automatisieren statt manuell stichprobenartig testen

• Fehlerpfade und Auth-Grenzfälle explizit abdecken, nicht nur den Happy Path

Was ist Contract Testing mit Pact – und warum brauchen es Banken?

Contract Testing prüft, ob Konsument und Anbieter eines API-Vertrags zueinander passen – ohne eine vollständige End-to-End-Umgebung hochzufahren. Der Ansatz ist consumer-driven: Der Konsument definiert seine Erwartung, der Anbieter verifiziert sie gegen einen versionierten Vertrag (Pact, 2024). Werkzeug der Wahl ist Pact, ergänzt um den Pact Broker.

Der Nutzen ist konkret. Nicht alles braucht einen vollen Integrationstest – Contract Tests prüfen genau die Schnittstelle, schnell und isoliert (Microsoft ISE, 2024). Für DACH-Banken mit vielen unabhängig deployten Microservices ist das entscheidend: Teams deployen separat, ohne dass eine zentrale Stage zum Flaschenhals wird.

Gerade im regulierten Umfeld zählt Nachweisbarkeit. Versionierte Verträge im Broker dokumentieren, welche Service-Version mit welcher kompatibel ist – ein prüfbarer Audit-Trail. Das reduziert das Risiko, dass ein unabhängig ausgerollter Service stillschweigend einen Vertragspartner bricht. Contract Tests laufen dabei auf Entwicklerebene und ergänzen System-Integrationstests, ersetzen sie aber nicht.

Wie binden Sie Integrationstests in CI/CD ein?

Abbildung 4: Integrationstests in drei Schritten in CI/CD einbinden.

Integrationstests entfalten ihren Wert erst automatisiert in der Pipeline – ausgeführt in Jenkins, GitHub Actions oder GitLab CI bei jedem relevanten Commit. Der Hebel ist real: Rund 45 % der Teams automatisieren ihre Regressionstests und damit am häufigsten diese Disziplin, während 82 % weiterhin teils manuell testen (Katalon, 2025). Hier liegt unausgeschöpftes Potenzial.

Ein belastbarer Workflow folgt einem klaren Muster:

1. Abhängigkeiten provisionieren – Datenbanken, Queues und Nachbarservices per Testcontainers ephemer hochfahren, isoliert pro Lauf.

2. Tests gegen echte Schnittstellen ausführen – nicht gegen geteilte Mocks, sondern gegen containerisierte reale Komponenten.

3. Gating setzen – schlägt ein Integrations- oder Contract-Test fehl, wird der Merge blockiert. Kein roter Build in den Hauptzweig.

Ein bekanntes Problem bleibt: UI-getriebene System-Integrationstests brechen, sobald sich Oberflächen oder Selektoren ändern. Hier setzen Self-Healing-Locators an – sie erkennen verschobene Elemente und passen sich an, statt rot zu laufen. Autemos deckt mit Self-Healing und einem visuellen Recorder Web-, Mobile-, API- und Desktop-Tests ab und hält System-Integrationstests stabil, wenn Schnittstellen sich verschieben – komplementär zu entwicklernahen Contract Tests.

Wie selbstheilende Locators technisch funktionieren, lesen Sie hier.

Lohnt sich der Aufwand? Was kosten ungefangene Fehler?

Fehler werden teurer, je später man sie entdeckt – das ist die belastbare, evergreene Kernaussage hinter dem Integrationstest. Akademisch gestützt zeigt sich, dass ein in der Integration gefundener Defekt im Schnitt rund 4,55 Personenstunden kostet, einer in der Systemphase dagegen etwa 6,2 (Wagner, arXiv, 2016). Früher fangen heißt günstiger fangen.

Vorsicht ist bei den oft zitierten Zehnerpotenz-Tabellen geboten. Die populären 1×/10×/100×-Leitern lassen sich nicht seriös zurückverfolgen und werden hier bewusst nicht verwendet. Die Richtung der Aussage – Kosten steigen mit der Entdeckungsphase – ist solide; konkrete Multiplikatoren sind es nicht.

Für die Praxis genügt diese Richtung. Ein Integrationstest, der einen Schnittstellenbruch im CI-Lauf stoppt, ist günstiger als derselbe Fehler im Systemtest, in der Abnahme oder – am teuersten – in Produktion.

Häufig gestellte Fragen

Was ist der Unterschied zwischen Integrationstest und Systemtest?

Der Integrationstest prüft das Zusammenspiel und die Schnittstellen zwischen integrierten Komponenten oder Systemen. Der Systemtest prüft das vollständige, integrierte System gegen die Anforderungen. In der Testpyramide sitzt der Integrationstest darunter (Martin Fowler, 2018). Kurz: Integration prüft Verbindungen, System prüft das Ganze.

Stub oder Mock – was nehme ich wann?

Nehmen Sie einen Stub, wenn Sie nur vordefinierte Rückgaben eines aufgerufenen Moduls brauchen, etwa beim Top-Down-Vorgehen. Nehmen Sie einen Mock, wenn Sie verifizieren wollen, ob und wie eine Abhängigkeit aufgerufen wurde – also das Verhalten (GTB-Glossar, 2024). Stub prüft Zustand, Mock prüft Interaktion.

Ersetzt Contract Testing den Integrationstest?

Nein. Contract Testing prüft gezielt den Vertrag zwischen Konsument und Anbieter, ohne volle Umgebung – schnell und isoliert (Microsoft ISE, 2024). Es ergänzt System-Integrationstests, ersetzt sie aber nicht. Beide zusammen geben Microservice-Teams Sicherheit beim unabhängigen Deployen.

Welche Strategie eignet sich für Microservices?

Bei vielen unabhängig deployten Services ist reines Big-Bang riskant, weil Fehler kaum isolierbar bleiben. Bewährt hat sich die Kombination aus Bottom-Up-Integration der Basisdienste und consumer-driven Contract Testing. So bleiben Basisdienste früh stabil (Qytera, 2026), und Verträge schützen die Schnittstellen.

Wie automatisiere ich Integrationstests in der Pipeline?

Provisionieren Sie Abhängigkeiten ephemer per Testcontainers, führen Sie Tests gegen echte Schnittstellen aus und setzen Sie Gating, das fehlerhafte Builds blockiert. Bisher automatisieren nur rund 45 % der Teams ihre Regressionstests konsequent (Katalon, 2025). Mehr zur Strategie im Leitfaden zur KI-Testautomatisierung.

Fazit

Der Integrationstest ist die unterschätzte Mitte der Testpyramide – die Ebene, auf der sich entscheidet, ob isoliert saubere Module auch im Verbund tragen. Wer die vier Strategien kennt, Stub, Treiber und Mock sauber trennt und Contract Testing mit Pact ernst nimmt, gewinnt genau dort Sicherheit, wo verteilte Systeme am häufigsten brechen: an den Schnittstellen. Bei 74 % API-first-Organisationen ist das kein Randthema mehr (Postman, 2024). Für DACH-Banken kommt die Nachweisbarkeit versionierter Verträge hinzu. Automatisieren Sie Integrationstests in CI/CD, halten Sie UI-nahe Prüfungen mit Self-Healing stabil und stoppen Sie Schnittstellenbrüche, bevor sie teuer werden. Sprechen Sie mit unserem Team, wie Sie Ihre Integrationstests stabil automatisieren.