Tests de réponses HTTP avec Postman

Postman est un logiciel qui permet de créer, stocker, organiser des requêtes HTTP de toute sorte : GET, POST, DELETE, etc… et de configurer toutes les données liées a ces requêtes : entêtes HTTP, entêtes d’authentification et contenu du corps de la requête par exemple. On peut aussi y générer la documentation d’une api avec des exemples et la partager. C’est un outil que j’utilise de temps en temps pour me faciliter la vie quand j’interagis avec des API et que j’apprécie beaucoup.

Je viens seulement de découvrir la fonctionnalité de test de réponse qui est intégrée à Postman. Après une première approche ça me semble très pratique. Je suis actuellement dans le cas où je dois mettre a jour une API utilisée par une application mobile. Cette application ne reçoit pas de mises à jour, et il faut donc que je modifie l’API tout en gardant le même schéma de donnée pour qu’elle puisse continuer à être fonctionnelle.

Cependant la mise à jour de mon API consiste à récupérer des données via une nouvelle URL. Cette URL renvoie globalement les mêmes informations, mais avec un format complètement différent. La structure de mon ancienne API est un schéma JSON très volumineus (environ 7000 lignes par requêtes avec des données imbriquées sur plusieurs niveaux). Pour mettre à jour l’API sans risquer de tout casser, il me faut un moyen de m’assurer que le format de sortie ne change pas entre mes anciennes modifications et mes nouvelles modifications.

C’est là qu’interviennent les tests Postman. Tester sur Postman utilise JavaScript avec une syntaxe très compréhensible. Par exemple, avec les 5 lignes de codes ci-dessous, je m’assure que la requête répond correctement une 200 avec un corps JSON.

pm.test("response must be valid and have a body", function () {
     pm.response.to.be.ok;
     pm.response.to.be.withBody;
     pm.response.to.be.json;
});

Ce qui m’intéresse c’est d’avoir la garantie que ma structure JSON est respectée malgré les modifications que je vais appliquer. Pour cela, je vais devoir tester chaque niveau de mon JSON avec les types de données attendus. Si j’attend un tableau je peux le définir. Pareil pour une chaîne de caractère ou un nombre.
Dans l’exemple ci-dessous, le test ne passera que si la structure JSON est composée au premier niveau des deux clés “user” et “trips”. S’il y a des clés en trop ou en moins, le test ne passe pas et je sais que quelque chose est cassé ou incorrect.

pm.test("response must be have correct formatting", function () {
    const json = pm.response.json()
    pm.expect(json).to.have.all.keys('user', 'trips')
});

Si je m’attends à un tableau, je peux facilement écrire :

pm.expect(value).to.be.an("array")
pm.expect(value).to.be.a("string")
pm.expect(value).to.be.a("number")

En utilisant cette notation je peux très vite décrire ma structure JSON et m’assurer que tout fonctionne avant de faire mes modifications d’API.
Ainsi, si je vois comme sur la capture ci-dessous que les tests deviennent rouge, quelque chose ne va pas. Si je laisse tel quel, l’affichage ou la fonctionnalité sur l’application risque d’être cassé pour l’utilisateur final.

Dernière chose : comme c’est du Javascript qui est utilisé pour les tests, c’est facile d’écrire sa propre logique, ses propres fonctions, etc… Je n’en ai pas encore eu l’utilité mais il est possible d’écrire des tests bien plus poussés que ce que j’ai montré plus haut.
D’ailleurs, par défaut, il y a intégré les modules NodeJS « moment« , « lodash » et « querystring » et ils peuvent être directement utilisés dans le code. Et il est même possible d’utiliser des librairies externes, via des CDN par exemple.

Au final je suis content de cette découverte qui me permet rapidement et facilement de répondre à mon besoin de sécurité suite aux modifications que je vais faire sur mon API. N’ayant pas de visibilité sur l’utilisation de l’API par l’application mobile, je dois m’assurer de ne rien casser. La mise en place des tests me permet d’être plus serein que tout continue à fonctionner comme prévu. Même s’il ne faut pas oublier que les tests permettent seulement de révéler la présence de défaut, et pas leur absence.