Testcontainers pour l’e‑commerce

Testcontainers permet de piloter des conteneurs Docker depuis les tests. Idéal pour un e‑commerce: DB (PostgreSQL), cache (Redis), files (Kafka, RabbitMQ) démarrent à la volée, avec des données propres à chaque run, en local et en CI.

Pré‑requis

- Docker Desktop installé et lancé.

Mise en place (C# / xUnit)

Exemple minimal pour un repo de commandes: base PostgreSQL et cache Redis.

Fixture de base (PostgreSQL + Redis)

Exemple : test d’intégration OrderRepository

Test d’un repository branché sur PostgreSQL. On crée le schéma dans le test pour rester hermétique.

Cas microservice : lancer l’image du service pour tester l’intégration

On peut tester un microservice tel qu’il sera déployé en démarrant directement son image Docker, tout en branchant des dépendances réelles (ex: PostgreSQL).

Points clés:

- L’image du service est démarrée telle qu’en prod; on injecte la chaîne de connexion via variables d’environnement.

- Ici on utilise host.docker.internal + port mappé pour atteindre PostgreSQL depuis le conteneur du service (simple avec Docker Desktop/CI).

- Alternative: créer un réseau Docker et donner un alias au conteneur DB (ex: "db") puis utiliser "Host=db;Port=5432".

Dans un pipeline CI

Aucune infra partagée à préparer: les conteneurs sont éphémères, démarrés par les tests. Il suffit que l’agent CI ait accès à Docker (ou une VM runner avec Docker).

Combien de temps ça prend ?

- Projet .NET existant: 1–2 h pour une première base (DB + cache), incluant une fixture réutilisable.

- Équipe: 0,5–1 j pour évangéliser, factoriser une "test infra" propre et exemples (PostgreSQL, Redis, message broker).

- Chaque nouveau test d’intégration ensuite: quelques minutes (schéma de test + données).

Gains attendus

- Réduction massive de la flakiness (30–70%) grâce à l’isolation et des données fraîches.

- Parité local/CI: "ça marche chez moi" disparaît.

- Mise à l’échelle simple: exécutions en parallèle par collection/fixture; pas de contention sur une DB partagée.

- On teste le vrai contrat technique (driver, SQL, latences) plutôt que des mocks.

Variantes (Node, Java)

Disponible aussi pour Node (testcontainers-node) et Java (Testcontainers Java) avec une API équivalente (builders, waits, réutilisation).