Bruno CLI vs Apidog CLI: Automatizar Pruebas API en CI

Tus pruebas de API pasan en tu portátil. La verdadera pregunta es si se ejecutan en cada pull request, cada fusión, cada compilación nocturna, sin que un humano haga clic en nada. Esa tarea le corresponde a un ejecutor de línea de comandos. Toma las pruebas que ya has creado y las ejecuta sin interfaz gráfica dentro de tu pipeline, sale con un código de estado limpio y escribe un informe que tu panel de CI puede leer.

Constantemente surgen dos ejecutores cuando los equipos configuran esto: el CLI de Bruno y el CLI de Apidog. Resuelven el mismo problema desde diferentes puntos de partida. Bruno es un cliente de API nativo de Git, con prioridad sin conexión, de código abierto, y su CLI ejecuta los archivos .bru que residen en tu repositorio. Apidog es una plataforma de API todo en uno, y su CLI ejecuta los escenarios de prueba visuales que construyes en la aplicación. Ambos se integran en GitHub Actions, GitLab CI, Jenkins y cualquier otra cosa con Node.js. Ambos fallan la compilación cuando una prueba falla. Las diferencias aparecen en cómo creas las pruebas, cómo te autenticas y cómo viaja la definición de la prueba a la CI.

Esta es una comparación honesta, a nivel de comando, de los dos. Sin argumentos falaces. Bruno hace varias cosas genuinamente bien, y verás exactamente dónde encaja cada ejecutor antes de conectar uno a tu pipeline.

En resumen

• CLI de Bruno (@usebruno/cli, binario bru) ejecuta archivos .bru directamente desde una carpeta en tu repositorio de Git. Es de código abierto, funciona sin conexión y no necesita cuenta ni token. Lo apuntas a un directorio y ejecuta cada solicitud y aserción que encuentra.
• CLI de Apidog (apidog-cli, binario apidog) ejecuta los escenarios de prueba que diseñas en la aplicación Apidog, obtenidos por ID usando un token de acceso. No reescribes las pruebas como código; el escenario visual es la prueba, y el CLI lo ejecuta sin interfaz gráfica.
• Ambos emiten informes JUnit, JSON y HTML, y ambos fallan la compilación ante una prueba fallida. El XML de JUnit es lo que se conecta a los paneles de CI en cualquier caso.
• Elige Bruno cuando quieras todo en el repositorio, cero cuentas y control total sin conexión de archivos de prueba de texto plano.
• Elige Apidog cuando quieras creación visual, encadenamiento de escenarios, gestión de entornos y ejecuciones impulsadas por datos sin mantener el código de prueba manualmente.

El problema real: pruebas que existen pero nunca se ejecutan

Una prueba que ejecutas manualmente es una prueba que se pudre. Alguien la construyó, pasó una vez, y luego permaneció intocada mientras la API cambiaba por debajo. La solución no es más pruebas. Son pruebas que se ejecutan automáticamente en cada cambio, con una señal de aprobado/fallido sobre la que el pipeline puede actuar.

Un ejecutor de CLI es lo que cierra esa brecha. Necesita tres cosas para ser útil en la CI: tiene que ejecutarse sin una GUI, tiene que salir con un código distinto de cero cuando algo falla para que la compilación se ponga en rojo, y tiene que escribir un informe legible por máquina para que los revisores vean qué falló. Bruno y Apidog cumplen ambos requisitos. Donde difieren es antes del comando de ejecución, en cómo se escribió la prueba y dónde reside.

Si estás configurando la CI desde cero, vale la pena leer los patrones más amplios en la automatización de pruebas de API en CI/CD junto con esta comparación. Aquí nos centramos en los dos ejecutores en sí.

Qué hace bien el CLI de Bruno

Todo el diseño de Bruno es nativo de Git. Cada solicitud, entorno y aserción es un archivo .bru de texto plano en disco, dentro de tu repositorio, versionado como cualquier otro archivo fuente. Ese modelo tiene ventajas reales, y vale la pena exponerlas claramente antes de cualquier comparación.

Tus pruebas viven con tu código. Un pull request que cambia un endpoint puede cambiar la prueba para ese endpoint en el mismo diff, revisado por la misma persona. No hay un sistema separado para sincronizar, ni una copia en la nube que pueda desviarse de lo que hay en el repositorio. Los diffs son legibles porque el formato es texto. Puedes buscar en tus pruebas (grep), refactorizarlas con las mismas herramientas que usas para el código y resolver conflictos de fusión en un editor.

También es de código abierto y funciona sin conexión. El CLI se ejecuta completamente en tu máquina o en tu ejecutor de CI sin cuenta, sin inicio de sesión y sin token. Para equipos con reglas estrictas de manejo de datos o entornos aislados (air-gapped), eso es importante. El nivel de pago de Bruno, Bruno Ultimate, añade funciones de equipo que incluyen SSO y SCIM, integraciones con administradores de secretos y capacidades de auditoría, por lo que el proyecto no es solo una herramienta para aficionados. Pero el cliente principal y el CLI son gratuitos y autónomos, y esa es una fortaleza legítima.

npm install -g @usebruno/cli

El binario es bru. Ejecutas una colección apuntándolo a la carpeta que contiene tus archivos .bru:

bru run --env staging

Ejecútalo desde dentro del directorio de la colección y bru run ejecuta las solicitudes que encuentra allí. Añade -r para buscar recursivamente en subcarpetas y así recoger solicitudes anidadas:

bru run -r --env staging

Ese es el bucle principal. Sin IDs, sin token, sin obtención remota. Los archivos en la carpeta son las pruebas, y el CLI los ejecuta.

Hemos cubierto la historia más amplia de Bruno en qué hace diferente a Bruno como cliente de API nativo de Git y dónde aparecen sus limitaciones para equipos más grandes. Específicamente para CI, las fortalezas mencionadas son las que importan.

Qué hace bien el CLI de Apidog

Apidog toma un camino diferente hacia el mismo pipeline. Construyes pruebas visualmente en la aplicación Apidog: encadenas solicitudes en un escenario, añades aserciones, extraes un valor de una respuesta para la siguiente solicitud y repites todo el proceso con un archivo de datos. El CLI es el ejecutor sin interfaz gráfica para esos escenarios. No tiene su propio formato de archivo. Obtiene el escenario que nombras por ID de tu proyecto Apidog y lo ejecuta exactamente como lo haría la aplicación.

La ventaja es que nadie mantiene dos representaciones de la misma prueba. El escenario en el proyecto es la prueba. Lo creas en un constructor visual que maneja el encadenamiento de solicitudes, la extracción de variables y las aserciones sin que tengas que escribir y depurar archivos de script. Luego, el CLI ejecuta ese mismo escenario en la CI. El bucle de creación rápida y el bucle de automatización utilizan una única fuente de verdad.

npm install -g apidog-cli

El binario es apidog. Una ejecución típica nombra un escenario por ID, elige un entorno 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 escribes esos IDs a mano. Abre el escenario de prueba, ve a su pestaña CI/CD, genera un token de acceso y Apidog construye el comando completo para ti con el ID del escenario y el ID del entorno ya completados. Lo copias una vez, luego mueves el token a un secreto de CI y lo referencias como $APIDOG_ACCESS_TOKEN. La referencia completa de flags se encuentra en la guía completa del CLI de Apidog si quieres todas las opciones en un solo lugar.

El modelo basado en tokens es la diferencia más clara con Bruno. Apidog ejecuta pruebas almacenadas en un proyecto al que el CLI accede a través de la red, autenticado. Bruno ejecuta pruebas almacenadas como archivos que el CLI lee del disco. Ninguno de los dos es incorrecto; se adaptan a diferentes configuraciones de equipo.

Comparativa

Dos cosas destacan. Primero, ambos ejecutores cubren los mismos aspectos esenciales de CI: selección de entorno, iteración dirigida por datos, los tres formatos de informe importantes y una salida no nula en caso de fallo. Segundo, la diferencia radica en dónde reside la prueba y cómo la escribiste, no en la capacidad bruta. Bruno guarda la prueba en el repositorio como texto. Apidog la guarda en el proyecto como un escenario visual y la ejecuta por referencia.

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

Un ejecutor se gana su lugar en un pipeline a través de dos comportamientos: el informe que escribe y el código de salida que devuelve. Si estos son correctos, el resto es solo conexión.

Bruno escribe informes con flags por formato. Pasas una ruta para cada formato que desees:

bru run -r --env staging \
  --reporter-junit ./results/junit.xml \
  --reporter-html ./results/report.html \
  --reporter-json ./results/report.json

El XML de JUnit es lo que tu panel de CI analiza en un árbol de aprobado/fallido. El informe HTML es un artefacto navegable. El --bail de Bruno detiene la ejecución después de la primera solicitud, prueba o aserción fallida, lo que mantiene una retroalimentación rápida en una prueba de humo. Sin --bail, ejecuta todo y reporta todos los fallos a la vez.

Apidog usa un único flag -r con una lista separada por comas, y escribe todo en un solo directorio de salida:

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

Su flag --on-error define el comportamiento a mitad del escenario: end detiene la ejecución en el primer fallo (el valor predeterminado), continue ejecuta todos los pasos para que recolectes todos los fallos en un solo informe, e ignore salta un paso conocido como inestable. De cualquier manera, la ejecución termina con un código distinto de cero si algo falla.

El contrato del código de salida es el mismo en ambos lados y es la parte fundamental. Cuando una aserción falla, el ejecutor sale con un código distinto de cero. La CI lee ese código, marca el paso como fallido, falla el trabajo y bloquea la fusión o el despliegue. No configuras nada extra. La única trampa, idéntica para ambos, es tragar el código de salida: si envuelves la ejecución en un pipeline de shell o añades || true, la salida no cero se ignora y la puerta deja de funcionar silenciosamente. No hagas eso.

CLI de Bruno en GitHub Actions

Como los archivos .bru ya están en el repositorio, el flujo de trabajo es corto. Realiza un checkout del código, instala el CLI, ejecuta la colección, sube el informe.

name: API tests

on:
  pull_request:
    branches: [main]

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

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install Bruno CLI
        run: npm install -g @usebruno/cli

      - name: Run API tests
        working-directory: ./api-tests
        run: bru run -r --env staging --reporter-junit ./results/junit.xml

      - name: Upload report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: bruno-report
          path: ./api-tests/results

El working-directory apunta a la carpeta que contiene tu colección. if: always() mantiene la carga del informe en ejecución incluso cuando las pruebas fallan, que es exactamente cuando quieres leerlo. No se necesita ningún secreto porque nada se autentica en un servicio remoto.

CLI de Apidog en GitHub Actions

El flujo de trabajo de Apidog es estructuralmente el mismo, con una adición: el token de acceso proviene de los secretos del repositorio, y seleccionas el escenario por ID en lugar de por ruta de carpeta.

name: API tests

on:
  pull_request:
    branches: [main]

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

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install Apidog CLI
        run: npm install -g apidog-cli

      - name: Run API test scenario
        run: |
          apidog run \
            --access-token "$APIDOG_ACCESS_TOKEN" \
            -t 605067 \
            -e 1629989 \
            -r html,junit \
            --out-dir ./apidog-reports
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}

      - name: Upload report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: apidog-report
          path: ./apidog-reports

Observa la simetría. Mismo checkout, misma configuración de Node, misma forma de instalar-y-ejecutar, mismo 'siempre subir'. Las únicas diferencias reales son el token configurado como secreto y el escenario seleccionado por ID. Si quieres esto expandido con variantes para GitLab CI y Jenkins también, la guía completa del CLI de Apidog mantiene el mismo patrón en todos los ejecutores.

Cómo elegir

La decisión rara vez se reduce a qué ejecutor es "mejor". Se reduce a cómo tu equipo quiere crear y almacenar las pruebas.

Elige Bruno cuando el repositorio sea la fuente de la verdad. Si quieres cada prueba como un archivo de texto plano que reside junto al código que cubre, revisado en el mismo pull request, sin cuenta y sin llamadas de red en tiempo de ejecución, Bruno se ajusta exactamente a ese modelo. Es la elección natural para equipos que tratan las pruebas como código, valoran las herramientas offline y de código abierto, y se sienten cómodos editando archivos .bru directamente. Bruno Ultimate añade SSO, SCIM, integraciones con administradores de secretos y funciones de auditoría si más tarde necesitas la capa de equipo y gobernanza, por lo que crecer con él es una opción en lugar de una barrera.

Elige Apidog cuando la velocidad de creación y un flujo de trabajo integrado importen más que el control a nivel de archivo. Si prefieres construir un escenario de prueba visualmente, encadenar solicitudes, extraer variables y ejecutar el mismo escenario en diferentes entornos sin escribir y depurar código de prueba manualmente, el modelo de Apidog elimina esa fricción. Diseña, depura, simula y prueba en un solo espacio de trabajo, y el CLI ejecuta el escenario exacto que construiste. Para equipos que provienen de una configuración de Postman, el modelo mental se mapea limpiamente, y la ruta de migración es una que Apidog cubre como alternativa a Postman para pruebas de API.

También hay una respuesta para ambas herramientas. Algunos equipos mantienen los archivos nativos de Git de Bruno para verificaciones de solicitudes de bajo nivel y usan Apidog para los escenarios encadenados más grandes y las ejecuciones de regresión que dependen mucho del entorno. Los dos CLIs coexisten bien en un mismo pipeline; son pasos separados con códigos de salida separados.

Si has estado decidiendo entre las plataformas de manera más amplia, no solo los CLIs, la comparación entre Apidog y Bruno cubre diseño, simulación y colaboración más allá de la línea de comandos. Para configurar tu primer escenario automatizado y ejecutarlo desde la terminal la misma tarde, descarga Apidog y copia el comando generado desde la pestaña CI/CD de cualquier escenario.

Preguntas frecuentes

¿Es gratuito el CLI de Bruno?

Sí. El CLI de Bruno es de código abierto y se distribuye como el paquete npm @usebruno/cli. Se ejecuta completamente en tu máquina o ejecutor de CI sin cuenta ni token. Bruno Ultimate es un nivel de pago separado que añade funciones de equipo y gobernanza como SSO, SCIM, integraciones con administradores de secretos y auditoría, pero el CLI en sí es gratuito.

¿Es gratuito el CLI de Apidog?

El CLI es un paquete npm gratuito, apidog-cli. Ejecuta los escenarios de prueba de tu proyecto Apidog, por lo que lo que puedes ejecutar depende de tu plan de Apidog, pero el ejecutor de línea de comandos no es un producto de pago separado.

¿Tengo que escribir las pruebas como código para alguno de los dos ejecutores?

Para Bruno, tus pruebas son archivos .bru que puedes editar manualmente o crear en la aplicación Bruno, por lo que hay un formato de texto que tocarás directamente. Para Apidog, construyes escenarios visualmente en la aplicación y el CLI los ejecuta por ID, por lo que no mantienes el código de prueba manualmente. Esa es la principal diferencia de creación entre los dos.

¿Ambos ejecutores fallan la compilación cuando una prueba falla?

Sí. Ambos salen con un código distinto de cero cuando una aserción falla, lo que la CI lee para marcar el paso como fallido y bloquear la fusión o el despliegue. El --bail de Bruno se detiene en el primer fallo; el --on-error end de Apidog hace lo mismo y es el predeterminado. Evita envolver cualquiera de las ejecuciones en || true, lo que traga el código de salida y rompe la puerta.

¿Qué formato de informe debo usar en CI?

Usa JUnit XML para el resultado legible por máquina que tu panel de CI analiza en un árbol de aprobado/fallido, y añade HTML si quieres un artefacto navegable. Bruno los escribe con --reporter-junit y --reporter-html; Apidog usa -r html,junit. Ambos también soportan JSON para un post-procesamiento personalizado.

¿Necesita el CLI de Bruno conexión a internet o una cuenta para ejecutarse?

No. Bruno ejecuta los archivos .bru en tu repositorio localmente, sin inicio de sesión y sin obtener datos remotos, lo que lo hace adecuado para CI sin conexión o aislada. El CLI de Apidog se autentica con un token de acceso y obtiene el escenario de tu proyecto, por lo que necesita acceso a la red para el servicio de Apidog en tiempo de ejecución.

¿Puedo ejecutar cualquiera de los CLI sin una instalación global?

Sí para ambos. Usa npx @usebruno/cli run ... o npx apidog-cli run ... para ejecutar sin una instalación global persistente, lo cual es conveniente en ejecutores de CI efímeros. Ejecuta bru run --help o apidog run --help para confirmar las opciones exactas disponibles en tu versión instalada.