Antwort.

Die Isolation von Tests mit externen Diensten ist eine Voraussetzung für zuverlässige Automatisierung.

Hintergrund: Frühere Automatisierungssysteme "stießen" an externe APIs und Datenbanken, die oft entweder nicht verfügbar waren oder unerwartete Daten zurücklieferten. Ohne Isolierung können Testergebnisse nicht reproduziert werden: Flimmern, Abstürze aufgrund externer Probleme, zufällige Fehler.

Problem:

Externe Dienste sind oft instabil: Sie können den Vertrag ändern, es können keine Daten verfügbar sein oder der Test kann Nebeneffekte auslösen.
Notwendigkeit, die externe Antwort zu kontrollieren ("einzufrieren") für die Vorhersehbarkeit des Ergebnisses.
Langsame Antworten und die Unmöglichkeit, Szenarien lokal oder in CI zu reproduzieren.

Lösung:

Verwendung von "Mocks" und "Stubs" – lokalen Platzhaltern, die die Antworten externer APIs simulieren. Beliebt sind WireMock (Java), httpmock (Python), MockServer, TestContainers.
Emulation von Datenbanken mit Hilfe von In-Memory-Lösungen oder Fixtures, die vor jedem Test zurückgesetzt und neu gefüllt werden.

Abstraktion von Testdatensätzen in Variablen, damit Tests parallel ausgeführt werden können und sich nicht "überlappen".

import requests
BASE_URL = "http://localhost:1080/api"
def test_order_creation():
    mock_response = {"orderId": 12345, "state": "created"}
    # In echten Tests wird die Antwort vom Mock-Server zurückgegeben
    # Hier Aufruf von requests.post und assert ...

Schlüsselfunktionen:

Verwendung von Mock-Servern zur Nachahmung von externen Abhängigkeiten.
Datenintegrität: Datenreinigung vor/nach dem Test (Setup/Teardown).
Isolation der Identifikatoren von Testobjekten.

Trickfragen.

Muss man Integrations Tests mit echten Diensten bei jedem Durchlauf durchführen?

Nein. Regelmäßig können Mocks/Stubs verwendet werden, und Integrations Tests sollten separat, seltener und unter Kontrolle ausgeführt werden.

Geben Tests mit echten externen APIs immer zuverlässigere Ergebnisse?

Nein. Im Gegenteil, sie sind weniger stabil und können aufgrund von Änderungen beim Partner ausfallen. Ständige Flimmer-Tests verringern die Qualität der Pipeline.

Kann man die gleichen Testdaten für parallele automatisierte Tests mit externen Diensten verwenden?

Nein. Das kann zu Kollisionen, "Rennen" und Instabilität führen. Identifikatoren und Status müssen für jeden Test/Thread eindeutig sein.

Typische Fehler und Anti-Muster

Keine Reinigung oder Isolation von Testdaten.
Verwendung von echtem API sogar für Unit-Tests.
Unbegründete Verkürzung der Wartezeit (Timeout), was zu falschen Fehlschlägen führt.
Nichtbeachtung von Änderungen bei externen APIs (alle Tests waren gleichzeitig kaputt).

Beispiel aus der Praxis

Negativer Fall

Im Unternehmen wurde beschlossen, zur Geschwindigkeit alle automatisierten Tests gegen echte externe APIs (Zahlungs-Gateway) auszuführen. Mehrmals wurden die Tests gesperrt, es gab Limits, der Zugang musste wiederhergestellt werden, Daten "flossen" in echte Berichte, es gab falsche Auslöser.

Vorteile:

Schnelle Integration mit echtem Dienst.

Nachteile:

Änderungen auf der Betreiberseite brachen die Tests, was Zeit und Geld kostete, Testmüll in "Produktions"-Diensten, Schwierigkeiten bei der Reproduktion.

Positiver Fall

MockServer und eine fiktive In-Memory-Datenbank wurden eingerichtet. Vor jedem Test wurde der Status zurückgesetzt, die Daten waren einzigartig. Echte Integrations Tests wurden separat und seltener durchgeführt.