Réponse.

L'isolation des tests avec des services externes est une condition essentielle pour une automatisation fiable.

Contexte du problème : Les anciens systèmes d'automatisation rencontraient des problèmes avec les API externes et les bases de données, qui étaient souvent soit indisponibles, soit renvoyaient des données imprévues. Sans isolation des tests automatisés, il est impossible de reproduire les résultats : clignotements, plantages dus à des problèmes externes, pannes aléatoires.

Problèmes :

Les services externes sont souvent instables : ils peuvent changer de contrat, les données peuvent être absentes ou le test peut provoquer des effets secondaires.
Nécessité de contrôler ("fixer") la réponse extérieure pour prévoir le résultat.
Réponses lentes et impossibilité de reproduire des scénarios localement ou dans un CI.

Solutions :

Utilisation de "mocks" et "stubs" — des bouchons locaux simulant les réponses des API externes. WireMock (Java), httpmock (Python), MockServer, TestContainers sont populaires.
Émulation de bases de données à l'aide de solutions in-memory ou de fixtures, nettoyées et re-remplies avant chaque test.

Extraction des ID des données de test dans des variables, afin que les tests puissent être exécutés en parallèle sans "se marcher sur les pieds".

import requests
BASE_URL = "http://localhost:1080/api"
def test_order_creation():
    mock_response = {"orderId": 12345, "state": "created"}
    # Dans des tests réels, la réponse sera renvoyée par le mock-server
    # Ici, appel de requests.post et assert ...

Caractéristiques clés :

Utilisation de serveurs mocks pour simuler les dépendances tierces.
Propreté de l'état : nettoyage des données avant/après le test (setup/teardown).
Isolation des identifiants des entités de test.

Questions pièges.

Est-il obligatoire de réaliser des tests d'intégration via des services réels à chaque exécution ?

Non. On peut régulièrement utiliser des mocks/stubs, tandis que les tests d'intégration sont lancés séparément, moins souvent et sous contrôle.

Les tests avec une véritable API externe donneront-ils toujours un résultat plus fiable ?

Non. Au contraire, ils sont moins stables, peuvent échouer à cause de changements du côté du partenaire. Des tests fréquents conduisent à une détérioration de la qualité du pipeline.

Peut-on utiliser les mêmes données de test pour des tests automatisés parallèles avec des services externes ?

Non. Cela peut entraîner des collisions, des "courses" et de l'instabilité. Les identifiants et l'état doivent être uniques par test/flux.

Erreurs typiques et anti-patrons

Pas de nettoyage ou d'isolation des données de test.
Utilisation d'une API réelle même pour des tests unitaires.
Réduction injustifiée du temps d'attente (timeout), entraînant des faux échecs.
Ignorer les changements d'API tierce (tests cassés pour tout le monde).

Exemple de la vie réelle

Cas négatif

Dans l'entreprise, il a été décidé de lancer tous les tests automatisés sur des API externes réelles (passerelle de paiement) pour plus de rapidité. Plusieurs fois, les tests ont été bloqués, des limites ont été atteintes, et il a fallu rétablir l'accès, les données "fuitaient" dans des rapports réels, provoquant des déclenchements falsifiés.

Avantages :

Intégration rapide avec le service réel.

Inconvénients :

Les changements du côté de l'opérateur ont cassé les tests, entraînant des pertes de temps et d'argent, des déchets de test dans des services "de production", et complexité de reproduction.

Cas positif

Un MockServer et une base de données in-memory fictive ont été configurés. Avant chaque test, l'état était réinitialisé, les données étaient uniques. Les tests d'intégration réels étaient exécutés séparément et moins souvent.