Exécuter Collections Postman en CI Sans Newman

En bref

Newman, l'exécuteur CLI officiel de Postman, nécessite npm et Node.js dans votre pipeline CI. Cela introduit un risque lié à la chaîne d'approvisionnement, ajoute une surcharge de gestion des dépendances et, sur le forfait gratuit de Postman, les exécutions de collections via l'API sont désormais soumises à des limites de débit. Ce guide présente trois alternatives pour exécuter des tests d'API en CI sans Newman : l'exécuteur CLI d'Apidog, k6 et Hurl. Apidog est la voie la plus directe si vous avez des collections Postman existantes, car il les importe nativement et n'a aucune limite par exécution.

💡

Apidog est une plateforme de développement d'API tout-en-un gratuite. Son exécuteur CLI exécute des collections compatibles Postman en CI sans dépendance npm et sans limite de nombre d'exécutions. Essayez Apidog gratuitement, aucune carte de crédit requise.

button

Introduction

Newman était une bonne idée. Un outil CLI qui exécute les collections Postman dans les pipelines CI a rendu les tests d'API portables et automatisables. Il bénéficiait de la confiance de la marque Postman, s'intégrait à GitHub Actions via une action communautaire populaire, et fonctionnait assez bien pour que de nombreuses équipes construisent leur stratégie d'automatisation des tests d'API autour de lui.

Puis trois problèmes sont apparus.

Premièrement, Newman est un package npm. Chaque pipeline qui l'utilise tire du registre npm au moment de la construction. La compromission de ua-parser-js en 2021 et l'incident de node-ipc en 2022 ont démontré que les attaques de la chaîne d'approvisionnement npm ne sont pas théoriques. Les équipes de sécurité ont commencé à se demander pourquoi la couche de test d'API avait besoin de npm.

Deuxièmement, Postman a commencé à limiter les exécutions de collections sur les forfaits gratuits et basiques. Les équipes qui comptaient sur l'exécution de collections via l'API Postman dans le cadre de leur CI ont atteint les quotas et ont dû soit mettre à niveau leurs plans, soit repenser leurs pipelines.

Troisièmement, le rythme de maintenance de Newman a ralenti. Les problèmes restent ouverts sur GitHub pendant des mois. Certaines API de script Postman plus récentes ont un support incohérent dans Newman.

Le résultat : les développeurs qui ont construit des pipelines CI sur Newman recherchent maintenant des alternatives. Voici ce qui est disponible.

Option 1 : Apidog CLI (recommandé pour les utilisateurs de collections Postman)

L'exécuteur CLI d'Apidog est le remplacement fonctionnel le plus proche de Newman si vous avez déjà investi dans les collections Postman.

Ce qu'il prend en charge

Format Postman Collection v2 et v2.1
Environnements Postman (exportation JSON)
pm.test, pm.expect, pm.environment.set, pm.collectionVariables.set
Scripts de pré-requête et de post-requête
Tests basés sur les données via des fichiers de données CSV et JSON
Sortie JUnit XML et JSON pour les rapports CI

Aucun npm requis. L'Apidog CLI est distribué en tant qu'exécutable autonome. Vous le téléchargez une fois, l'ajoutez à votre PATH, et il s'exécute.

Aucune limite par exécution. Apidog ne limite pas les exécutions de collections sur aucun plan. Un pipeline qui exécute 500 collections par jour fonctionne de la même manière qu'un pipeline qui en exécute 5.

Installation

Téléchargez l'exécutable CLI pour votre plateforme depuis apidog.com/cli ou utilisez l'installeur shell :

# macOS / Linux
curl -sSf https://apidog.com/cli/install.sh | sh

# Vérifier
apidog --version

Pour les exécuteurs CI basés sur Docker, Apidog fournit une image officielle :

FROM apidog/cli:latest

Exécuter une collection Postman

Exportez votre collection depuis Postman (Fichier > Exporter > Collection v2.1) et votre environnement (Gérer les environnements > Exporter).

Ensuite, exécutez :

apidog run collection.json \
  --environment environment.json \
  --reporter-junit results.xml

Exemple GitHub Actions

name: Tests API

on: [push, pull_request]

jobs:
  api-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Installer Apidog CLI
        run: curl -sSf https://apidog.com/cli/install.sh | sh

      - name: Exécuter les tests API
        run: |
          apidog run ./tests/collection.json \
            --environment ./tests/env.json \
            --reporter-junit test-results.xml

      - name: Télécharger les résultats des tests
        uses: actions/upload-artifact@v4
        if: always()
        with:
          name: api-test-results
          path: test-results.xml

Pas de npm install, pas de package.json, pas de matrice de version Node.js. La tâche s'exécute plus rapidement et la surface de dépendance est plus petite.

Exemple GitLab CI

api-tests:
  image: apidog/cli:latest
  script:
    - apidog run ./tests/collection.json
        --environment ./tests/env.json
        --reporter-junit test-results.xml
  artifacts:
    reports:
      junit: test-results.xml

Option 2 : k6

k6 est un outil de test de charge de Grafana Labs qui gère également les tests d'API fonctionnels. Il est intéressant à connaître car il est vraiment excellent pour les tests de performance en parallèle des vérifications fonctionnelles.

Ce qu'il prend en charge

HTTP/1.1, HTTP/2, WebSocket, gRPC
Scripts de test JavaScript (ES6+)
Seuils pour les assertions de performance
Sortie vers InfluxDB, Prometheus, Datadog

Ce qu'il ne prend pas en charge

Le format natif des collections Postman. Vous pouvez convertir les collections Postman en scripts k6 à l'aide du convertisseur postman-to-k6, mais la sortie nécessite souvent un nettoyage manuel, en particulier pour les scripts complexes.
L'API pm.* de Postman nativement. La couche de conversion l'émule mais avec des lacunes.

Quand choisir k6

Si vous devez combiner les tests fonctionnels et les tests de performance dans le même pipeline – par exemple, vérifier la correction de l'API sous charge – k6 vaut le coût de la migration. Si vous souhaitez simplement remplacer Newman pour les tests fonctionnels, Apidog est plus rapide à configurer.

Utilisation de base de k6 en CI

# Installer (Linux)
sudo apt-get install k6

# Exécuter un script de test
k6 run api-tests.js

Les sorties CI de k6 indiquent le succès/l'échec en fonction des définitions de seuils dans votre script. La sortie JUnit XML est disponible via le package k6-reporter.

Option 3 : Hurl

Hurl est un outil de test HTTP open-source écrit en Rust. Il est rapide, n'a aucune dépendance d'exécution et utilise un DSL en texte clair pour définir les requêtes et les assertions.

Ce qu'il prend en charge

HTTP/1.1 et HTTP/2
Assertions JSON, XPath et regex
Variables et enchaînement de requêtes
Sortie HTML, JUnit et JSON

Ce qu'il ne prend pas en charge

Le format de collection Postman. Hurl utilise son propre format de fichier .hurl. Il n'y a pas de convertisseur automatisé.
Les scripts de test JavaScript. Les assertions sont déclaratives, pas programmatiques.

Quand choisir Hurl

Si vous êtes prêt à réécrire vos tests dans le DSL de Hurl, vous obtenez un exécutable remarquablement petit sans runtime. L'exécutable est un seul fichier de 10 Mo. Hurl est un excellent choix pour les nouveaux projets où vous n'avez pas de dette de collection Postman.

Exemple de test Hurl de base

GET https://api.example.com/users/1
HTTP 200
[Asserts]
jsonpath "$.id" == 1
jsonpath "$.email" isString

Hurl dans GitHub Actions

- name: Installer Hurl
  run: |
    curl -LO https://github.com/Orange-OpenSource/hurl/releases/latest/download/hurl-x86_64-unknown-linux-gnu.tar.gz
    tar -xf hurl-*.tar.gz
    sudo mv hurl /usr/local/bin/

- name: Exécuter les tests API
  run: hurl --test tests/*.hurl

Comparaison des trois options

Fonctionnalité	Apidog CLI	k6	Hurl
Import Postman	Natif	Convertisseur (perte de données)	Non
Dépendance npm	Non	Non	Non
Scripting JavaScript	Oui (API pm.*)	Oui (ES6)	Non (DSL uniquement)
Test de performance	Non	Oui	Non
Taille de l'exécutable	~50 Mo	~30 Mo	~10 Mo
Limites d'exécution gratuites	Aucune	Aucune	Aucune
Sortie JUnit	Oui	Via plugin	Oui

Migration depuis Newman : étapes pratiques

Si vous avez un pipeline existant basé sur Newman, voici le chemin de migration vers Apidog CLI :

Exportez vos collections. Dans Postman, cliquez avec le bouton droit sur chaque collection et exportez-la en version 2.1. Exportez vos environnements séparément.

Installez Apidog CLI. Ajoutez l'étape d'installation à votre configuration CI.

Remplacez la commande Newman. Une commande Newman typique ressemble à ceci :

newman run collection.json -e environment.json --reporters junit --reporter-junit-export results.xml

L'équivalent Apidog :

apidog run collection.json --environment environment.json --reporter-junit results.xml

La structure des drapeaux est similaire par conception.

Vérifiez la compatibilité des scripts. Exécutez votre collection localement avec Apidog CLI avant de valider la modification CI. La plupart des scripts pm.* s'exécutent sans modification. Les scripts qui utilisent pm.require pour charger des modules externes nécessitent un ajustement.

Supprimez Node.js de votre configuration CI. Si Newman était la seule raison pour laquelle Node.js apparaissait dans votre pipeline, vous pouvez supprimer entièrement l'étape de configuration Node.js et l'étape npm install.

FAQ

Newman est-il officiellement déprécié ?Non, début 2026, Newman est toujours maintenu par Postman. Mais le rythme de maintenance est lent et plusieurs problèmes ouverts affectent des cas d'utilisation réels. Il ne disparaîtra pas de sitôt, mais la construction de nouveaux pipelines sur lui comporte un risque croissant.

Apidog CLI nécessite-t-il un compte Apidog ?Pour l'exécution de collections exportées localement, non. Pour la synchronisation des collections à partir d'un espace de travail Apidog, oui. Si vous migrez depuis Postman, vous pouvez exécuter uniquement à partir de fichiers JSON exportés.

Apidog CLI peut-il exécuter des tests basés sur les données ?Oui. Passez un fichier de données CSV ou JSON avec l'option --iteration-data. Ceci est équivalent à l'option -d de Newman pour l'itération basée sur les données.

Quel est le risque de la chaîne d'approvisionnement avec les exécuteurs basés sur npm ?Tout package tiré de npm au moment de la CI est une surface d'attaque potentielle. Les packages compromis peuvent exfiltrer des variables d'environnement, ce qui, dans un contexte CI, inclut les clés API et les jetons. Un exécutable binaire téléchargé via HTTPS et épinglé à une somme de contrôle évite ce type de risque.

k6 prend-il en charge les tests gRPC ?Oui. k6 a un support gRPC natif, ce qui en fait l'un des rares outils open-source qui gère à la fois REST et gRPC dans la même suite de tests. Si votre surface d'API inclut des points de terminaison gRPC, k6 mérite d'être évalué.

Hurl prend-il en charge les en-têtes d'authentification ?Oui. Hurl prend en charge les en-têtes personnalisés, y compris Authorization, Bearer et l'authentification basée sur les cookies. Les variables vous permettent d'injecter des secrets à partir de variables d'environnement au moment de l'exécution.

L'ère de Newman en tant que choix par défaut pour les tests d'API en CI touche à sa fin. Les risques liés à la chaîne d'approvisionnement sont réels, les limites du forfait gratuit ont changé la donne pour de nombreuses équipes, et de meilleures alternatives existent désormais. La migration vers un pipeline sans Newman est simple, surtout si vous passez à Apidog CLI avec vos collections Postman existantes.