Warum Integrationstests Sie oder Ihre Software nicht retten werdenu2026

Hat Sie der Titel gereizt? Prima, die Arbeit ist getan! Heute werde ich Ihnen meine Geschichte über Integrationstests erzählen. Sie entstand nach einem weiteren Wissensaustausch beim Mittagessen mit meinem Freund  Kenny. Von dieser Definition ist ein Integrationstest

(...) die Phase beim Softwaretest, in der einzelne Softwaremodule kombiniert und als Gruppe getestet werden. Integrationstests werden durchgeführt, um die Übereinstimmung eines Systems oder einer Komponente mit bestimmten funktionalen Anforderungen zu bewerten. Sie finden nach den Einzeltests und vor den Validierungstests statt. Beim Integrationstest werden die Module, die bereits einzeln getestet wurden, zu größeren Aggregaten zusammengefasst, die in einem Integrationstestplan definierten Tests auf diese Aggregate angewandt und als Ergebnis das integrierte System für den Systemtest bereitgestellt.

Klingt ziemlich nach Wasserfall, oder? Das ist es auch! Die Implementierungsansätze, die ich beobachtet habe, schaffen außerdem enorme Abhängigkeiten zwischen den Teams und koppeln den Software-Release-Prozess.

Alles gekoppelt, eine Geschichte der Integrationstests

Eine solide CI/CD-Pipeline umfasst mehrere Schritte: Validieren, Erstellen, Testen, Verpacken und Freigeben der Software. Ich werde nicht ins Detail gehen, da die notwendigen Schritte je nach Sprachen, Frameworks, Plattformen und Freigabestrategien variieren.Allerdings (es gibt immer ein Aber) verwenden Teams häufiger, als mir lieb ist, Integrationstests, um (1) festzustellen, ob die Abhängigkeiten der Software funktionieren (Softwareabhängigkeiten), und (2) zu überprüfen, ob Benutzerreisen, die mehrere Domänengrenzen überschritten haben (teamübergreifende Abhängigkeiten).Aus diesen Gründen habe ich eine Kopplung zwischen verschiedenen Systemen, Teams und Domänen beobachtet. Außerdem ist es schmerzhaft, den Entwicklungs- und Freigabeprozess zu beobachten... Die Zeit und der Aufwand, die in den Prozess gesteckt werden, und die verschwommene Grenze zwischen dem automatisierten Prozess und der manuellen Koordination...

Was ist also die Alternative, um hochwertige Software zu liefern?

Integrationstests sind ein Symptom, nicht das wegen der Kopplung von Systemen und Teams! Und bevor Sie sich austoben und alle Integrationstests aus Ihrer Codebasis löschen, möchte ich Ihnen Folgendes zeigen  meine Alternative dazu. Die erste Testtechnik, die ich verwende, ist das Contract Testing. Vertragstests sind

(...) eine Methode, die sicherstellt, dass Dienste (wie ein API-Anbieter und ein Client) miteinander kommunizieren können.

Diese Definition wird bereitgestellt von Pact, ein Vertragstest-Tool für HTTP-basierte APIs. Haftungsausschluss: Contract Testing kann auf jede API angewandt werden, und dieser Blogbeitrag ist nicht auf ein (dieses) Tool ausgerichtet. Ich mag einfach ihre Definition! :-) Die Vertragstests werden vor der Bereitstellung in einer Umgebung ausgeführt und gegen einen Broker validiert. Das bedeutet, dass ich prüfe, ob alle meine Annahmen über die Verträge mit meinen direkten Abhängigkeiten korrekt sind. Wenn nicht, breche ich den CI/CD-Prozess ab.Damit sind jedoch nicht alle Probleme gelöst. Contract Testing liefert keine Antwort auf die Frage: Sind meine Abhängigkeiten funktionstüchtig? Um diese Frage zu beantworten, wende ich eine zweite Technik an, das Gesundheitstesten. Gesundheitstests sind

eine Möglichkeit, in Echtzeit Feedback über die direkten Abhängigkeiten einer Anwendung zu geben.

Diese Definition stammt von mir. Es bedeutet, dass eine Anwendung (über Push- oder Pull-Mechanismen) den Status und die Metriken der direkten Abhängigkeiten melden kann. Auf der Anwendungsebene zusammengefasst, kann dies ein Ampelmuster mit Grün, Gelb und Rot ergeben. In Kombination mit einem geeigneten Überwachungstool können wir den Status der Abhängigkeiten in Echtzeit einsehen. Diese zweite Technik löst eine wichtige Falle von Integrationstests. Integrationstests geben Feedback zu den Abhängigkeiten bei  zu einem bestimmten Zeitpunkt. Gesundheitstests (falls ordnungsgemäß durchgeführt)  liefernkontinuierlich das notwendige Feedback. Die Kombination dieser beiden Techniken hat einige interessante Nebeneffekte. Zunächst einmal verringert sich die Ausführungszeit der CI/CD-Pipeline im Vergleich zu den Ausführungszeiten von Integrationstests, da weniger Komponenten beteiligt sind. Zweitens neigen Integrationstests dazu, spröde zu sein, und es kann die Anzahl der False Positives reduzieren, was die Produktivität des Teams erhöht. Nicht zuletzt zwingt es die Teams dazu, die Grenzen ihrer Systeme und ihrer Domänen zu diskutieren. Es erhöht das Bewusstsein für den Kontext, in dem Teams arbeiten, und führt zu umfassenden Gesprächen zwischen allen am Softwareentwicklungsprozess Beteiligten (ja, ich sage IT und Business).

Und was denken Sie darüber?

Teilen Sie es mir mit, in den Kommentaren oder über Twitter (DM-Nachrichten sind offen).   Dieser Blogbeitrag wird auch in meinem persönlichen Blog veröffentlicht.