Qu'est-ce que l'API testing ?

Qu'est-ce que l'API testing ?

L'API testing est la pratique de valider une interface HTTP, REST, GraphQL ou gRPC directement contre sa spécification : forme du contrat, status codes, payloads de réponse, authentification, autorisation, gestion d'erreurs, rate limits et performance sous charge. Les tests sautent l'UI complètement et exercent l'endpoint comme un autre service le ferait.

Parce que l'API est généralement le point d'intégration entre services (et la surface contre laquelle un SDK public construit), les API tests attrapent des ruptures que les UI tests manquent : drift de schéma, changements silencieux casseurs de rétrocompatibilité, flows d'auth cassés et violations de contrat qui n'échouent qu'au moment où un consumer downstream parse la réponse.

API testing vs UI testing

Les deux valident le système ; ils vivent à des couches différentes.

• UI testing conduit un browser à travers un flow (login, recherche, checkout) et asserte sur les éléments visibles. Lent (secondes par assertion), flaky (réseau, timing d'animation, quirks headless), cher à maintenir.
• API testing envoie des requêtes HTTP directement et asserte sur status, headers, body. Rapide (dizaines de millisecondes par assertion), déterministe (pas de surface de rendu), bon marché à maintenir. Couvre contrat + préoccupations d'intégration que l'UI ne peut pas atteindre.

La répartition pragmatique : 80% de couverture de test à la couche API, 20% à la couche UI pour les rares flows que les utilisateurs voient réellement end-to-end. Inverser ce ratio est la cause la plus commune de pipelines CI lents et flaky.

Ce que couvrent les API tests

• Validation de contrat. Le schéma de réponse correspond à la spec OpenAPI / GraphQL / protobuf. Types de champs, champs requis, valeurs enum. Attraper les ruptures au moment où elles partent.
• Status codes. 2xx au succès, 4xx correct sur mauvais input (400 vs 401 vs 403 vs 404 vs 422), 5xx n'apparaît que sur de vraies erreurs serveur.
• Authentification et autorisation. Les requêtes non authentifiées renvoient 401. Les requêtes authentifiées du mauvais tenant renvoient 403. Les tokens expirent comme annoncé.
• Edge cases. Arrays vides, champs null, strings max-length, JSON malformé, headers requis manquants, payloads surdimensionnés.
• Idempotence. Les requêtes POST / PUT avec une idempotency key appliquée deux fois produisent un seul side effect.
• Rate limits et quotas. 429 renvoyé au seuil documenté avec Retry-After correct.
• Performance. p95 latency sous SLO à la charge attendue. Voir load testing pour comment mesurer.

Quand exécuter des API tests

1. À chaque PR. Partie de la regression suite. Checks fonctionnels et de contrat tournent en secondes.
2. Smoke post-deploy. Une poignée de checks d'endpoint critique après chaque deploy pour confirmer que l'API live répond correctement. Voir smoke testing.
3. Régression de performance. Lancez un load test contre l'API au peak attendu avant chaque release. Assertez que p95 + error rate n'ont pas régressé.
4. Sizing de capacité pre-launch. Lancez du capacity testing et spike testing contre l'API pour connaître le plafond avant l'arrivée du trafic.

Outils clés d'API testing

• Postman / Insomnia. Constructeurs interactifs de requêtes avec support collection-runner. Bons pour l'exploration ; les collections peuvent tourner en CI.
• REST-assured (Java), supertest (Node), pytest+requests (Python). API tests code-first vivant à côté du code applicatif. Le défaut pour les regression suites.
• Schemathesis, Dredd. Génèrent des cas de test automatiquement depuis une spec OpenAPI / GraphQL. Attrapent le drift de schéma pour lequel vous n'avez pas écrit de tests.
• JMeter et k6. API testing côté performance. Les deux supportent HTTP, assertions JSON / XML, headers custom, flows d'auth. k6 a GraphQL first-class via JS ; JMeter gère SOAP, JDBC, MQTT pour APIs non-REST.

Comment exécuter des tests de performance API

Un API test fonctionnel confirme que l'endpoint renvoie la bonne forme à faible charge. Un test de performance API confirme qu'il le fait encore à charge de production. Les deux comptent ; le second attrape la fuite qui fait tomber l'API le jour du launch.

Dans k6, définissez votre endpoint flow en JavaScript, ajoutez des assertions check() sur chaque réponse et configurez un scénario ramping-vus au peak attendu. Dans JMeter, utilisez un HTTP Request sampler avec JSON Path / Response Assertions et un Thread Group dimensionné à la concurrence attendue.

Exécutez depuis LoadFocus pour du trafic depuis plusieurs régions cloud frappant l'API simultanément. Les vrais consumers d'API sont géo-distribués ; les load tests single-origin manquent le comportement DNS, gateway régional et edge cache que la production rencontre.

Si vous préférez ne pas écrire les scripts vous-même, LoadFocus propose des load testing services où des ingénieurs conçoivent des scénarios API depuis votre spec OpenAPI, les exécutent à grande échelle et livrent une analyse avec décompositions latency-par-endpoint et error-rate-par-endpoint.