Tests d'API : vérifiez vos échanges avant l'interface

Les API web accessibles en HTTP, qu'elles soient REST ou SOAP, ainsi que les webhooks entrants. Le scénario pose l'appel, ses en-têtes et son corps, puis contrôle le code de retour et le contenu de la réponse.

Non. L'appel et les contrôles se construisent par assemblage de blocs, comme un scénario d'interface. C'est ce qui permet à un testeur non développeur de couvrir les services sans dépendre de l'équipe back.

Oui, et c'est le cas le plus utile. La valeur retournée par un appel, un identifiant de panier ou un jeton d'authentification par exemple, est réutilisée dans les appels suivants. La séquence complète devient un scénario unique.

Les secrets sont chiffrés au repos et ne sont jamais restitués en clair. Les jetons d'authentification s'obtiennent dans le scénario lui-même, ce qui permet de tester aussi leur renouvellement et leur expiration.

Oui, et c'est souvent la bonne façon de faire. Un scénario peut préparer une donnée par API pour gagner du temps, puis vérifier le résultat à l'écran. Le parcours réel traverse les deux, le test aussi.

Oui. Un bloc de validation de schéma JSON vérifie que la réponse respecte le contrat attendu : champs présents, types, valeurs autorisées. Un champ renommé ou passé de nombre à chaîne fait échouer le test, même si l’appel renvoie un code 200.

Oui, un bloc dédié envoie des requêtes SOAP et remonte l’erreur quand le service répond en faute. Les environnements qui gardent des services historiques n’ont donc pas besoin d’un outil séparé.

Oui, et c’est souvent le plus utile. Le code de réponse attendu est paramétrable : vous pouvez exiger un 403 pour vérifier qu’un profil n’a pas accès à une ressource, ou un 404 pour valider un cas d’erreur. Les codes d’erreur technique à remonter se déclarent séparément.

Le code de réponse, le corps et les en-têtes sont rangés dans des variables réutilisables aux étapes suivantes, et les journaux de la requête et de la réponse sont téléchargeables depuis le rapport. Un seuil de performance par requête permet aussi de faire échouer un appel trop lent.

En isolant les causes habituelles : un jeu de données dédié, une attente explicite entre deux appels dépendants, et un environnement dont on connaît l'état. Un échec qui ne se reproduit pas à la seconde exécution est un signal d'instabilité, pas un défaut applicatif.