Qu'est-ce que l'API testing ?

Qu'est-ce que l'API testing ?

L'API testing consiste à envoyer des requêtes directement à une API et à comparer la réponse avec ce que promet la spécification : code de statut, en-têtes, forme du payload, authentification, gestion des erreurs et temps de réponse. Aucun navigateur ni interface n'intervient. Le test appelle l'endpoint comme le ferait un autre service ou un SDK, et détecte les ruptures de contrat avant qu'un consommateur ne les remarque.

Comment fonctionne l'API testing

Un test est une requête plus des assertions. Vous choisissez un endpoint, définissez méthode, en-têtes, auth et corps, vous l'envoyez, puis vous vérifiez la réponse. Enchaînez les requêtes quand un appel dépend d'un autre (créer une commande, puis la lire avec l'id renvoyé).

POST /orders
Authorization: Bearer <token>
{"sku": "A-100", "qty": 2}

assert status == 201
assert body.id est une chaîne
assert body.qty == 2
assert temps de réponse < 300 ms

Lancez les mêmes vérifications dans un runner de tests à chaque pull request, et un sous-ensemble contre l'API en production de façon planifiée.

Ce que couvrent les tests d'API

• Contrat. Noms de champs, types et champs obligatoires correspondent au schéma OpenAPI ou GraphQL.
• Codes de statut. 2xx en cas de succès, le bon 4xx pour une entrée invalide (400, 401, 403, 404, 422), 5xx seulement pour de vraies erreurs serveur.
• Authentification et autorisation. Sans jeton, 401 ; avec le jeton d'un autre tenant, 403 ; les jetons expirés sont refusés.
• Cas limites. Tableaux vides, champs nuls, longueurs maximales, JSON mal formé, en-têtes manquants, corps volumineux.
• Limites de débit. Un 429 au seuil documenté, avec un Retry-After cohérent.
• Performance. Latence et taux d'erreurs à la charge attendue. Voir les métriques de performance d'API.

API testing et tests d'interface

Les tests d'interface pilotent un navigateur à travers un parcours et vérifient ce qui est visible. Ils sont lents et cassent quand la mise en page change. Les tests d'API vérifient directement les réponses, s'exécutent en millisecondes et n'échouent que pour une raison. La plupart des équipes placent l'essentiel des vérifications au niveau de l'API et gardent quelques tests d'interface pour les parcours que les utilisateurs suivent vraiment. Les deux ont leur place dans les tests de régression.

Types de tests d'API

• Tests fonctionnels et de contrat vérifient la justesse par rapport à la spécification.
• Tests d'intégration vérifient que les services fonctionnent ensemble, souvent contre un stub issu du mocking d'API quand une dépendance manque.
• Tests de sécurité sondent l'auth, les injections et l'exposition excessive de données.
• Smoke tests appellent quelques endpoints critiques après un déploiement. Voir le guide du smoke testing (en anglais).
• Tests de charge mesurent vitesse et erreurs sous trafic concurrent. Voir le load testing.
• Supervision répète les vérifications de façon planifiée en production. Voir la supervision d'API.

Erreurs courantes

• Ne vérifier que le code de statut. Un 200 avec le mauvais corps reste un échec.
• Ne tester que le cas nominal et ignorer les échecs d'auth et les entrées invalides.
• Partager des données de test modifiables entre les tests, si bien que l'ordre change le résultat.
• Écrire jetons et URL en dur au lieu d'utiliser des variables par environnement.
• Lancer les mesures de performance depuis une seule machine à côté du serveur, ce qui masque les effets réseau et régionaux.
• Ne jamais tester la production, si bien qu'un déploiement qui passe en staging échoue sans que personne ne le voie.

Outils et place de LoadFocus

Les runners en code (pytest avec requests, supertest, REST-assured) conviennent aux suites de régression. Postman et les clients similaires conviennent à l'exploration. Les outils pilotés par la spécification, comme Schemathesis, génèrent des cas à partir d'un fichier OpenAPI.

• curl en ligne envoie une requête depuis les serveurs LoadFocus et affiche statut, en-têtes, corps et le détail des temps. C'est une vérification ponctuelle, et les redirections sont signalées au lieu d'être suivies.
• L'API status checker vérifie une URL publique depuis 6 régions AWS à la fois. C'est un instantané, sans planification, historique ni alertes.
• La supervision d'API exécute des vérifications planifiées sur les codes de statut, les corps de réponse, les en-têtes et le temps de réponse, avec des alertes par email, Slack, Microsoft Teams et d'autres canaux. Le plan gratuit vérifie toutes les 5 minutes ; les plans payants, plus souvent.
• OpenAPI vers k6 convertit une spécification OpenAPI ou Swagger en script k6 dans votre navigateur. Vous pouvez l'exécuter sur la plateforme de load testing, qui lance JMeter et k6 depuis 25 régions cloud.

Ce que les testeurs en navigateur peuvent ou non faire est détaillé dans le guide du testeur d'API en ligne (en anglais).

Questions fréquentes : API testing

L'API testing, est-ce la même chose que les tests unitaires ?

Non. Un test unitaire vérifie une fonction isolée. Un test d'API appelle le service en fonctionnement via HTTP et vérifie le contrat qu'il expose, ce qui sollicite aussi le routage, l'auth, la sérialisation et souvent la base de données.

Faut-il savoir coder pour tester des API ?

Pas pour commencer. Un client comme curl ou un constructeur de requêtes suffit pour envoyer des requêtes et lire les réponses. Le code ou un fichier de configuration intervient quand on automatise en CI.

À quelle fréquence lancer les tests d'API ?

Les vérifications fonctionnelles et de contrat à chaque pull request, quelques vérifications critiques après chaque déploiement et un sous-ensemble planifié en production pour apprendre une panne avant vos utilisateurs.

Quelle différence entre API testing et supervision d'API ?

Le testing s'exécute avant la mise en production pour trouver des défauts. La supervision répète des vérifications contre l'API en production et vous alerte quand quelque chose échoue ou ralentit.