Questions d'entretien test d'API

Le test d'API vérifie directement la couche service — vous envoyez une requête et faites vos assertions sur la réponse, sans navigateur. Vous vérifiez le statut, le corps, les en-têtes et le comportement là où la logique vit réellement.

Vous testez ici parce que c'est plus rapide, plus stable et plus proche du bug que l'UI. Une règle métier cassée apparaît dans la réponse de l'API bien avant de se manifester comme un bouton mal étiqueté, et un test d'API n'est pas instable à cause d'un rendu lent.

Un test unitaire vérifie une fonction isolée, généralement avec tout ce qui l'entoure mocké — il prouve que l'unité de code est correcte. Un test d'API frappe un service en cours d'exécution via HTTP et vérifie tout le chemin de la requête à la réponse : routage, sérialisation, auth, la base de données, tout.

Les tests unitaires sont ceux du développeur ; les tests d'API sont souvent les vôtres. Ils se recoupent en intention mais pas en portée — un test unitaire qui passe dit que la fonction marche ; un test d'API qui passe dit que l'endpoint déployé marche.

GET lit une ressource et ne change rien. POST en crée une nouvelle. PUT remplace une ressource en totalité. PATCH en met à jour une partie. DELETE la supprime.

La distinction que les examinateurs écoutent, c'est la sûreté et l'idempotence : GET est sûr (aucun effet de bord) ; GET, PUT et DELETE sont idempotents (deux fois la même requête = même état final) ; POST n'est ni l'un ni l'autre — appelez-le deux fois et vous pourriez créer deux ressources.

2xx a réussi — 200 OK, 201 Created, 204 No Content. 3xx redirection. 4xx la faute du client — 400 requête erronée, 401 non authentifié, 403 interdit, 404 non trouvé, 409 conflit, 422 non traitable. 5xx la faute du serveur — 500 erreur interne, 503 indisponible.

La ligne qui compte en entretien : 401 veut dire « je ne sais pas qui vous êtes », 403 veut dire « je sais qui vous êtes et vous ne pouvez pas ». Les confondre est un bug d'API réel et courant que vous devriez tester.

PUT remplace toute la ressource — ce que vous n'envoyez pas, le serveur peut le vider. PATCH ne met à jour que les champs que vous envoyez et laisse le reste tranquille.

Le test qui attrape le vrai bug : PATCH un seul champ, puis GET la ressource et vérifiez que chaque AUTRE champ est inchangé. Les équipes implémentent régulièrement PATCH comme un PUT déguisé, mettant silencieusement à null les champs que le client n'a pas inclus — et ça n'apparaît que lorsqu'un utilisateur perd des données.

Des ressources adressées par URL (/orders/42), sur lesquelles on agit avec des méthodes HTTP, communiquant via des représentations (généralement JSON), sans état — chaque requête porte ce dont le serveur a besoin, rien n'est retenu entre les appels.

En pratique la plupart des API « REST » sont pragmatiques, pas conformes au manuel. Ce qui compte pour les tests, c'est l'absence d'état : si un endpoint dépend d'un état de session côté serveur caché, c'est votre terrain de chasse aux bugs — rejouez une requête isolément et voyez si elle marche toujours.

D'abord obtenez une identification valide comme le ferait un vrai client, puis prouvez que l'endpoint la fait respecter. Pour un flux Bearer/JWT : obtenez un token, envoyez-le dans l'en-tête Authorization, et vérifiez que le chemin nominal marche.

Puis testez la mise en application, là où sont les bugs : pas de token → 401, token mal formé → 401, token expiré → 401, token valide mais mauvaises permissions → 403, et le token d'un autre utilisateur → il ne peut pas atteindre vos données. Les cas négatifs sont le test, pas le chemin nominal.

Le code de statut est le minimum. Ensuite : la structure du corps (les champs dont vous dépendez existent, avec les bons types), les valeurs (celles que la requête aurait dû changer), les en-têtes clés (content-type, cache, rate-limit), et le temps de réponse s'il est sous budget.

Un 200 avec un corps cassé est l'échec qu'un test paresseux rate. Affirmer status == 200 et s'arrêter, c'est comme ça qu'une suite verte livre un null là où devrait figurer un nom de client.

Vous affirmez que la réponse correspond à une forme définie — noms de champs, types, ce qui est requis, ce qui est nullable — avec un validateur JSON Schema ou un modèle typé (pydantic, un POJO, un schéma Zod). Une seule assertion couvre toute la structure.

Vous vous embêtez parce que les vérifications de valeurs et de schéma attrapent des bugs différents. Votre test de valeur affirme price == 41.98 ; il ne dit rien du jour où price commence à arriver comme une chaîne, ou où un champ requis disparaît silencieusement. Le schéma est votre alerte précoce de dérive de contrat.

Démontez le chemin nominal : champs requis manquants, mauvais types, valeurs vides et null, valeurs limites (0, négatif, longueur max, un de plus), JSON mal formé, champs supplémentaires inattendus, et envois en double.

Puis ceux qu'on oublie : des entrées ressemblant à du SQL/script dans les champs texte, une charge énorme, un mauvais content-type, et un accès non autorisé à la ressource de quelqu'un d'autre. Le chemin nominal est un test ; la couverture intéressante, c'est tout ce que l'endpoint devrait rejeter proprement — avec le bon 4xx, pas un 500.

Chaque test possède ses données. Créez ce dont vous avez besoin dans le setup (via l'API ou un seed), utilisez-le, et nettoyez-le dans le teardown — pour que les tests ne dépendent pas d'un enregistrement partagé qu'un autre test pourrait changer ou supprimer.

L'anti-pattern, ce sont les tests qui supposent que « l'utilisateur 42 existe » ou tournent dans un ordre fixe. Ceux-là passent en local et échouent en CI dès qu'ils tournent en parallèle ou que quelqu'un modifie le seed. Des données autonomes, c'est ce qui rend une suite d'API sûre à exécuter en parallèle et répétable.

Postman pour explorer, des vérifications ponctuelles, et partager une collection avec des gens qui ne codent pas — c'est rapide de fouiller une API et de voir ce qu'elle fait. Le code (REST Assured, Python requests + pytest) pour tout ce qui doit tourner en CI, partager du setup, boucler sur des données, ou vivre à côté du reste de l'automatisation.

La réponse honnête en entretien : commencez dans Postman pour comprendre l'API, puis reconstruisez les vérifications en code une fois qu'elles valent la peine d'être gardées. Les collections Postman en CI via Newman existent, mais un vrai framework les dépasse.

En couches. Une fine couche client/service enveloppe les appels HTTP (un endroit par endpoint, pour qu'un changement d'URL soit une seule modification). Les tests appellent ces méthodes et affirment — ils ne construisent jamais de requêtes brutes en ligne. La config (URLs de base, identifiants) vient de l'environnement, pas codée en dur. Le setup/teardown des données est dans les fixtures. Les schémas vivent en un seul endroit et sont réutilisés.

Le test se lit comme une intention — createOrder(); assertStatus(201); assertSchema(order) — et la mécanique HTTP se cache derrière. Cette séparation est ce qui permet à la suite de survivre à une API qui n'arrête pas de changer.

Pagination : vérifiez que la taille de page est respectée, que le curseur/offset avance sans répéter ni sauter d'éléments, que la dernière page se termine proprement, et que les totaux sont cohérents tant que les données sont stables. Le bug classique, ce sont les éléments qui se décalent entre les pages quand la liste sous-jacente change en cours de parcours.

Limitation de débit : envoyez des requêtes au-delà de la limite et vérifiez que vous obtenez 429 (pas 500), que les en-têtes Retry-After/limite sont corrects, et que le compteur se réinitialise quand il le devrait. Et vérifiez que la limite est par la bonne clé — par utilisateur, pas globale, sinon un client bruyant affame tout le monde.

Explorez d'abord, documentez au fur et à mesure. Observez le trafic réseau de l'app pour voir les vraies requêtes, ou lisez le code si vous le pouvez. Pour chaque endpoint, cartographiez la méthode, les paramètres requis et optionnels, l'auth, et la forme de la réponse en faisant des appels et en observant — construisant une mini-spec à partir de ce que vous trouvez.

Puis transformez cette spec en tests : le chemin nominal, les cas négatifs, le schéma que vous venez de rétro-concevoir. Le compte rendu que vous produisez est lui-même précieux — vous avez documenté une API non documentée, ce dont l'équipe avait probablement besoin de toute façon.

Envoyez le POST avec un corps valide, vérifiez 201 et que la réponse inclut le nouvel id et renvoie les données. Puis GET cet id et vérifiez que la ressource a réellement persisté avec les bonnes valeurs — la création n'est pas prouvée tant que vous ne pouvez pas la relire.

Puis les bords : POST la même chose à nouveau (doublon — renvoie-t-il 409 ou en crée-t-il un second ?), POST avec un champ requis manquant (400/422), et nettoyez la ressource créée dans le teardown. Le round-trip plus les négatifs, c'est le test complet ; n'affirmer que le 201 en est la moitié.