DEV Community

Cover image for Mejores alternativas a Insomnia CLI (inso) para pruebas de API en CI
Roobia
Roobia

Posted on • Originally published at apidog.com

Mejores alternativas a Insomnia CLI (inso) para pruebas de API en CI

Si ejecutas Insomnia en CI, probablemente ya usas inso: el CLI de Insomnia para ejecutar suites de pruebas, colecciones de solicitudes y linting de especificaciones OpenAPI con Spectral. Funciona bien para equipos que ya tienen todo dentro de Insomnia, pero puede volverse frágil cuando quieres pruebas versionadas, identificadores estables o pipelines menos acoplados a una aplicación de escritorio.

Prueba Apidog hoy

Esta guía resume qué hace inso, dónde suele aparecer la fricción y qué alternativas puedes usar según tu caso: pruebas API en CI, colecciones existentes, flujos declarativos, herramientas open source o una plataforma API completa.

Qué hace inso y dónde empieza la fricción

inso lee datos desde:

  • Un directorio .insomnia en tu proyecto, normalmente creado por Git Sync.
  • El directorio de datos local de la aplicación Insomnia, si usas la app de escritorio.

Los comandos referencian suites, colecciones y especificaciones por nombre:

inso run test "My API Test Suite" --env "Staging"
inso run collection "Smoke Tests" --env "Staging"
inso lint spec "Petstore Design Doc"
inso export spec "Petstore Design Doc" --output openapi.yaml
Enter fullscreen mode Exit fullscreen mode

La instalación es directa:

brew install inso
docker pull kong/inso:latest
Enter fullscreen mode Exit fullscreen mode

También hay builds descargables para Windows, Linux y macOS.

Su punto fuerte es claro: inso lint spec usa Spectral, el linter de OpenAPI de Stoplight. Si tu pipeline depende principalmente del linting de especificaciones, no cambies de herramienta sin evaluar esa parte.

Los motivos habituales para buscar una alternativa a inso son:

  • Acoplamiento a Insomnia: las pruebas viven dentro de .insomnia o en la base de datos local de la app.
  • Referencias por nombre: si alguien renombra una suite en la GUI, el comando de CI puede romperse.
  • Dependencia de cuenta o sincronización: algunos equipos prefieren que sus datos de API no dependan de una cuenta de proveedor.
  • Mezcla de responsabilidades: inso combina linting de OpenAPI y ejecución de pruebas; quizá solo necesitas una de esas funciones.
  • Flujos Git poco explícitos: en algunos equipos es más natural que las pruebas sean archivos YAML, JSON o texto plano en el repositorio.

Comparativa rápida

Herramienta Tipo Formato de origen Basado en datos Reportes Código abierto Mejor para
Apidog CLI Ejecutor de plataforma completa Proyecto Apidog / importación OpenAPI Sí, con -d CSV/JSON CLI, HTML, JSON No, con nivel gratuito Diseño, mock, documentación y pruebas en una sola plataforma
Newman Ejecutor de colecciones Postman JSON de colección Postman Sí, con -d CSV/JSON CLI, HTML, JSON Sí Equipos con colecciones Postman existentes
Hoppscotch CLI Ejecutor de colecciones OSS JSON de Hoppscotch / ID cloud Sí, con datos de iteración CSV CLI, JUnit XML Sí Pipelines open source y autoalojables
Step CI Probador API declarativo Workflows YAML / JSON Limitado CLI, JUnit Sí Pruebas como configuración en el repositorio
Hurl Ejecutor HTTP de texto plano Archivos .hurl Mediante variables CLI, JUnit, HTML Sí Smoke tests y aserciones HTTP ligeras

1. Apidog CLI: alternativa todo en uno

Apidog es una plataforma API que cubre diseño, depuración, pruebas, simulación y documentación. Su CLI lleva la parte de pruebas a la terminal y a CI/CD.

Usa apidog run para ejecutar escenarios de prueba o colecciones:

apidog run --access-token <token> -t <scenario-id> -e <env-id>
Enter fullscreen mode Exit fullscreen mode

Ejemplo con datos externos y reportes:

apidog run -t <scenario-id> -d ./users.csv -r html,cli
Enter fullscreen mode Exit fullscreen mode

Ejemplo subiendo el reporte a la nube:

apidog run -t <scenario-id> --upload-report
Enter fullscreen mode Exit fullscreen mode

Casos prácticos donde encaja:

  • Quieres ejecutar pruebas API desde CI.
  • Necesitas reportes HTML o JSON además de salida en consola.
  • Quieres reutilizar entornos definidos en la plataforma.
  • Quieres una misma herramienta para diseño, mock, documentación y testing.

Un ejemplo básico en GitHub Actions podría verse así:

name: API tests

on:
  push:
    branches:
      - main

jobs:
  apidog-tests:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Run Apidog tests
        run: |
          apidog run \
            --access-token ${{ secrets.APIDOG_ACCESS_TOKEN }} \
            -t ${{ secrets.APIDOG_SCENARIO_ID }} \
            -e ${{ secrets.APIDOG_ENV_ID }} \
            -r cli,json
Enter fullscreen mode Exit fullscreen mode

Punto importante: Apidog CLI no reemplaza inso lint spec como linter independiente de OpenAPI. Valida especificaciones al importarlas, pero no hace linting estilo Spectral desde la terminal. Si tu necesidad principal es linting, considera usar Spectral directamente.

Pros

  • Una plataforma para diseño, mock, documentación y pruebas.
  • Ejecuciones basadas en datos con -d.
  • Reportes en CLI, HTML y JSON.
  • Soporte para entornos y subida de reportes.
  • Útil cuando quieres evitar una pila de herramientas separadas.

Contras

  • No incluye un linter OpenAPI independiente equivalente a Spectral.
  • No es completamente open source, aunque tiene nivel gratuito.

Recursos útiles:

2. Newman: si ya tienes colecciones Postman

Newman es el CLI open source de Postman para ejecutar colecciones desde terminal. Es una alternativa a inso lógica si tu equipo ya usa Postman.

Ejemplo básico:

newman run collection.json -e staging.json -d data.csv -r cli,html,json
Enter fullscreen mode Exit fullscreen mode

En CI, el flujo suele ser:

  1. Exportar la colección Postman como JSON.
  2. Exportar el entorno como JSON.
  3. Guardar ambos archivos en el repositorio o generarlos durante el pipeline.
  4. Ejecutar Newman con reportes.

Ejemplo en GitHub Actions:

name: Newman tests

on:
  pull_request:

jobs:
  api-tests:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Install Newman
        run: npm install -g newman newman-reporter-html

      - name: Run collection
        run: |
          newman run ./postman/collection.json \
            -e ./postman/staging.json \
            -d ./postman/data.csv \
            -r cli,html,json
Enter fullscreen mode Exit fullscreen mode

Pros

  • Ejecuta colecciones Postman existentes.
  • Open source.
  • Ecosistema maduro y muchas recetas de CI.
  • Buen soporte para reportes e iteraciones basadas en datos.

Contras

  • Depende del formato de colección Postman.
  • No hace linting de OpenAPI.
  • La gestión principal de colecciones sigue ligada a Postman.

Para comparar un ejecutor de colecciones con una plataforma más amplia, revisa Apidog CLI vs Newman.

3. Hoppscotch CLI: opción open source y autoalojable

Hoppscotch es un ecosistema API open source con versión web, escritorio, CLI y opciones autoalojadas. Su CLI, @hoppscotch/cli, ejecuta colecciones en CI.

Instalación:

npm i -g @hoppscotch/cli
Enter fullscreen mode Exit fullscreen mode

Nota: las versiones recientes requieren Node.js v22 o superior. Si usas Node 20, debes quedarte en CLI v0.26.0.

Ejecutar una colección local:

hopp test ./collection.json -e ./env.json
Enter fullscreen mode Exit fullscreen mode

Ejecutar con retardo:

hopp test ./collection.json -e ./env.json -d 100
Enter fullscreen mode Exit fullscreen mode

Ejecutar una colección por ID desde un servidor cloud o autoalojado:

hopp test <collection-id> --token <pat> --server https://hoppscotch.example.com
Enter fullscreen mode Exit fullscreen mode

Generar reporte JUnit:

hopp test ./collection.json --reporter-junit ./report.xml
Enter fullscreen mode Exit fullscreen mode

hopp test ejecuta solicitudes, scripts de pre-request y scripts de prueba. Si falla una aserción, el proceso termina con código distinto de cero, lo que lo hace adecuado para CI.

Pros

  • Open source y autoalojable.
  • Compatible con reportes JUnit.
  • Soporta colecciones locales o alojadas.
  • Buena opción si quieres evitar dependencia de un proveedor cerrado.

Contras

  • Node v22+ puede complicar imágenes de CI antiguas.
  • Ecosistema menor que Newman.
  • No incluye linting de OpenAPI.

Lecturas relacionadas:

4. Step CI: pruebas declarativas como código

Step CI usa archivos YAML o JSON para definir pruebas API. En lugar de depender de una colección creada en una GUI, escribes los flujos de prueba directamente en el repositorio.

Ejemplo:

version: "1.1"
name: Status check

tests:
  health:
    steps:
      - name: GET health
        http:
          url: https://api.example.com/health
          method: GET
          check:
            status: 200
Enter fullscreen mode Exit fullscreen mode

Este enfoque ayuda si tu principal problema con inso son las referencias por nombre. Aquí la prueba vive en un archivo, y la ruta del archivo se convierte en el identificador natural.

Flujo recomendado:

  1. Crea un directorio para pruebas API: 
mkdir api-tests
Enter fullscreen mode Exit fullscreen mode
  1. Guarda workflows YAML dentro del repositorio: 
api-tests/health.yml
api-tests/users.yml
Enter fullscreen mode Exit fullscreen mode
  1. Ejecútalos en local y en CI.
  2. Publica salida JUnit si tu sistema de CI la soporta.

Pros

  • Las pruebas son archivos versionados.
  • Revisables en pull requests.
  • Sin base de datos de aplicación ni dependencia de GUI.
  • Buen encaje para equipos que prefieren configuración como código.

Contras

  • Menos interactivo para depuración manual.
  • Escribes más YAML a mano.
  • Soporte basado en datos más limitado que Newman o Apidog.

Step CI es un buen reemplazo de Insomnia CLI si quieres que las pruebas estén junto al código de la aplicación y no dentro de la estructura de una herramienta.

5. Hurl: HTTP testing en texto plano

Hurl es la opción más ligera. Escribes solicitudes y aserciones en archivos .hurl, sin GUI, base de datos ni cuenta.

Ejemplo:

GET https://api.example.com/users/1
HTTP 200
[Asserts]
jsonpath "$.id" == 1
jsonpath "$.name" exists
Enter fullscreen mode Exit fullscreen mode

Ejecutar el test:

hurl --test users.hurl
Enter fullscreen mode Exit fullscreen mode

También puedes usar variables y encadenar solicitudes. Por ejemplo:

POST https://api.example.com/login
Content-Type: application/json
{
  "email": "dev@example.com",
  "password": "secret"
}

HTTP 200
[Captures]
token: jsonpath "$.token"

GET https://api.example.com/me
Authorization: Bearer {{token}}

HTTP 200
[Asserts]
jsonpath "$.email" == "dev@example.com"
Enter fullscreen mode Exit fullscreen mode

Generar reporte JUnit:

hurl --test --report-junit report.xml users.hurl
Enter fullscreen mode Exit fullscreen mode

Pros

  • Formato de texto plano simple.
  • Fácil de versionar.
  • Huella mínima en CI.
  • Ideal para smoke tests, health checks y contratos simples.

Contras

  • Los escenarios complejos pueden volverse verbosos.
  • No hay GUI de colecciones.
  • No reemplaza linting de OpenAPI.

Cómo elegir

Elige según el trabajo que necesitas automatizar:

  • Quieres una plataforma para diseño, mock, documentación y pruebas: usa Apidog CLI.
  • Ya tienes colecciones Postman: usa Newman.
  • Quieres open source y autoalojable: usa Hoppscotch CLI.
  • Quieres pruebas declarativas en tu repositorio: usa Step CI.
  • Quieres checks HTTP mínimos y rápidos: usa Hurl.
  • Tu caso principal es inso lint spec: conserva inso o usa Spectral directamente.

Una estrategia práctica es separar responsabilidades:

# Lint de OpenAPI
spectral lint openapi.yaml

# Pruebas de API
apidog run -t <scenario-id> -e <env-id>
Enter fullscreen mode Exit fullscreen mode

O, si usas Newman:

spectral lint openapi.yaml
newman run collection.json -e staging.json
Enter fullscreen mode Exit fullscreen mode

Así no dependes de que una sola herramienta cubra linting, ejecución, reportes y gestión de colecciones.

Si estás migrando desde el ecosistema de Insomnia, también puedes revisar:

Top comments (0)