« A TCP proxy to simulate network and system conditions for chaos engineering » : c’est ainsi que le projet Toxiproxy se décrit lui-même dans sa documentation officielle. Concrètement, l’outil s’intercale entre le code testé et un service qu’il appelle, et permet d’injecter des défauts réseau contrôlés — latence, bande passante réduite, coupure brutale — sans toucher au code de l’application ni dépendre d’un service tiers réellement défaillant.
Sur un projet d’extension de suivi de commandes pour une entreprise de vente de matériel apicole, aucun test n’observait le comportement de l’application quand le service externe de calcul de frais de transport répondait lentement. Le code partait du principe que la réponse arrivait toujours en moins d’une seconde, une hypothèse jamais vérifiée automatiquement.
Ce que Toxiproxy ajoute par rapport à un simple mock
Un mock d’appel HTTP remplace la réponse par une valeur fixe, instantanément. Il ne teste donc jamais ce qui se passe si la réponse met du temps à arriver, ou si la connexion se coupe en cours de requête. Toxiproxy, lui, laisse passer un véritable appel réseau (vers un service de test local ou un double du service réel), mais y injecte un délai ou une coupure au niveau de la couche TCP, de façon totalement transparente pour le code applicatif.
Mise en place dans la suite d’intégration
Toxiproxy s’installe comme un serveur autonome, piloté par une API HTTP. En intégration continue, il tourne dans un conteneur dédié aux côtés de l’application :
# docker-compose.test.yml
services:
toxiproxy:
image: ghcr.io/shopify/toxiproxy:2.7.0
ports:
- "8474:8474"
- "8666:8666"
Un proxy est ensuite créé pour rediriger les appels destinés au service de frais de transport vers ce point d’entrée contrôlé :
curl -X POST http://localhost:8474/proxies \
-d '{"name": "frais_transport", "listen": "0.0.0.0:8666", "upstream": "frais-transport-stub:9000"}'
Le code applicatif, en environnement de test, appelle l’adresse du proxy plutôt que celle du service réel, via une variable de configuration. Le comportement nominal reste identique tant qu’aucun toxique n’est activé.
Injecter une latence contrôlée
Une fois le proxy en place, un « toxique » de latence peut être ajouté pour un test précis, puis retiré à la fin du test :
curl -X POST http://localhost:8474/proxies/frais_transport/toxics \
-d '{"name": "latence_calcul", "type": "latency", "attributes": {"latency": 6000, "jitter": 500}}'
Le test peut alors vérifier que l’application affiche un message d’attente au-delà d’un certain seuil, plutôt que de bloquer indéfiniment ou d’afficher une erreur brute au client final :
public function test_affiche_message_attente_si_calcul_frais_lent(): void
{
$this->activer_toxique_latence('frais_transport', 6000);
$reponse = $this->get('/panier/frais-de-port');
$reponse->assertSee('Calcul des frais de livraison en cours, veuillez patienter');
$this->desactiver_toxique_latence('frais_transport');
}
Ce que ce test a révélé
Sur ce projet, le test a immédiatement mis en évidence que l’application attendait indéfiniment la réponse du service de frais de transport, sans délai maximal configuré côté client HTTP, bloquant l’affichage complet de la page panier. Le correctif a consisté à fixer un délai maximal de quatre secondes, au-delà duquel un tarif de secours forfaitaire s’affiche avec une mention explicite, plutôt que de laisser la page se figer.
Limites et bon usage
- Toxiproxy ne remplace pas un test de charge : il sert à observer un comportement de repli sur un cas précis, pas à mesurer une capacité globale.
- Chaque toxique doit être retiré explicitement après le test, sous peine de fausser les tests suivants qui utilisent le même proxy.
- L’outil convient bien aux services externes accessibles par le réseau ; il ne s’applique pas à une base de données coupée localement, scénario qui relève d’une approche différente.
Un test qui ne connaît que la réponse rapide d’un service externe ne teste que la moitié du comportement réel de production.
En résumé
Toxiproxy permet de vérifier, sans dépendre d’un incident réel, que l’application se comporte correctement face à un service externe lent ou coupé. Sur ce projet, le test de latence a permis de découvrir et corriger un blocage avant qu’un client ne le rencontre en conditions réelles lors d’un pic de commandes.
