Apidog CLI vs Postman CLI: El Mejor Ejecutor de Pruebas CI

Sus pruebas de API pasan cuando hace clic en Ejecutar en su portátil. Eso no prueba nada. La prueba que importa es la que se ejecuta en cada solicitud de extracción, cada fusión y cada compilación nocturna, sin que haya ningún humano presente para hacer clic en nada. La tarea de integrar sus pruebas en ese ciclo pertenece a un ejecutor de línea de comandos. Toma las pruebas que ya escribió, las ejecuta sin interfaz gráfica dentro de su canalización, sale con un código de estado que su CI puede leer y escribe un informe que aparece en el panel de control de la compilación.

Dos ejecutores surgen una y otra vez cuando los equipos configuran esto: el CLI de Postman y el CLI de Apidog. Ambos apuntan al mismo objetivo desde diferentes puntos de partida. El CLI de Postman ejecuta las colecciones que usted crea en Postman. El CLI de Apidog ejecuta los escenarios de prueba visuales que usted crea en Apidog. Ambos se instalan en un solo paso, ambos se integran con GitHub Actions, GitLab CI y Jenkins, y ambos ponen la compilación en rojo cuando una prueba falla. Las diferencias reales se encuentran antes del comando de ejecución: cómo se crean las pruebas, cómo se autentica en CI y dónde reside realmente la definición de la prueba.

En resumen

• CLI de Postman (binario postman) ejecuta las colecciones almacenadas en su espacio de trabajo de Postman. Se basa en Newman, está firmado y respaldado por Postman, y se autentica con una clave API de Postman. Cuando ha iniciado sesión, envía los resultados de la ejecución de vuelta a la nube de Postman automáticamente.
• CLI de Apidog (apidog-cli, binario apidog) ejecuta los escenarios de prueba que diseña visualmente en Apidog. Lo apunta a un escenario por ID con un token de acceso, y ejecuta ese escenario sin interfaz gráfica ni GUI.
• Ambos emiten informes JUnit, JSON, HTML y de terminal. Ambos fallan la compilación si una prueba falla. El XML de JUnit es lo que se conecta a un panel de CI en cualquier caso.
• Elija el CLI de Postman cuando sus pruebas ya residen en colecciones de Postman y su equipo está comprometido con la nube de Postman para informes e historial.
• Elija el CLI de Apidog cuando desee la creación visual de escenarios, el encadenamiento de solicitudes, la gestión de entornos y las ejecuciones basadas en datos desde una única fuente de verdad, con control total sobre si los informes permanecen locales o van a la nube.

El problema real: pruebas que existen pero nunca se ejecutan

Una prueba que se ejecuta manualmente es una prueba que se echa a perder. Alguien la escribió, pasó una vez y luego permaneció intocada mientras la API cambiaba. Tres meses después, la prueba es incorrecta y nadie se dio cuenta, porque nadie la ejecutó. La solución no es escribir más pruebas. Es hacer que las pruebas que tiene se ejecuten automáticamente con cada cambio, con una señal de aprobado o reprobado sobre la que la canalización pueda actuar.

Un ejecutor CLI es la herramienta que cierra esa brecha. Para ganarse un lugar en CI, tiene que hacer tres cosas. Tiene que ejecutarse sin interfaz gráfica, porque su ejecutor de CI no tiene pantalla. Tiene que salir con un código de error distinto de cero cuando algo falla, para que la compilación se ponga en rojo y se bloquee una fusión rota. Y tiene que escribir un informe legible por máquina, para que el revisor vea qué falló sin tener que volver a ejecutar nada localmente. Tanto el CLI de Postman como el CLI de Apidog cumplen limpiamente con esos requisitos. Donde se separan es en todo lo que sucede antes de run: cómo se escribió la prueba y dónde reside cuando CI la busca.

Si está configurando pruebas automatizadas desde cero, los patrones más amplios en la automatización de pruebas de API en CI/CD merecen ser leídos junto con este artículo. Aquí, el enfoque se mantiene en los dos ejecutores.

Lo que el CLI de Postman hace bien

Primero, un punto de claridad que confunde a mucha gente: el CLI de Postman no es Newman. Newman es el ejecutor más antiguo, de código abierto y basado en npm que la comunidad ha utilizado durante años. El CLI de Postman es una herramienta más nueva, construida sobre la base de Newman, pero firmada y oficialmente respaldada por la empresa Postman. Si ha estado ejecutando Newman, los dos no son intercambiables, y la diferencia importa en CI. Hemos detallado esa distinción exacta en Postman CLI vs Newman si está decidiendo entre las dos opciones del lado de Postman.

La mayor fortaleza del CLI de Postman es que permanece dentro del mundo que su equipo ya conoce. Si sus colecciones, entornos y variables compartidas ya residen en un espacio de trabajo de Postman, el CLI las ejecuta con casi ninguna traducción. No necesita reconstruir nada. Se autentica, nombra la colección y ejecuta las solicitudes y pruebas exactamente como lo haría la aplicación.

Instalarlo es un solo comando. En macOS y Linux, ejecuta el script de instalación oficial:

curl -o- "https://dl-cli.pstmn.io/install/unix.sh" | sh

En Windows, utiliza el instalador de PowerShell firmado, y también hay un paquete npm si prefiere fijarlo como una dependencia de desarrollo:

npm install -g postman-cli

El binario es postman. En CI, se autentica con una clave API de Postman, que es el método que Postman recomienda para las canalizaciones:

postman login --with-api-key $POSTMAN_API_KEY

Luego, ejecuta una colección por su ID, o por una ruta de archivo local si la ha exportado:

postman collection run $POSTMAN_COLLECTION_ID -e $POSTMAN_ENV_ID

La parte que le otorga mucha lealtad al CLI de Postman es lo que sucede después de la ejecución. Cuando ha iniciado sesión, envía los resultados de la ejecución directamente a la nube de Postman, donde aparecen en su espacio de trabajo junto con la colección. El historial de pruebas, las comparaciones de ejecución y el panel visible para el equipo están todos allí sin ninguna configuración adicional. Para un equipo que ya vive en Postman, ese viaje de ida y vuelta es realmente útil y es una razón justa para quedarse.

Lo que el CLI de Apidog hace bien

Apidog toma una ruta diferente hacia la misma canalización. Usted construye pruebas visualmente dentro de la aplicación Apidog: encadena varias solicitudes en un único escenario de prueba, añade aserciones en cada respuesta, extrae un valor de una respuesta y lo alimenta a la siguiente solicitud, y repite todo el escenario sobre un archivo de datos. El CLI es el ejecutor sin interfaz gráfica para esos escenarios. No tiene un formato de prueba propio. Accede a su proyecto de Apidog, encuentra el escenario que usted nombra por ID y lo ejecuta exactamente como lo haría la aplicación, luego informa los resultados.

La ventaja es que nadie mantiene dos copias de la misma prueba. El escenario que construyó en el editor visual es la prueba que se ejecuta en CI. No hay ningún paso en el que tenga que volver a expresar una prueba que funciona como un script y luego depurar el script. El ciclo de creación rápido y el ciclo de automatización comparten una única fuente de verdad. Para flujos de varios pasos, como iniciar sesión, luego crear, luego leer, luego eliminar, ese encadenamiento visual ahorra mucho del código de pegamento que de otro modo escribiría a mano. La mecánica de construir esos flujos se cubre en la guía de escenarios de prueba para la automatización de pruebas de API.

La instalación es un comando npm:

npm install -g apidog-cli

El binario es apidog. Una ejecución típica nombra un escenario por ID, elige un entorno, establece un número de iteraciones y se autentica con un token de acceso:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 -n 1 -r html,junit

No escribe esos IDs manualmente. Abra el escenario de prueba en Apidog, cambie a su pestaña CI/CD, haga clic para generar un token de acceso, y Apidog construirá el comando completo para usted con el ID del escenario y el ID del entorno ya completados. Lo copia una vez, mueve el token a un secreto de CI y lo referencia como $APIDOG_ACCESS_TOKEN en su flujo de trabajo.

El modelo de token e ID es la separación más clara del CLI de Postman. Apidog ejecuta pruebas almacenadas en un proyecto que el CLI obtiene a través de la red, autenticado por el token. Tampoco hay una opción de suscripción a la nube separada para los informes: usted elige --out-dir para los artefactos locales y añade --upload-report solo cuando desea que se suba un resumen a la nube de Apidog. Los informes permanecen donde usted los coloca.

Comparación

Dos cosas destacan de esa tabla. Primero, ambos ejecutores cubren los elementos esenciales de CI de manera casi idéntica: selección de entorno, iteración basada en datos, los cuatro formatos de informe importantes y una salida no nula en caso de fallo. Si todo lo que necesita es un ejecutor que se ponga en rojo en una fusión incorrecta, cualquiera de los dos cumple la función. Segundo, la verdadera división radica en dónde reside la prueba y cómo la escribió. El CLI de Postman ejecuta una colección que reside en su espacio de trabajo de Postman. El CLI de Apidog ejecuta un escenario visual que reside en su proyecto de Apidog.

Informadores y códigos de salida: las partes que CI realmente lee

Un ejecutor demuestra su valor en una canalización a través de dos comportamientos: el informe que escribe y el código de salida que devuelve. Si se hacen bien esas dos cosas, todo lo demás es cableado.

El CLI de Postman toma una lista de reportadores separados por comas, y cuando ha iniciado sesión, también envía los resultados a la nube de Postman:

postman collection run $POSTMAN_COLLECTION_ID \
  -e $POSTMAN_ENV_ID \
  --reporters cli,junit \
  --bail

El reportador junit es el que su panel de control de CI analiza en un árbol de aprobado o reprobado. La bandera --bail detiene la ejecución en la primera solicitud, prueba o aserción fallida, lo que mantiene una retroalimentación rápida en una prueba de humo. Elimine --bail y ejecutará todo, luego informará todos los fallos juntos. El CLI sale con un código distinto de cero en cualquier fallo, por lo que la compilación se pone en rojo por sí sola.

El CLI de Apidog utiliza la misma idea del reportador -r y escribe todo en un único directorio de salida:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 \
  -r html,junit --out-dir ./apidog-reports

Su bandera --on-error configura el comportamiento a mitad de escenario: end se detiene en el primer fallo y es el valor predeterminado, continue ejecuta cada paso para que recopile todos los fallos en un informe, e ignore pasa por alto un paso conocido como inestable sin descarrilar la ejecución. De cualquier manera, el proceso termina con un código no nulo si algo falló, y el XML de JUnit aterriza en ./apidog-reports listo para que su panel de control lo recoja.

El resultado práctico: ambos escriben XML de JUnit, ambos fallan la compilación correctamente y ambos archivan un informe HTML que puede abrir más tarde. La diferencia en la generación de informes es el viaje de ida y vuelta a la nube. Postman envía los resultados a su nube por defecto cuando está autenticado. Apidog mantiene los informes locales a menos que se le pida que los suba. Ninguno es mejor en abstracto; uno se adapta a equipos que quieren un historial alojado sin pensar en ello, el otro se adapta a equipos que quieren decidir exactamente qué sale del ejecutor.

Integrando cada uno en GitHub Actions

La estructura de un trabajo de GitHub Actions es la misma para ambos: extraer el repositorio, configurar Node, instalar el CLI, ejecutar las pruebas, y el código de salida fallido bloquea la fusión. Almacene el secreto en la configuración de su repositorio, nunca en el archivo de flujo de trabajo.

Aquí está la versión del CLI de Postman:

- name: Run API tests (Postman CLI)
  run: |
    curl -o- "https://dl-cli.pstmn.io/install/unix.sh" | sh
    postman login --with-api-key ${{ secrets.POSTMAN_API_KEY }}
    postman collection run $POSTMAN_COLLECTION_ID -e $POSTMAN_ENV_ID --reporters cli,junit --bail

Y la versión del CLI de Apidog:

- name: Run API tests (Apidog CLI)
  run: |
    npm install -g apidog-cli
    apidog run --access-token ${{ secrets.APIDOG_ACCESS_TOKEN }} -t 605067 -e 1629989 -r cli,junit

Ambos son cortos, ambos son legibles y ambos se comportan de la misma manera a nivel de su canalización: una ejecución exitosa sale con cero y la fusión procede, una ejecución fallida sale con un código distinto de cero y la fusión se bloquea. Si desea un recorrido más profundo sobre la ejecución de pruebas de API en un flujo de trabajo de GitHub, la automatización de pruebas de API con GitHub Actions lo explica paso a paso. Para los usuarios de Jenkins, la misma idea se presenta en la integración de pruebas automatizadas de Apidog con Jenkins.

Entonces, ¿cuál gana en CI?

No hay un único ganador, porque la respuesta correcta depende de dónde residen sus pruebas y cómo su equipo desea crearlas y almacenarlas.

El CLI de Apidog gana cuando valora más la creación visual y una única fuente de verdad que un historial de la nube alojado. Usted construye un escenario una vez en el editor visual, con encadenamiento de solicitudes y aserciones gestionadas por usted, y el mismo escenario se ejecuta en CI por referencia. Usted decide si los informes permanecen locales o se cargan. Y debido a que Apidog cubre el diseño, la simulación y la documentación en el mismo espacio de trabajo, el escenario de prueba se sitúa junto al contrato API que verifica, lo que evita que las pruebas y la especificación se separen. Los equipos que evalúan las plataformas de manera más amplia pueden leer la comparación completa de Apidog vs Postman.

El CLI de Postman gana cuando su equipo ya está dentro de Postman. Sus colecciones están allí, sus entornos están allí y desea un historial de ejecución en la nube de Postman sin tener que configurar nada. El viaje de ida y vuelta a la nube en cada ejecución es una verdadera comodidad para esa configuración, y la herramienta está oficialmente firmada y respaldada. Si eso describe a su equipo, cambiar de ejecutores le aporta poco.

Si ya se siente limitado por el modelo de nube de Postman, o simplemente quiere crear pruebas una vez y ejecutarlas en todas partes, el camino es claro. Descargue Apidog, construya un escenario, abra su pestaña CI/CD y copie el comando apidog run generado en su canalización. Esa es toda la configuración.

Preguntas frecuentes

¿Es el CLI de Postman lo mismo que Newman? No. Newman es el ejecutor npm de código abierto más antiguo. El CLI de Postman es una herramienta más nueva construida sobre la base de Newman, firmada y respaldada por Postman, con informes integrados a la nube de Postman. Si está eligiendo entre los dos en el lado de Postman, Postman CLI vs Newman desglosa las diferencias.

¿Necesito una cuenta o un token para cualquiera de los CLI en CI? Sí para ambos, pero la forma difiere. El CLI de Postman se autentica con una clave API de Postman a través de postman login --with-api-key. El CLI de Apidog se autentica con un token de acceso pasado como --access-token. Almacene cualquiera de ellos como un secreto de CI, nunca en el archivo de flujo de trabajo.

¿Ambos ejecutores fallan la compilación cuando una prueba falla? Sí. Ambos salen con un código de estado distinto de cero en cualquier prueba o aserción fallida, que es lo que le indica a su sistema de CI que marque la compilación en rojo y bloquee la fusión. El CLI de Postman utiliza --bail para detenerse en el primer fallo; el CLI de Apidog utiliza --on-error end, que es su valor predeterminado.

¿Puedo mantener mis informes locales en lugar de enviarlos a una nube? El CLI de Apidog mantiene los informes locales por defecto y los escribe en --out-dir; solo los sube con --upload-report. El CLI de Postman también escribe informes locales, pero cuando ha iniciado sesión, también envía automáticamente los resultados de la ejecución a la nube de Postman.

¿Cómo obtengo el comando de ejecución exacto de Apidog para mi escenario? Abra el escenario de prueba en Apidog, cambie a su pestaña CI/CD, genere un token de acceso, y Apidog construirá el comando apidog run completo con el ID del escenario y el ID del entorno ya completados. Cópielo, mueva el token a un secreto de CI y habrá terminado. Para cada bandera disponible, ejecute apidog run --help.

¿Cuál debería elegir un equipo que migra de la nube de Postman? Si la razón por la que se va es el modelo centrado en la nube o los precios, el CLI de Apidog encaja, porque ejecuta un único escenario visual desde su proyecto y le permite decidir qué sale del ejecutor. Empiece con la comparación Apidog vs Postman para ver cómo se alinean las plataformas más allá del ejecutor.