Diferencia entre Newman y Postman: Comparativa Completa

Newman y Postman no son competidores. Son dos mitades de un mismo flujo de trabajo. Postman es la aplicación de escritorio donde se diseñan solicitudes, se escriben pruebas y se exploran API manualmente. Newman es la herramienta de línea de comandos que toma las colecciones creadas en Postman y las ejecuta sin la interfaz gráfica de usuario. Si Postman es el taller, Newman es la máquina que ejecuta su trabajo terminado según un cronograma.

La confusión suele surgir de la pregunta "¿cuál debería usar?". La respuesta honesta es "ambos", en diferentes etapas. Se autoriza en Postman porque una interfaz gráfica lo hace rápido. Se ejecuta en Newman porque una canalización no puede hacer clic en botones. Este artículo explica la relación con precisión, muestra dónde encaja cada uno y guía para integrar Newman en una canalización de CI/CD.

Qué es Postman

Postman es una plataforma gráfica de API. Se instala como una aplicación de escritorio, se crean solicitudes, se organizan en colecciones y carpetas, y se adjuntan entornos que contienen variables como URL base y tokens. Después de cada respuesta, Postman ejecuta scripts de prueba de JavaScript que se escriben en la pestaña "Tests" de la solicitud.

Un script de prueba de Postman verifica la respuesta:

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á diseñado para el trabajo interactivo. Un desarrollador que depura un nuevo endpoint envía solicitudes, inspecciona respuestas, ajusta encabezados e itera en segundos. Un ingeniero de QA convierte esas solicitudes en un conjunto de regresión guardado. Los equipos comparten espacios de trabajo para que todos trabajen con la misma colección. Todo eso se beneficia de una interfaz visual. Nuestra guía sobre cómo probar API con Postman cubre ese flujo de trabajo en profundidad.

Para lo que Postman no está diseñado es para la ejecución desatendida. Ejecutar un conjunto significa abrir la aplicación y hacer clic en "Collection Runner". Eso está bien para una persona en un escritorio. Es inútil para un servidor de compilación.

Qué es Newman

Newman es el ejecutor de colecciones oficial de línea de comandos de Postman. Es un paquete npm de código abierto, de uso gratuito, que ejecuta exactamente los mismos archivos de colección que produce Postman. Se exporta una colección como un archivo JSON, se le entrega a Newman, y Newman ejecuta cada solicitud y cada script de prueba, y luego informa los resultados en su terminal.

Instálelo con npm:

npm install -g newman

Ejecute una colección:

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

Newman ejecuta cada solicitud, ejecuta las mismas aserciones pm.test que lo haría Postman, e imprime un resumen. El detalle clave es que Newman utiliza el mismo motor de ejecución que Postman, por lo que una colección que pasa en la GUI se comporta de forma idéntica en la línea de comandos. No hay reescritura ni lenguaje de prueba separado.

Newman también sale con un código de estado distinto de cero cuando falla alguna prueba. Ese comportamiento es lo que lo hace valioso para la automatización: un sistema de compilación lee ese código de salida y falla la compilación ante una aserción rota. Una ejecución exitosa sale con cero y la canalización continúa.

Comparación lado a lado

El archivo JSON de la colección es el puente entre ellos. Se construye una vez en Postman, y Newman lo ejecuta siempre en la automatización.

Cómo encaja Newman en CI/CD

Newman existe principalmente para integrar las pruebas de API en la integración continua. El patrón es consistente entre proveedores. Se suben la colección exportada y los archivos de entorno al repositorio, se instala Newman en la canalización, se ejecuta y se deja que el código de salida controle la compilación.

Aquí está el flujo de trabajo en pasos numerados:

1. Exportar desde Postman. En Postman, exporte su colección y su entorno como archivos JSON.
2. Subirlos al repositorio. Guárdelos junto a su código para que tengan control de versiones con la API.
3. Instalar Newman en la canalización. Añada npm install -g newman al trabajo de CI, o use la imagen Docker postman/newman.
4. Ejecutar la colección. Llame a newman run con los archivos de colección y entorno.
5. Controlar por el código de salida. Si alguna prueba falla, Newman sale con un código distinto de cero y el proveedor de CI marca la compilación como fallida.

Un paso de GitHub Actions se ve así:

- 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

La bandera --reporters vale la pena conocerla. Newman viene con reporteros incorporados para CLI y JUnit XML, y los reporteros de la comunidad añaden salida HTML y más. JUnit XML, en particular, permite que los paneles de CI muestren los resultados de las pruebas de forma nativa. Para una guía completa, consulte nuestra guía sobre cómo automatizar pruebas de API en CI/CD y los detalles de la automatización de pruebas de API con GitHub Actions.

Opciones útiles de línea de comandos de Newman

Newman tiene un conjunto de banderas que manejan los aspectos difíciles de las ejecuciones automatizadas. Conocer algunas de ellas marca la diferencia entre un trabajo frágil y uno confiable.

La bandera --iteration-data apunta a Newman a un archivo CSV o JSON y ejecuta toda la colección una vez por fila, sustituyendo los valores de la fila como variables. Así es como se impulsa una ejecución de Newman con datos: una colección, muchas entradas. La bandera --iteration-count simplemente repite la colección un número fijo de veces.

La bandera --bail le indica a Newman que se detenga en el primer fallo en lugar de ejecutar el resto de la colección. En una canalización de retroalimentación rápida, esto suele ser lo que se desea, ya que una única solicitud rota suele significar que la compilación ya va a fallar. La bandera --timeout-request limita el tiempo que puede tardar cualquier solicitud individual, lo que protege el trabajo de quedarse colgado en un servicio que no responde.

La bandera --delay-request inserta una pausa entre solicitudes, útil cuando una API impone límites de tasa. Y --folder permite ejecutar solo una carpeta nombrada dentro de una colección, de modo que un trabajo de prueba de humo puede ejecutar un subconjunto pequeño mientras el trabajo de regresión completo lo ejecuta todo. Ninguna de estas opciones existe en el "Collection Runner" de la GUI de Postman de la misma forma programable, y juntas son la razón por la que Newman es la opción práctica para la ejecución desatendida.

Errores comunes al pasar de Postman a Newman

Cuando los equipos llevan una colección de la GUI a Newman por primera vez, surgen una y otra vez algunos problemas. El más común son los valores codificados. Una solicitud que funcionó en Postman porque una variable estaba configurada en el entorno activo fallará en Newman si ese archivo de entorno no se pasa con --environment. Siempre exporte y proporcione el entorno explícitamente.

El segundo es depender de la nube de Postman. Las colecciones que hacen referencia a variables sincronizadas en la nube o que usan funciones vinculadas a una sesión de Postman iniciada pueden no comportarse de la misma manera cuando se ejecutan desde un archivo JSON simple. Pruebe el archivo exportado localmente con Newman antes de confiar en él en CI.

El tercero es olvidar que los archivos exportados se vuelven obsoletos. El JSON de la colección en su repositorio es una instantánea. Si alguien edita la colección en Postman y no la vuelve a exportar, la canalización sigue ejecutando la versión antigua. Los equipos resuelven esto con disciplina, tratando la exportación como una confirmación deliberada, o pasando a una herramienta donde la definición de la prueba y el ejecutor son la misma cosa.

Cuándo usar cada uno

Use Postman cuando un humano esté haciendo el trabajo. Diseñar una nueva API, depurar una llamada fallida, explorar un servicio de terceros, construir y refinar un conjunto de pruebas: todo esto es interactivo y pertenece a la GUI.

Use Newman cuando no haya ningún humano presente. Ejecutar el conjunto en cada solicitud de extracción, en un horario nocturno o como prueba de humo posterior a la implementación: todo esto necesita una herramienta que se ejecute desde un script e informe a través de un código de salida.

En la práctica, la frontera es "autoría versus ejecución". No elegirá uno sobre el otro. Usará Postman para crear y Newman para automatizar, y el archivo de la colección llevará su trabajo entre ellos. Si prefiere no mantener un ejecutor separado en absoluto, nuestra guía sobre cómo ejecutar colecciones de Postman en CI sin Newman cubre otras opciones.

Una alternativa unificada: Apidog

Mantener una configuración de Postman-más-Newman significa exportar colecciones, mantener los archivos JSON sincronizados y gestionar un ejecutor separado. Apidog colapsa eso en una sola plataforma. Diseña API, depura solicitudes y construye escenarios de prueba automatizados con aserciones visuales en la misma aplicación, luego ejecuta esos escenarios en CI/CD con el ejecutor de línea de comandos incorporado. No hay un paso de exportación y sincronización porque las definiciones de las pruebas y el motor de ejecución viven juntos.

Apidog también cubre el diseño de API, servidores simulados y pruebas de rendimiento en el mismo espacio de trabajo, por lo que las pruebas funcionales que usted crea son las mismas que ejecuta su canalización. Puede descargar Apidog y usar sus funciones de prueba de forma gratuita. Para una comparación de herramientas en este espacio, consulte nuestra lista de las mejores alternativas a Postman para pruebas de API.

Preguntas frecuentes

¿Es Newman un reemplazo para Postman?

No. Newman no puede crear ni editar colecciones; solo las ejecuta. Todavía necesita Postman, u otra herramienta, para crear la colección y escribir los scripts de prueba. El trabajo de Newman es ejecutar ese trabajo terminado de forma desatendida. Son complementarios, no intercambiables.

¿Cuesta dinero Newman?

No. Newman es de código abierto y completamente gratuito. Se distribuye como un paquete npm. Postman tiene un nivel gratuito más planes de pago para equipos más grandes, pero Newman en sí mismo no tiene costo, independientemente de cómo lo uses.

¿Mis pruebas de Postman se comportarán igual en Newman?

Sí. Newman utiliza el mismo motor de ejecución que Postman, por lo que las aserciones pm.test y la lógica de la solicitud se ejecutan de forma idéntica. Una colección que pasa en el Collection Runner de Postman producirá los mismos resultados en Newman, lo que lo hace seguro para CI.

¿Cómo informa Newman sobre los fallos de las pruebas?

Newman imprime un resumen en la terminal y sale con un código de estado distinto de cero cuando falla alguna prueba. Ese código de salida es cómo los sistemas de CI detectan el fallo. Newman también admite reporteros, incluidos JUnit XML y HTML, para que los resultados puedan alimentar paneles de control e informes de compilación.

¿Puedo ejecutar Newman sin instalar Node.js?

Newman es un paquete npm, por lo que una instalación directa necesita Node.js. Para evitar eso, use la imagen oficial de Docker postman/newman, que incluye todo. El enfoque de Docker es común en entornos de CI donde no desea administrar un entorno de ejecución de Node.js en el trabajo de compilación.