Antwoord.

Isolatie van tests met externe services is een vereiste voor betrouwbare automatisering.

Achtergrond van de vraag: Vroegere automatiseringssystemen "stuiterden" op externe API's en databases die vaak niet beschikbaar waren of onvoorziene gegevens retourneerden. Zonder isolatie van de geautomatiseerde tests is het resultaat niet reproduceerbaar: flikkeringen, falen door externe problemen, willekeurige storingen.

Probleem:

Externe services zijn vaak onbetrouwbaar: ze kunnen het contract wijzigen, gegevens kunnen ontbreken of de test kan bijwerkingen veroorzaken.
De noodzaak om ("vast te leggen") externe antwoorden voor voorspelbaarheid van het resultaat.
Langzame antwoorden en de onmogelijkheid om scenario's lokaal of in CI te reproduceren.

Oplossing:

Gebruik van "mocks" en "stubs" - lokale stoppers die de reacties van externe API's simuleren. Populair zijn WireMock (Java), httpmock (Python), MockServer, TestContainers.
Emulatie van databases met behulp van in-memory oplossingen of fixtures die vóór elke test worden geleegd en opnieuw worden gevuld.

Zet testdata-ID's in variabelen, zodat tests parallel kunnen draaien en elkaar niet "overlapen".

import requests
BASE_URL = "http://localhost:1080/api"
def test_order_creation():
    mock_response = {"orderId": 12345, "state": "created"}
    # In echte tests retourneert het antwoord de mock-server
    # Hier de aanroep requests.post en assert ...

Belangrijke kenmerken:

Het gebruik van mock-servers om externe afhankelijkheden te imiteren.
Schoonheid van de staat: de gegevens worden voor/na de test gewist (setup/teardown).
Isolatie van identificatoren van testentiteiten.

Vragen met een valstrik.

Is het absoluut noodzakelijk om integratietests via echte services bij elke run uit te voeren?

Nee. Regelmatig kunnen moks/stubs worden gebruikt, en integratietests kunnen apart, minder vaak en onder controle worden uitgevoerd.

Leveren tests met een echte externe API altijd een betrouwbaarder resultaat op?

Nee. Integendeel, ze zijn minder stabiel en kunnen falen door wijzigingen aan de partnerkant. Continue fliktests verlagen de kwaliteit van de pipeline.

Kun je dezelfde testgegevens gebruiken voor parallelle geautomatiseerde tests met externe services?

Nee. Dit kan leiden tot conflicten, "races" en onbetrouwbaarheid. Identificatoren en staat moeten uniek zijn voor elke test/stroom.

Typische fouten en anti-patronen

Geen opruiming of isolatie van testgegevens.
Gebruik van echte API's, zelfs voor unit tests.
Ongerechtvaardigde verkorting van de tijdsduur voor het wachten (timeout), wat leidt tot valse mislukkingen.
Niet rekening houden met wijzigingen in de externe API (de testen zijn voor iedereen gebroken).

Voorbeeld uit het leven

Negatieve casus

In een bedrijf besloten ze omwille van snelheid alle geautomatiseerde tests op echte externe API's (betaalpoort) uit te voeren. Meerdere keren werden de tests geblokkeerd, limieten werden bereikt, ze moesten de toegang herstellen, gegevens "lekten" naar echte rapporten, er waren valse alarmen.

Voordelen:

Snelle integratie met een echte service.

Nadelen:

Wijzigingen aan de kant van de operator verbraken de tests, verspilling van tijd en geld, testafval in "echte" services, moeilijkheid bij reproductie.

Positieve casus

Stelden MockServer en een fictieve in-memory database in. Voor elke test werd de staat gereset, gegevens waren uniek. Echte integratietests werden apart en minder vaak uitgevoerd.