Que tester dans une API ?
Cet article est le deuxième d’une série dédiée aux test d’API.
Les autres articles exploreront les thèmes suivant :
- Tester une API, ce n’est pas faire que du Postman
- Tests de contrat : mythe, réalité et pièges
- Concevoir une stratégie de test d'API efficace
Vous voilà devant votre API, Postman ouvert, prêt à tester. Mais par où commencer ? Vous testez le happy path, tout passe au vert, et puis quoi ? Cette question "que tester exactement ?" revient constamment.
La réponse courte : vous ne pouvez pas tout tester, et vous ne devriez même pas essayer. La réponse longue : il existe six grandes catégories de tests API qui couvrent l'essentiel des risques. Comprendre ces catégories vous aidera à faire des choix intelligents.
Les six catégories essentielles de tests d'API
Quand on parle de tester une API, on parle en réalité de vérifier six dimensions différentes qui garantissent que votre API est solide et fiable. Chacune de ces dimensions répond à un risque spécifique.
Tester le schéma: le fondement de la confiance
Les tests de schéma vérifient que l'API respecte ce qu'elle promet. C'est la structure entre votre API et ceux qui l'utilisent. Quand votre documentation indique qu'un endpoint retourne un objet avec un champ "userId" de type string, ce champ doit effectivement être présent et être une chaîne de caractères.
Ces tests examinent la structure des réponses. Est-ce que tous les champs obligatoires sont présents ? Est-ce que les types de données correspondent à la spécification ? Est-ce que les codes de statut HTTP sont appropriés ? Un endpoint de création devrait retourner un 201 Created, pas un 200 OK.
Ces tests sont particulièrement cruciaux dans les architectures microservices où plusieurs équipes développent des services qui doivent communiquer entre eux. Si le service A attend un tableau d'objets mais que le service B renvoie un objet unique, tout s'effondre.
Je vous partage une vidéo sur ce sujet.
Le niveau au dessus est de faire des test de contrat, ce qui sera présenter dans le prochain article.
Les règles métier : le cœur de la valeur
Les règles métier sont ce qui différencie votre API d'un simple CRUD générique. C'est là que réside la logique spécifique à votre domaine. Dans une API de e-commerce, vous devez tester qu'un utilisateur ne peut pas commander un produit en rupture de stock, qu'une réduction ne peut pas être appliquée deux fois, ou qu'un remboursement ne peut pas dépasser le montant initial.
Ces tests nécessitent une compréhension profonde du métier. Ils ne se limitent pas à vérifier le code HTTP, mais vérifient que l'API applique correctement les règles de gestion et maintient la cohérence du système.
Un piège classique : les règles métier silencieuses. Ce sont ces règles qui ne génèrent pas d'erreur visible mais qui modifient subtilement le comportement. Par exemple, une API qui applique automatiquement une remise VIP sans le signaler explicitement, ou qui arrondit les prix selon des règles complexes. Ces comportements doivent être testés explicitement.
Erreurs et cas limites : tester l'échec
Si vos tests se limitent au happy path, vous ne testez qu'une fraction de ce que votre API doit gérer. Les vraies questions sont : que se passe-t-il quand ça ne marche pas ? Comment votre API réagit-elle face à des données invalides ou malformées ?
Tester les erreurs, c'est envoyer un payload incomplet et vérifier que l'API retourne un message d'erreur clair, pas un 500 Internal Server Error cryptique. C'est aussi tester avec des types invalides : envoyer une chaîne là où l'API attend un nombre, ou un tableau vide là où elle attend au moins un élément.
Les cas limites sont tout aussi importants. Que se passe-t-il si vous envoyez une chaîne de 10 000 caractères dans un champ prénom ? Si vous créez une commande avec zéro article ? Ces scénarios surviennent en production.
Un bon test d'erreur vérifie trois choses : le code HTTP approprié, un message d'erreur compréhensible, et l'absence d'effets de bord. Si une création échoue, rien ne doit être modifié en base de données.
Sécurité : la dimension invisible
La sécurité est souvent négligée dans les tests d'API, pourtant elle est absolument critique. Vous devez vérifier que votre API refuse les requêtes non authentifiées quand nécessaire, qu'elle respecte les autorisations, et qu'elle ne fuit pas de données sensibles.
Les tests de sécurité basiques incluent : tester qu'un utilisateur ne peut pas accéder aux ressources d'un autre utilisateur, qu'un token expiré est rejeté, que les données sensibles ne sont pas exposées dans les logs ou messages d'erreur, et que l'API résiste aux attaques courantes.
Concrètement, testez avec des tokens invalides, des identifiants manipulés, des payloads contenant des scripts. Beaucoup d'API "internes" ne vérifient aucune autorisation et permettent à n'importe quel utilisateur authentifié d'accéder à toutes les données.
Performance basique : ne pas ralentir le système
Les tests de performance d'API ne consistent pas à lancer des tests de charge massifs. Pour la plupart des équipes, la performance basique suffit : s'assurer que votre API répond dans des temps raisonnables sous une charge normale.
Un test de performance basique vérifie qu'un endpoint répond en moins de 200-300 millisecondes dans des conditions standards, qu'une requête complexe ne prend pas plusieurs secondes, et que l'API ne ralentit pas dramatiquement avec une charge légèrement supérieure.
Vous pouvez intégrer ces tests dans vos pipelines CI/CD. Si un changement fait passer le temps de réponse de 100ms à 2 secondes, vous voulez le savoir immédiatement. Des outils comme K6 ou des assertions de temps dans vos frameworks suffisent.
L'objectif est de détecter les problèmes évidents : une requête N+1, un endpoint qui fait 50 appels base de données pour retourner une liste, ou une opération synchrone qui devrait être asynchrone.
Compatibilité et versioning : gérer l'évolution
Votre API va évoluer. De nouvelles fonctionnalités vont apparaître, d'anciennes vont disparaître. La question est : comment gérer cette évolution sans casser les clients existants ? C'est là qu'interviennent les tests de compatibilité et de versioning.
Ces tests vérifient que les changements restent rétrocompatibles. Si vous ajoutez un nouveau champ obligatoire, les clients qui envoient l'ancienne structure doivent continuer à fonctionner, soit via une valeur par défaut, soit via une version d'API différente.
Tester le versioning, c'est aussi vérifier que les anciennes versions continuent de fonctionner après un déploiement. Si vous maintenez une v1 et une v2, vos tests doivent valider les deux versions simultanément.
Ce qu'il faut ignorer : l'art du compromis
Maintenant, parlons de ce que vous ne devriez pas tester, ou du moins pas avec la même intensité. Beaucoup d'équipes tombent dans le piège de vouloir tout tester, ce qui mène à des suites de tests énormes et impossibles à maintenir.
Les détails d'implémentation interne ne méritent pas de tests d'API. Si votre endpoint utilise Redis ou PostgreSQL en interne, peu importe du point de vue du contrat d'API. Ce qui compte, c'est le résultat visible.
Les scénarios extrêmement improbables ne méritent pas d'automatisation. Tester qu'une API gère une requête avec 10 000 paramètres quand votre use case réel ne dépasse jamais 10 paramètres, c'est du temps perdu.
Les variations infinies du même cas ne sont pas utiles. Si vous testez qu'un champ email doit être valide, pas besoin de tester 50 formats différents. Testez un cas valide, un cas invalide, et peut-être un cas limite.
La notion de risque API : prioriser intelligemment
Tester une API, c'est fondamentalement un exercice de gestion du risque. Vous avez un temps limité, et vous devez l'allouer là où il aura le plus d'impact. Pour cela, vous devez identifier les risques spécifiques à votre API.
Un risque API combine deux dimensions : la probabilité qu'un problème survienne et l'impact qu'il aurait. Un endpoint critique qui gère les paiements représente un risque élevé. Un endpoint administratif rarement utilisé représente un risque faible.
Cela ne signifie pas que vous ne testez pas les endpoints à faible risque, mais que vous adaptez votre effort. Pour l'endpoint de paiement, vous aurez peut-être 100 tests couvrant tous les cas possibles. Pour l'endpoint de statistiques, quelques tests de contrat suffiront.
Identifiez aussi les zones qui changent fréquemment versus celles qui sont stables. Les parties qui évoluent constamment méritent plus de tests de non-régression.
Posez-vous ces questions : Combien d'utilisateurs sont impactés si cet endpoint tombe ? Quelles sont les conséquences business d'un bug ? À quelle fréquence est-il modifié ? Quelle est la complexité de la logique métier ?
Des exemples concrets pour clarifier
Prenons un exemple pratique. Imaginez un endpoint POST /orders qui crée une commande. Que devez-vous tester ?
Pour le contrat, vous vérifiez que l'endpoint retourne un 201 avec un orderId, un total, et une liste d'items. Vous testez aussi qu'il retourne un 400 si le payload est incomplet.
Pour les règles métier, vous testez qu'une commande ne peut pas être créée avec un panier vide, que le total correspond à la somme des prix, et que le stock est décrémenté.
Pour les erreurs, vous envoyez un payload avec un productId inexistant, un quantity négatif, un payload sans userId obligatoire. Vous vérifiez que chaque erreur retourne un code approprié et un message clair.
Pour la sécurité, vous testez qu'un utilisateur ne peut pas créer une commande au nom d'un autre en manipulant le userId.
Pour la performance, vous vérifiez que l'endpoint répond en moins de 500ms même avec 20 articles.
Voilà, en quelques tests bien pensés, vous couvrez l'essentiel des risques sans tester tous les cas imaginables.
Tester intelligemment, pas exhaustivement
Tester une API, ce n'est pas cocher toutes les cases d'une checklist interminable. C'est comprendre les six grandes catégories de tests, identifier les risques spécifiques à votre contexte, et allouer vos efforts là où ils comptent.
Vous n'avez pas besoin de 1000 tests pour avoir une API de qualité. Vous avez besoin des bons tests, ceux qui détectent les problèmes réels avant qu'ils n'atteignent vos utilisateurs.
Dans le prochain article, nous plongerons en profondeur dans les tests de contrat : pourquoi ils sont souvent mal compris, comment les implémenter correctement, et quels pièges éviter.
FAQ
1) Dois-je vraiment tester tous les codes d'erreur possibles ?
Non, concentrez-vous sur les erreurs les plus courantes. Testez les erreurs 400, 401, 403, 404 et 500 pour les endpoints critiques. Pour les endpoints secondaires, quelques tests d'erreur basiques suffisent.
2) Comment savoir si j'ai assez de tests ?
Posez-vous ces questions : Si un bug passe en production, mes tests l'auraient-ils détecté ? Mes tests couvrent-ils les scénarios réels ? Si un développeur modifie le code, les tests casseront-ils en cas de régression ?
3) Les tests de contrat remplacent-ils les tests fonctionnels ?
Non, ils sont complémentaires. Les tests de contrat vérifient la structure des réponses. Les tests fonctionnels vérifient que les règles métier sont appliquées. Vous avez besoin des deux.
4) QFaut-il tester les dépendances externes de mon API ?
Pas directement. Utilisez des mocks pour simuler les réponses des dépendances externes. Testez que votre API gère correctement ces réponses, mais ne testez pas les dépendances elles-mêmes.
5) Est-ce que je dois tester tous les endpoints de la même manière ?
Non. Tu testes différemment un endpoint “critique business” et un endpoint “liste filtrée”. C’est exactement là que le risk-based testing est utile : même surface API, niveaux de risque différents.
6) À quelle fréquence dois-je faire des tests de performance ?
Les tests de performance basiques devraient tourner à chaque déploiement dans votre CI/CD. Les tests de charge plus poussés peuvent être hebdomadaires ou avant les releases majeures.