Cas pratiques API Testing

Contexte Une API POST /login retourne un objet JSON contenant un token. Le Problème Le test actuel tente d’accéder directement à une propriété inexistante. expect(response.token).toBeDefined(); Le token est en réalité dans response.data.token. Contraintes Corriger l’accès à la propriété sans modifier la logique globale du test. Livrable attendu Un test API valide vérifiant correctement la présence du token.

Contexte Une API GET /status retourne : { "status": "active" }. Le Problème Le test actuel compare avec une valeur incorrecte. const data = response.data; expect(data.status).toBe("ACTIVE"); La valeur réelle est en minuscules. Contraintes Corriger uniquement l’assertion pour correspondre à la valeur exacte retournée par l’API. Livrable attendu Un test API fonctionnel validant correctement la valeur du champ status.

Contexte Une API GET /count retourne : { "total": 5 }. Le Problème Le test compare la valeur comme une chaîne. expect(data.total).toBe("5"); La valeur retournée est numérique. Contraintes Corriger l’assertion pour comparer correctement des valeurs numériques. Livrable attendu Un test API fonctionnel validant correctement la valeur du champ total.

Contexte Une API GET /users retourne du JSON avec le header Content-Type: application/json. Le Problème Le test actuel vérifie une valeur incorrecte. expect(response.headers['content-type']).toBe('text/html'); Contraintes Corriger l’assertion pour vérifier que le Content-Type correspond au format JSON. Livrable attendu Un test API valide vérifiant correctement le header de réponse.

Contexte Une API GET /users retourne une liste d’utilisateurs avec un code 200 lorsque la requête réussit. Le Problème Le test actuel vérifie que la réponse retourne un code 201 au lieu de 200, ce qui provoque un échec systématique. const response = await api.get('/users'); expect(response.status).toBe(201); Contraintes Corriger uniquement l’assertion pour qu’elle corresponde au comportement réel de l’API. Ne pas modifier l’appel réseau. Livrable attendu Un test API valide vérifiant correctement le code de statut HTTP.

Contexte Une API GET /unknown retourne un code 404 lorsque la ressource n’existe pas. Le Problème Il faut écrire un test qui vérifie ce comportement. Contraintes Envoyer une requête vers une ressource inexistante et vérifier que le code de statut retourné est 404. Livrable attendu Un test API validant correctement la gestion d’erreur 404.

Contexte Une API GET /profile retourne un objet JSON contenant id, name et email. Le Problème Aucun test ne vérifie que la propriété email est bien présente dans la réponse. Contraintes Écrire un test qui parse la réponse JSON et vérifie que la propriété email existe et n’est pas vide. Livrable attendu Un test API simple validant la structure minimale attendue.

Contexte Une API GET /health doit répondre en moins de 500 ms. Le Problème Il faut ajouter un test simple de performance. Contraintes Mesurer le temps de réponse et vérifier qu’il est inférieur au seuil défini. Livrable attendu Un test API validant que le temps de réponse respecte le seuil de performance attendu.

Contexte Une API GET /product retourne un objet contenant un champ price. Le Problème Il faut s’assurer que price est bien un nombre. Contraintes Écrire un test qui vérifie que la propriété price existe et que son type est numérique. Livrable attendu Un test API simple validant le type du champ price.

Contexte Une API GET /orders retourne un tableau JSON d’objets commande. Le Problème Il faut vérifier que la liste contient au moins un élément. Contraintes Écrire un test qui vérifie que la réponse est un tableau et que sa longueur est supérieure à zéro. Livrable attendu Un test API validant que la liste retournée n’est pas vide.

Contexte Une API POST /orders crée une commande et retourne un objet contenant id, total et status. Une seconde requête GET /orders/{id} doit récupérer cette commande. Le Problème Le test actuel ne stocke pas correctement l’identifiant retourné. const response = await api.post('/orders', payload); const orderId = response.id; const order = await api.get(`/orders/${orderId}`); L’id se trouve en réalité dans response.data.id. Contraintes Corriger l’extraction de l’identifiant sans modifier la logique globale du test. Livrable attendu Un test API fonctionnel reliant correctement les deux requêtes.

Contexte Un test API enchaîne deux appels dépendants mais oublie d’attendre la résolution de la première requête. Le Problème const res = api.post('/login', credentials); const profile = await api.get('/profile'); La première requête n’est pas correctement attendue. Contraintes Corriger la gestion asynchrone en utilisant await correctement avant d’utiliser le résultat. Livrable attendu Un test API respectant correctement la gestion asynchrone des appels réseau.

Contexte Une API GET /products?page=1&limit=10 retourne un tableau paginé avec totalCount. Le Problème Le test actuel vérifie uniquement la longueur du tableau sans prendre en compte totalCount. expect(response.data.length).toBe(10); Contraintes Ajouter une validation cohérente entre totalCount et le nombre d’éléments retournés pour la page demandée. Livrable attendu Un test API validant correctement la logique de pagination.

Contexte Une API sécurisée nécessite un header Authorization: Bearer <token>. Le Problème Le test actuel oublie d’ajouter le préfixe Bearer dans le header. headers: { Authorization: token } Contraintes Corriger la construction du header pour inclure correctement le préfixe requis. Livrable attendu Un test API fonctionnel authentifié correctement.

Contexte Une API POST /users retourne un code 400 avec un message JSON lorsque l’email est déjà utilisé. Le Problème Le test actuel vérifie uniquement le code HTTP sans valider le message métier retourné. expect(response.status).toBe(400); Contraintes Ajouter une assertion vérifiant que response.data.message correspond exactement à "Email already exists". Livrable attendu Un test API complet validant à la fois le code et le message d’erreur.

Contexte Une API GET /dashboard retourne des données différentes selon le rôle (admin, user, manager). Le Problème Le test actuel ne couvre qu’un seul rôle. Contraintes Créer une structure data-driven testant plusieurs rôles avec des tokens différents. Vérifier que les données retournées correspondent aux permissions attendues pour chaque rôle. Livrable attendu Un test API paramétré couvrant plusieurs scénarios d’autorisation.

Contexte Une API GET /reports doit répondre en moins de 800 ms selon l’environnement. Le Problème Le test actuel utilise un seuil fixe, non adaptable selon staging ou production. Contraintes Implémenter un seuil configurable via variable d’environnement et comparer dynamiquement le temps de réponse avec cette valeur. Livrable attendu Un test API flexible validant la performance selon l’environnement ciblé.

Contexte Une API GET /subscriptions retourne des abonnements avec un champ active. Le Problème Si active est true, un champ expirationDate doit être présent. Contraintes Implémenter une logique conditionnelle dans le test pour vérifier la présence de expirationDate uniquement lorsque active est true. Livrable attendu Un test API capable de gérer des validations conditionnelles basées sur les données retournées.

Contexte Une API GET /invoice retourne un objet avec subtotal, tax et total. Le Problème Il faut vérifier que total correspond à subtotal + tax. Contraintes Extraire les valeurs numériques et comparer dynamiquement la somme avec le champ total. Gérer correctement les types numériques. Livrable attendu Un test API validant la cohérence métier des données financières.

Contexte Une API GET /users retourne une liste d’utilisateurs avec un sous-objet address contenant street, city et zip. Le Problème Il faut vérifier que chaque utilisateur possède un objet address valide avec toutes les propriétés obligatoires. Contraintes Parcourir la liste retournée et vérifier la présence et le type des champs id, email ainsi que address.street, address.city et address.zip. Livrable attendu Un test API validant la structure complète et cohérente des objets retournés.

Contexte Une API PUT /users/{id} met à jour les informations d’un utilisateur. Le Problème Il faut garantir que seules les propriétés modifiées changent et que les autres restent intactes. Contraintes Récupérer l’état initial via GET, effectuer la mise à jour puis récupérer à nouveau la ressource. Comparer dynamiquement les champs pour vérifier l’intégrité globale des données. Livrable attendu Un test API validant l’intégrité complète des données après opération de mise à jour.

Contexte Les tests API sont exécutés en parallèle en CI et créent des ressources via POST /users. Le Problème Des collisions apparaissent car les mêmes emails sont utilisés dans plusieurs exécutions simultanées. const payload = { email: "test@example.com" }; Contraintes Modifier la génération de données pour créer des emails uniques dynamiquement à chaque exécution. Vérifier que la ressource est correctement supprimée après test. Livrable attendu Une suite de tests API compatible avec l’exécution parallèle sans conflit de données.

Contexte Un processus métier crée une commande via POST /orders, déclenche un paiement via POST /payments puis confirme l’expédition via POST /shipping. Le Problème Si le paiement échoue, la commande doit être annulée via DELETE /orders/{id}. Le test actuel ne gère pas ce scénario d’échec. Contraintes Mettre en place un test orchestrant les trois appels. Implémenter une logique conditionnelle : si le paiement retourne un statut différent de "approved", déclencher automatiquement l’appel de suppression. Vérifier l’état final du système. Livrable attendu Un test API robuste validant un workflow transactionnel avec gestion d’erreur et rollback.

Contexte Une API sécurisée utilise des tokens JWT expirant après un court délai. Le Problème Les tests échouent lorsque le token expire entre deux requêtes. Contraintes Décoder le token pour vérifier sa date d’expiration. Si expiré, déclencher automatiquement une requête de rafraîchissement avant de poursuivre les appels protégés. Éviter toute duplication de logique. Livrable attendu Un test API autonome gérant dynamiquement l’expiration et le renouvellement des tokens.

Contexte L’API expose /v1/products et /v2/products avec des différences structurelles. Le Problème Il faut garantir que la version v1 reste rétrocompatible malgré les évolutions introduites en v2. Contraintes Créer des tests distincts pour chaque version et comparer les champs communs. Vérifier que les champs supprimés ou modifiés ne cassent pas les contrats existants. Livrable attendu Une suite de tests API assurant la conformité contractuelle et la rétrocompatibilité.

Contexte Une API critique doit maintenir un temps de réponse moyen inférieur à 300 ms sur 20 appels consécutifs. Le Problème Un test unique ne permet pas de vérifier la moyenne globale. Contraintes Exécuter la requête plusieurs fois dans une boucle contrôlée, accumuler les temps de réponse puis calculer la moyenne. Ajouter une assertion sur la moyenne calculée. Livrable attendu Un test API évaluant dynamiquement la performance moyenne sur plusieurs itérations.

Contexte GET /transactions expose des résultats paginés avec paramètres page et limit ainsi qu’un totalCount. Le Problème Il faut vérifier que toutes les pages cumulées ne contiennent ni doublons ni pertes de données. Contraintes Appeler dynamiquement plusieurs pages, stocker les identifiants retournés et vérifier l’unicité globale. Comparer le nombre total d’éléments collectés avec totalCount. Livrable attendu Un test API validant intégralement la logique de pagination et l’intégrité des données.

Contexte GET /users retourne une liste d’utilisateurs. GET /users/{id}/details retourne les informations détaillées. Le Problème Il faut garantir que les champs id et email sont cohérents entre les deux endpoints. Contraintes Extraire dynamiquement un utilisateur depuis la première réponse, appeler le second endpoint puis comparer les champs clés. Gérer correctement les appels asynchrones. Livrable attendu Un test API validant la cohérence des données entre endpoints dépendants.

Contexte Certaines routes comme DELETE /admin/users sont réservées aux administrateurs. Le Problème Il faut vérifier que les utilisateurs standards reçoivent un code 403 Forbidden. Contraintes Effectuer des appels avec différents rôles et vérifier que seuls les administrateurs obtiennent un code 200. Ajouter des assertions sur les messages d’erreur. Livrable attendu Un test API validant strictement les règles d’autorisation et la sécurité d’accès.

Contexte GET /contracts retourne des contrats de type "standard" ou "premium". Le Problème Certains champs comme prioritySupport sont obligatoires uniquement pour les contrats premium. Contraintes Définir un schéma JSON incluant des règles conditionnelles. Vérifier dynamiquement que les champs obligatoires sont présents selon la valeur du champ type. Livrable attendu Un test API validant la conformité structurelle et métier des objets retournés.