De nos jours, il n’est pas un service du web qui ne soit accessible au travers d’APIs. Pour rappel, les API’s sont des fournisseurs de données que l’on peut utiliser dans une grande variété de clients, allant du site Web (avec des frameworks comme Angular, React, etc), des applications mobiles ou même depuis d’autres API’s.

Si vous avez eu à développer des API REST, vous avez sans doute dû les tester, voire même créer des scénarios. Peut-être êtes-vous tombé sur Postman pour effectuer quelques requêtes ? Mais sans doute que vous n’avez fait qu’effleurer la puissance de cette application. Si le développeur y trouvera bien sûr son compte, Postman a bien d’autres applications dont nous allons parler .

 

Première requête

La première fois que vous avez lancé Postman, vous avez dû essayer de créer votre première requête. Peut-être vous êtes vous demandé pourquoi l’application insistait tant pour faire partie d’une collection. Après tout, vous ne vouliez QUE lancer une requête et basta !

Votre requête créée, vous avez l’écran suivant :

Les 4 premiers onglets sont assez familiers pour qui a déjà fait une requête HTTP :

  • Params : permet de définir les paramètres de l’URL,
  • Authorization : permet de configurer la méthode d’authentification,
  • Headers : cet onglet est évident. A noter que si vous avez configuré une méthode d’authentification, les paramètres seront automatiquement insérés dans cet onglet. De même, le format de votre body, le Content-Type sera rempli ici,
  • Body : le body peut adopter plusieurs formats, du json au multipart-form.

Jusqu’ici, on se dit que ça ressemble à Swagger, pas la peine d’en faire un plat ! Si vous souhaitez d’ailleurs en savoir plus sur la mise en place de Swagger, retrouvez notre article “Comment se matérialise une API ?“.

Les autres onglets sont effectivement plus intéressants :

  • Pre-Request Scripts : Vous pourrez ici définir un script Javascript qui sera joué avant la requête. Pour définir des variables utilisées dans la requête (date du jour avec moment.js par exemple).
  • Tests : Là aussi, on peut écrire un script qui sera exécuté une fois que la requête aura abouti. Comme son nom l’indique, c’est dans cet onglet qu’on pourra définir des assertions sur le résultat. Nous y reviendrons.
  • Settings :  Il rassemble différents paramètres booléens sur la requête.

 

Utilisation des variables

Postman dispose d’un système de variable très fournis et très pratique.

En effet, différents champs d’actions de ces variables sont définis, voici les plus courantes et l’utilisation que vous pouvez faire d’elles :

  • Global : La portée de ces variables est définie pour tout Postman, quel que soit la collection ou l’environnement.
  • Collection : La portée est limitée à la collection.
  • Environment : Porté à l’environnement courant. En principe, on y accède qu’en lecture.
  • Data : Sert surtout pour injecter des données externes. Nous y reviendrons dans mon prochain article.
  • Local : La portée est limitée au script (Pre-Request Script ou Test).

 

Tout en haut de l’écran, on trouve un menu déroulant définissant les environnements :

Une fois défini, il est possible d’utiliser ces variables avec la syntaxe “Moustache” :

{{m_valueDate}}

Cette syntaxe est utilisable presque partout :

  • Dans la barre de requête :

 

  • Dans les champs des onglets Params, Authorization ou Header :
  • Body :
  • Seule exception, dans les scripts javascript, il faut utiliser un helper (voir plus bas).

 

 

Utilisation de l’onglet test

La grande édition permet de saisir du code javascript qui sera exécuté lorsque la requête aura répondu.

 

Test d’erreur

La première utilisation de cet onglet, c’est de vérifier l’état de la réponse à la requête. Postman défini l’objet pm qui sert un peu à tout. Pour tester si la requête est en erreur, il suffit d’écrire :

pm.response.to.not.be.error

Extraction de valeur

Qui dit réponse, dit valeur. Selon le type de la réponse, il existe de nombreux helper sur l’objet pm pour extraire les valeurs, indiquons la fonction pm.response.json() qui est très pratique.

Puisque nous avons une valeur, il peut être intéressant de la conserver pour un usage ultérieur :

pm.globals.set("valueDate", val);

Je ne détaille pas ici le système des variables.

 

Assertion

Puisque nous pouvons tester l’état de la réponse, que nous pouvons extraire une valeur de cette réponse, peut-être pouvons-nous tester sa conformité à une contrainte ?

pm.expect(jsonData.value).to.eql(100);

 

Et puisque nous en sommes là, nous pouvons carrément écrire un vrai test :

pm.test("Your test name", () => {
var jsonData = pm.response.json();
pm.expect(jsonData.value).to.eql(100);
});

On commence ici à entrevoir quelque chose…

 

 

Collection

Nous venons de constater que nous pouvons faire extraire des valeurs d’une requête et faire des assertions sur la réponse. C’est bien, mais ça serait super si on pouvait enchaîner les requêtes !

C’est un des usages des collections ! Les collections peuvent contenir :

  • Des requêtes,
  • Des dossiers.

Notez le menu Export, il nous sera très utile dans un prochain article. Et tout en haut, la petite flèche parait très tentante… Essayons.

Vous avez compris, le bouton Run permet d’exécuter les requêtes de la collection, dans l’ordre. Les collections permettent plusieurs cas d’utilisation :

  • Test d’un scénario sans Frontend,
  • Description de séquence d’appel : pour un consommateur de l’API,
  • Tests de non-régressions,
  • Tests de performances.

Sur cet écran, on configure notre run. On peut désactiver certains calls et même réordonner les requêtes.

La fenêtre suivante détaille le déroulement des requêtes et leurs résultats.

 

Pour conclure

Ce court article n’a fait qu’effleurer la puissance de Postman pour le développeur, la consultation de la documentation officielle détaille tout cela.

Nous verrons dans un prochain article comment automatiser l’exécution de ces scénarios dans une chaîne d’intégration continue. A très vite !