Edit du 08 mars 2020: merci à Ali El Malhouf pour ses propositions d’amélioration.
Ma présentation de l’outil se base sur un usage que j’ai terminé en août dernier. Il est possible que des évolutions soient disponibles entre temps. N’hésitez pas à les partager en commentaires.
Postman en bref
Postman est une plateforme collaborative de développement des API.
Il permet:
– d’envoyer des requêtes REST, SOAP ou GraphQL pour solliciter vos API
– simuler des endpoints (mocking)
– Générer et publier la documentation de vos API
– Surveiller la performance de vos API
– Travailler de manière collaborative avec les espaces de travail
– Automatiser vos tests d’API
C’est ce dernier volet qui nous intéresse plus particulièrement.
Postman organise une suite de test dans ce qu’il appelle une collection.
Une collection est une suite de requêtes (REST, SOAP ou GraphQL) qui s’enchaînent en partageant un même contexte. Le contexte est partagé durant toute l’exécution. On y retrouve les cookies par exemple qui ont été déposés par une requête précédente mais aussi des variables créées à la volée. Cela est particulièrement pratique pour monter des sessions Web et tester des enchaînements de requêtes qui ont des dépendances.
Pour chaque requête, Postman propose d’exécuter des prérequis et un script de test. C’est dans ce dernier script qu’on va ajouter des vérifications sur la réponse obtenue (assertion): C’est la partie testing de l’outil.
Les deux schémas qui suivent sont issus de la documentation de postman et illustrent l’enchaînement entre prérequis, requête, réponse et script de test.
Ces prérequis et script de test sont en Javascript et le tout repose sur une base NodeJS pour l’exécution. Cela apporte une flexibilité pour partager des variables entre les requêtes d’une même collection.
Postman propose un client lourd et un client Web pour gérer ses collections et les exécuter. Il est aussi possible de les exécuter dans une intégration continue avec l’outil Newman. Cela est facilité par la proposition de récupérer ses collections avec un API et facilite donc l’intégration dans une CI.
Points forts et axes d’amélioration
Ses points forts sont:
– faciliter à prendre en main avec des tutoriels qui vous guident pas à pas au démarrage
– faciliter pour construire les vérifications avec des snippets prêtes à l’emploi mais aussi la syntaxe ChaiJS BDD
– un système d’exécution dans le client lourd qui fourni un bon niveau de log pour identifier une assertion qui échoue ou un problème dans le script de test.
– une gestion de la configuration avec plusieurs niveaux pour mieux gérer les variables.
– une API pour récupérer directement les collections et faciliter l’intégration continue.
– exploitation des jeux données par import csv ou json facilitant la mise en oeuvre d’une combinatoire d’exécution
Dans les versions futures, j’espère qu’ils vont améliorer les éléments suivants:
– Le partage de requêtes entre collections qui est un vrai frein lorsqu’on veut faire du test de bout-en-bout avec uniquement les API.
– la gestion des cookies
– Une intégration native à des outils de gestion de configuration comme gitlab.
– un reporting natif. Il est cependant possible de passer par l’outil tiers htmlextrareport pour obtenir des rapports plus complet.
Conclusion
Postman est un bon outil pour initier rapidement des vérifications de vos API. Dans un contexte full développement d’une API, il doit être très puissant. Si on se limite à la partie automatisée pour faire du test de bout-en-bout des API, on va vite arriver à des limites de maintenabilité, de stockage et partage de collections et in fine d’exécution en contexte intégration continue.
Pour en savoir plus, je vous invite à aller directement sur le site de Postman https://www.postman.com/ (en anglais) mais aussi de découvrir le cours d’Amber Race sur l’université du test automatisé: https://testautomationu.applitools.com/exploring-service-apis-through-test-automation/ (en anglais).
Un article d’Ali très intéressant pour compléter la présentation de cet outil (en anglais): https://medium.com/younited-tech-blog/generate-automated-test-reports-using-postman-b9c8cd53b955
4 réponses
Très bon article, résumant bien Postman ! 🙂
Niveau points forts, j’aurais ajouté :
– Possibilité de partager les collections sur le workspace de l’équipe.
– Communauté active (pour avoir déjà posé quelques questions, on me répond toujours)
– De très nombreuses nouvelles fonctionnalités au fur et à mesure des versions publiées
Points faibles, j’aurais ajouté :
– Manque de filtres sur les collections/requêtes. Il n’existe qu’un seul filtre (permettant de filtrer sur le nom des requêtes + collections). Il serait bien de pouvoir avoir des filtres avancés (filtrer sur le contenu de la tab « Tests » ou « Pre-request script », sur la description, etc…). On peut vite s’y perdre quand on a beaucoup de collections sur le workspace local.
– La documentation n’est pas vraiment complète et détaillée, lorsqu’on s’attaque à des points techniques au niveau de l’outil.
– J’aimerais bien qu’on puisse intégrer beaucoup plus facilement la notion de loop dans une collection, mais là je chipote un petit peu 😉
Je ne m’en fais pas pour les points négatifs, je pense que d’ici quelques mois et années, Postman deviendra bien + complet (bien qu’il rempli très bien son rôle aujourd’hui).
Cordialement
Merci beaucoup pour les compléments.