DEV Community

Cover image for ¿Qué es Inso? Insomnia CLI
Roobia
Roobia

Posted on • Originally published at apidog.com

¿Qué es Inso? Insomnia CLI

Si usa Insomnia como cliente API, ya tiene una interfaz gráfica para enviar solicitudes, diseñar especificaciones OpenAPI y escribir pruebas. El problema aparece cuando quiere ejecutar esas mismas pruebas en CI/CD o lintar una especificación en cada pull request. Para eso necesita una CLI. En el ecosistema de Insomnia, esa CLI es inso.

Prueba Apidog hoy

Esta guía muestra qué es inso, cómo instalarlo, qué comandos usar en el día a día, cómo conectarlo con sus datos de Insomnia y qué límites debe considerar antes de integrarlo en su pipeline.

¿Qué es inso?

inso es el compañero de línea de comandos de Insomnia, el cliente API de código abierto mantenido por Kong. Permite automatizar tres tareas principales desde la terminal:

  • Ejecutar suites de pruebas creadas en Insomnia.
  • Ejecutar colecciones de solicitudes.
  • Lintar especificaciones OpenAPI.

Imagen

En términos prácticos: inso le permite ejecutar trabajo definido en Insomnia sin abrir la aplicación. Usted referencia una especificación, colección, suite o entorno por nombre, y la CLI los resuelve desde los datos de Insomnia.

Instalación de la CLI de inso

Tiene varias formas de instalar inso. Elija según el entorno donde lo vaya a ejecutar.

macOS o Linux con Homebrew 

brew install inso
Enter fullscreen mode Exit fullscreen mode

CI/CD con Docker

Para runners limpios, Docker suele ser la opción más simple porque evita instalar dependencias locales:

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

Descarga directa

Kong publica archivos ZIP para Windows, Linux y macOS en la documentación oficial de la CLI de inso. Esta opción es útil si quiere fijar una versión concreta dentro de un artefacto de build.

Instalación con npm

Históricamente, inso también se distribuía como paquete npm bajo el nombre insomnia-inso. Esa ruta todavía existe, pero para configuraciones nuevas es preferible usar Homebrew, Docker o descargas directas, que son las rutas documentadas y recomendadas actualmente.

Verifique la instalación:

inso --version
Enter fullscreen mode Exit fullscreen mode

Comandos principales de inso

La CLI tiene una superficie pequeña. Estos son los comandos que probablemente usará en proyectos reales.

Ejecutar una suite de pruebas: inso run test

Use este comando para ejecutar una suite de pruebas creada en Insomnia contra un entorno específico:

inso run test "Payments API tests" --env "Staging"
Enter fullscreen mode Exit fullscreen mode

La suite y el entorno se referencian por nombre, tal como aparecen en Insomnia.

Este comando es útil en CI porque devuelve un código de salida distinto de cero si falla alguna aserción. Por ejemplo, puede usarlo como gate antes de desplegar:

inso run test "Payments API tests" --env "CI" --workingDir .
Enter fullscreen mode Exit fullscreen mode

Ejecutar una colección: inso run collection

Para ejecutar todas las solicitudes de una colección en secuencia:

inso run collection "Checkout flow" --env "Staging"
Enter fullscreen mode Exit fullscreen mode

Este comando funciona bien para pruebas de humo. Por ejemplo, puede validar rápidamente que un flujo básico de checkout responde correctamente después de un despliegue.

Lintar una especificación OpenAPI: inso lint spec

Para validar una especificación OpenAPI definida en Insomnia:

inso lint spec "Orders API"
Enter fullscreen mode Exit fullscreen mode

Internamente, inso lint spec usa Spectral, el linter de OpenAPI y JSON de Stoplight. Esto significa que no solo obtiene una validación superficial de sintaxis, sino linting basado en reglas.

Si su equipo aplica convenciones de diseño de API, este comando es una de las razones más fuertes para usar inso.

Ejemplo en CI:

inso lint spec "Orders API" --workingDir .
Enter fullscreen mode Exit fullscreen mode

Exportar una especificación: inso export spec

Para extraer una especificación de Insomnia a un archivo local:

inso export spec "Orders API" --output orders.yaml
Enter fullscreen mode Exit fullscreen mode

Esto es útil cuando necesita:

  • Pasar la especificación a un generador de SDK.
  • Guardar una snapshot.
  • Entregar un archivo YAML a otra herramienta.
  • Publicar la especificación como artefacto de CI.

Ejecutar scripts: inso script

También puede ejecutar scripts definidos en sus datos de Insomnia:

inso script deploy-smoke --env env_9f2a
Enter fullscreen mode Exit fullscreen mode

Este comando sirve como punto de extensión cuando necesita encadenar pasos personalizados alrededor de sus pruebas o colecciones.

Cómo inso encuentra sus especificaciones y colecciones

inso no almacena especificaciones, colecciones ni entornos por sí mismo. Lee datos desde una de estas fuentes:

  1. Un directorio .insomnia en el directorio de trabajo.
  2. El directorio de datos de la aplicación Insomnia instalada localmente.

Para CI/CD, el patrón recomendado es usar Git Sync de Insomnia y confirmar el directorio .insomnia en el repositorio. Así el runner puede ejecutar inso sin depender de una instalación local de Insomnia.

Ejemplo:

inso lint spec "Orders API" --workingDir .
Enter fullscreen mode Exit fullscreen mode

También puede apuntar explícitamente a una fuente:

inso run test "Payments API tests" --src ./api-project/.insomnia
Enter fullscreen mode Exit fullscreen mode

El modelo mental es este:

  • inso resuelve recursos por nombre o ID.
  • Esos nombres deben existir en la fuente de datos que está leyendo.
  • Si una suite, entorno o especificación no está en .insomnia o en los datos locales de Insomnia, inso no puede ejecutarla.
  • No puede apuntar directamente a un archivo OpenAPI suelto y decirle a inso que lo pruebe, salvo que ese archivo forme parte de una estructura de proyecto de Insomnia.

Ejemplo mínimo con GitHub Actions

Este workflow ejecuta linting de una especificación y una suite de pruebas en cada push.

Asume que el repositorio contiene un directorio .insomnia sincronizado desde Insomnia:

name: API checks
on: [push]

jobs:
  inso:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Install inso
        run: |
          curl -sSL https://github.com/Kong/insomnia/releases/latest/download/inso-linux-x64.zip -o inso.zip
          unzip inso.zip && sudo mv inso /usr/local/bin/

      - name: Lint the spec
        run: inso lint spec "Orders API" --workingDir .

      - name: Run the test suite
        run: inso run test "Payments API tests" --env "CI" --workingDir .
Enter fullscreen mode Exit fullscreen mode

Si el linting falla o alguna aserción no pasa, el job falla. Ese es el objetivo principal de mover estas comprobaciones desde la interfaz gráfica hacia la terminal: convertirlas en validaciones automatizadas.

Buenas prácticas al usar inso en CI

Para evitar fallos difíciles de depurar, considere estas prácticas:

  • Use nombres estables para suites, colecciones y entornos.
  • Evite renombrar recursos usados por pipelines.
  • Confirme el directorio .insomnia si quiere reproducibilidad en CI.
  • Use --workingDir o --src explícitamente en scripts automatizados.
  • Cree un entorno específico para CI, por ejemplo "CI" o "Staging CI".
  • Mantenga secretos fuera del repositorio y resuélvalos mediante variables del entorno de CI cuando sea posible.

Ejemplo de ejecución con entorno dedicado:

inso run test "Regression tests" --env "CI" --workingDir .
Enter fullscreen mode Exit fullscreen mode

Limitaciones de inso

inso es útil, pero tiene límites importantes.

Primero, está ligado a las fuentes de datos de Insomnia. Sus especificaciones, colecciones y suites deben vivir dentro de un proyecto de Insomnia, ya sea mediante Git Sync o mediante la aplicación instalada. Si su equipo no usa Insomnia como fuente de verdad, inso no tendrá datos sobre los que operar.

Segundo, muchos recursos se referencian por nombre. Eso es legible, pero también frágil. Si alguien cambia el nombre de una suite en Insomnia, el pipeline que usa el nombre anterior fallará en la siguiente ejecución.

Tercero, el alcance de la herramienta es intencionalmente estrecho. inso ejecuta pruebas, ejecuta colecciones, linta especificaciones, exporta especificaciones y ejecuta scripts. No reemplaza una plataforma completa de diseño, mock, documentación y pruebas.

inso vs. una plataforma integrada

inso funciona bien si Insomnia ya es su cliente principal y solo necesita llevar ciertas tareas a la terminal. La desventaja es que termina combinando varias piezas:

  • Insomnia para diseño y depuración.
  • inso para CI.
  • Spectral para linting.
  • Otras herramientas para mocks, documentación o flujos más completos.

Imagen

Apidog sigue un enfoque diferente. Combina diseño, simulación, documentación y pruebas en una sola plataforma. Su CLI de Apidog ejecuta escenarios de prueba y colecciones desde la misma fuente de verdad, con pruebas impulsadas por datos, múltiples formatos de informe y recursos y ramas como código.

Hay una diferencia importante: la CLI de Apidog no incluye un linter de especificaciones independiente como inso con Spectral. Si su prioridad principal es aplicar reglas de estilo OpenAPI al nivel de Spectral, inso tiene una ventaja clara. Si su prioridad es integrar diseño, pruebas, mocks y documentación sin unir varias herramientas, Apidog puede encajar mejor.

Para comparar ambas opciones, consulte Apidog CLI vs inso (CLI de Insomnia) o lea una explicación más amplia sobre qué es inso (CLI de Insomnia).

Si ya decidió que inso no encaja con su flujo, revise el resumen de las mejores alternativas a inso y la guía para migrar de inso a la CLI de Apidog.

Para contexto adicional sobre clientes GUI, también puede leer Apidog vs Insomnia y cómo usar Insomnia para probar una API.

Puede descargar Apidog gratis si quiere comparar el enfoque integrado con su configuración actual de inso.

Top comments (0)