Newman vs Postman: Quelle est la Différence ?

Newman et Postman ne sont pas des concurrents. Ils sont les deux moitiés d'un même flux de travail. Postman est l'application de bureau où vous concevez des requêtes, écrivez des tests et explorez des API manuellement. Newman est l'outil en ligne de commande qui prend les collections que vous avez créées dans Postman et les exécute sans interface graphique. Si Postman est l'atelier, Newman est la machine qui exécute votre travail terminé selon un calendrier.

La confusion vient généralement de la question « lequel devrais-je utiliser ? » La réponse honnête est : les deux, à différentes étapes. Vous créez dans Postman parce qu'une interface graphique rend cela rapide. Vous exécutez dans Newman parce qu'un pipeline ne peut pas cliquer sur des boutons. Cet article explique précisément la relation, montre où chacun a sa place et décrit comment intégrer Newman dans un pipeline CI/CD.

Qu'est-ce que Postman

Postman est une plateforme API graphique. Vous l'installez en tant qu'application de bureau, créez des requêtes, les organisez en collections et dossiers, et attachez des environnements qui contiennent des variables comme les URL de base et les jetons. Après chaque réponse, Postman exécute les scripts de test JavaScript que vous écrivez dans l'onglet Tests de la requête.

Un script de test Postman vérifie la réponse :

pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});

pm.test("Order total is a positive number", function () {
    const body = pm.response.json();
    pm.expect(body.total).to.be.a("number");
    pm.expect(body.total).to.be.above(0);
});

Postman est conçu pour le travail interactif. Un développeur déboguant un nouveau point de terminaison envoie des requêtes, inspecte les réponses, ajuste les en-têtes et itère en quelques secondes. Un ingénieur QA transforme ces requêtes en une suite de régression sauvegardée. Les équipes partagent des espaces de travail afin que tout le monde travaille à partir de la même collection. Tout cela bénéficie d'une interface visuelle. Notre guide sur comment tester les API avec Postman couvre ce flux de travail en profondeur.

Ce pour quoi Postman n'est pas conçu, c'est l'exécution sans surveillance. Exécuter une suite signifie ouvrir l'application et cliquer sur le Collection Runner. C'est bien pour une personne à un bureau. C'est inutile pour un serveur de build.

Qu'est-ce que Newman

Newman est l'outil officiel d'exécution de collections en ligne de commande de Postman. C'est un paquet npm open-source, gratuit à utiliser, qui exécute exactement les mêmes fichiers de collection que ceux produits par Postman. Vous exportez une collection sous forme de fichier JSON, la confiez à Newman, et Newman exécute chaque requête et chaque script de test, puis rapporte les résultats à votre terminal.

Installez-le avec npm :

npm install -g newman

Exécutez une collection :

newman run orders-api.postman_collection.json \
  --environment staging.postman_environment.json

Newman exécute chaque requête, exécute les mêmes assertions pm.test que Postman, et affiche un résumé. Le détail clé est que Newman utilise le même moteur d'exécution que Postman, donc une collection qui réussit dans l'interface graphique se comporte identiquement en ligne de commande. Il n'y a pas de réécriture ni de langage de test distinct.

Newman se termine également avec un code de statut non nul lorsqu'un test échoue. Ce comportement unique est ce qui le rend précieux pour l'automatisation : un système de build lit ce code de sortie et fait échouer le build en cas d'assertion brisée. Une exécution réussie se termine avec zéro et le pipeline continue.

Comparaison côte à côte

Le fichier JSON de la collection est le pont entre les deux. Vous le construisez une fois dans Postman, et Newman l'exécute indéfiniment en automatisation.

Comment Newman s'intègre dans le CI/CD

Newman existe principalement pour intégrer les tests d'API dans l'intégration continue. Le modèle est cohérent entre les fournisseurs. Vous commettez les fichiers de collection et d'environnement exportés dans votre dépôt, installez Newman dans le pipeline, l'exécutez et laissez le code de sortie bloquer le build.

Voici le flux de travail en étapes numérotées :

1. Exporter depuis Postman. Dans Postman, exportez votre collection et son environnement en tant que fichiers JSON.
2. Commitez-les dans le dépôt. Stockez-les à côté de votre code afin qu'ils soient versionnés avec l'API.
3. Installez Newman dans le pipeline. Ajoutez npm install -g newman à la tâche CI, ou utilisez l'image Docker postman/newman.
4. Exécutez la collection. Appelez newman run avec les fichiers de collection et d'environnement.
5. Verrouillez sur le code de sortie. Si un test échoue, Newman se termine avec un code non nul et le fournisseur CI marque le build comme échoué.

Une étape GitHub Actions ressemble à ceci :

- name: Run API tests
  run: |
    npm install -g newman
    newman run orders-api.postman_collection.json \
      --environment staging.postman_environment.json \
      --reporters cli,junit \
      --reporter-junit-export results.xml

L'option --reporters est bonne à connaître. Newman est livré avec des générateurs de rapports intégrés pour l'interface de ligne de commande (CLI) et JUnit XML, et les générateurs de rapports de la communauté ajoutent une sortie HTML et plus encore. JUnit XML en particulier permet aux tableaux de bord CI d'afficher les résultats des tests nativement. Pour une présentation complète, consultez notre guide sur l'automatisation des tests d'API en CI/CD et les spécificités de l'automatisation des tests d'API avec GitHub Actions.

Options de ligne de commande Newman utiles

Newman dispose d'un ensemble d'options qui gèrent les aspects délicats des exécutions automatisées. En connaître quelques-unes fait la différence entre une tâche fragile et une tâche fiable.

L'option --iteration-data indique à Newman un fichier CSV ou JSON et exécute la collection entière une fois par ligne, en substituant les valeurs de la ligne en tant que variables. C'est ainsi que vous pilotez une exécution Newman par les données : une collection, de nombreuses entrées. L'option --iteration-count répète simplement la collection un nombre fixe de fois.

L'option --bail indique à Newman de s'arrêter à la première défaillance au lieu d'exécuter le reste de la collection. Dans un pipeline à retour rapide, c'est souvent ce que vous voulez, car une seule requête défaillante signifie généralement que le build va déjà échouer. L'option --timeout-request limite le temps que peut prendre une seule requête, ce qui protège la tâche d'un blocage sur un service qui ne répond pas.

L'option --delay-request insère une pause entre les requêtes, utile lorsqu'une API applique des limites de débit. Et --folder vous permet d'exécuter uniquement un dossier nommé à l'intérieur d'une collection, de sorte qu'une tâche de test de fumée peut exécuter un petit sous-ensemble tandis que la tâche de régression complète exécute tout. Aucune de ces options n'existe dans le Collection Runner de l'interface graphique de Postman sous la même forme scriptable, et ensemble, elles expliquent pourquoi Newman est le choix pratique pour l'exécution sans surveillance.

Erreurs courantes lors du passage de Postman à Newman

Quelques problèmes se manifestent encore et encore lorsque les équipes transfèrent pour la première fois une collection de l'interface graphique vers Newman. Le plus courant est celui des valeurs codées en dur. Une requête qui fonctionnait dans Postman parce qu'une variable était définie dans l'environnement actif échouera dans Newman si ce fichier d'environnement n'est pas passé avec --environment. Exportez et fournissez toujours l'environnement explicitement.

Le second est de dépendre du cloud Postman. Les collections qui référencent des variables synchronisées dans le cloud ou utilisent des fonctionnalités liées à une session Postman connectée peuvent ne pas se comporter de la même manière lorsqu'elles sont exécutées à partir d'un simple fichier JSON. Testez le fichier exporté localement avec Newman avant de lui faire confiance en CI.

Le troisième est d'oublier que les fichiers exportés deviennent obsolètes. Le fichier JSON de la collection dans votre dépôt est un instantané. Si quelqu'un modifie la collection dans Postman et ne réexporte pas, le pipeline continue d'exécuter l'ancienne version. Les équipes résolvent ce problème par la discipline, en traitant l'exportation comme un commit délibéré, ou en passant à un outil où la définition du test et l'exécuteur sont la même chose.

Quand utiliser chacun

Utilisez Postman lorsqu'un humain effectue le travail. Concevoir une nouvelle API, déboguer un appel échoué, explorer un service tiers, construire et affiner une suite de tests : tout cela est interactif et doit se faire dans l'interface graphique.

Utilisez Newman lorsqu'aucun humain n'est présent. Exécuter la suite sur chaque pull request, selon un calendrier nocturne, ou comme test de fumée après déploiement : tout cela nécessite un outil qui s'exécute à partir d'un script et rend compte via un code de sortie.

En pratique, la limite est « création contre exécution ». Vous n'en choisirez pas un plutôt que l'autre. Vous utiliserez Postman pour créer et Newman pour automatiser, et le fichier de collection transportera votre travail entre eux. Si vous préférez ne pas du tout maintenir un exécuteur distinct, notre guide sur l'exécution des collections Postman en CI sans Newman couvre d'autres options.

Une alternative unifiée : Apidog

Maintenir une configuration Postman-plus-Newman signifie exporter des collections, garder les fichiers JSON synchronisés et gérer un exécuteur distinct. Apidog regroupe tout cela en une seule plateforme. Vous concevez des API, déboguez des requêtes et créez des scénarios de test automatisés avec des assertions visuelles dans la même application, puis exécutez ces scénarios en CI/CD avec l'exécuteur en ligne de commande intégré. Il n'y a pas d'étape d'exportation et de synchronisation car les définitions de test et le moteur d'exécution vivent ensemble.

Apidog couvre également la conception d'API, les serveurs de maquettes et les tests de performance dans le même espace de travail, de sorte que les tests fonctionnels que vous créez sont les mêmes que ceux que votre pipeline exécute. Vous pouvez télécharger Apidog et utiliser ses fonctionnalités de test gratuitement. Pour une comparaison des outils dans cet espace, consultez notre liste des meilleures alternatives à Postman pour les tests d'API.

Questions fréquemment posées

Newman est-il un remplaçant de Postman ?

Non. Newman ne peut pas créer ou modifier des collections ; il ne fait que les exécuter. Vous avez toujours besoin de Postman, ou d'un autre outil, pour créer la collection et écrire les scripts de test. Le rôle de Newman est d'exécuter ce travail terminé sans interface graphique. Ils sont complémentaires, pas interchangeables.

Newman est-il payant ?

Non. Newman est open source et entièrement gratuit. Il est distribué en tant que paquet npm. Postman a une version gratuite ainsi que des plans payants pour les grandes équipes, mais Newman lui-même n'a aucun coût, quelle que soit la façon dont vous l'utilisez.

Mes tests Postman se comporteront-ils de la même manière dans Newman ?

Oui. Newman utilise le même moteur d'exécution que Postman, de sorte que les assertions pm.test et la logique des requêtes s'exécutent de manière identique. Une collection qui réussit dans le Postman Collection Runner produira les mêmes résultats dans Newman, ce qui la rend sûre pour l'intégration continue.

Comment Newman signale-t-il les échecs de test ?

Newman affiche un résumé dans le terminal et se termine avec un code de statut non nul lorsqu'un test échoue. Ce code de sortie est la manière dont les systèmes CI détectent les échecs. Newman prend également en charge les générateurs de rapports, y compris JUnit XML et HTML, afin que les résultats puissent alimenter les tableaux de bord et les rapports de build.

Puis-je exécuter Newman sans installer Node.js ?

Newman est un paquet npm, donc une installation directe nécessite Node.js. Pour éviter cela, utilisez l'image Docker officielle postman/newman, qui regroupe tout. L'approche Docker est courante dans les environnements CI où vous ne voulez pas gérer un environnement d'exécution Node.js dans la tâche de build.