La CLI de Hoppscotch es una forma gratuita y de código abierto de ejecutar colecciones de API desde un terminal. Si ya utilizas Hoppscotch en la web o en el escritorio, hopp test te permite enviar esas mismas solicitudes a un pipeline de CI sin pagar nada. Esa es una verdadera fortaleza, y este artículo no pretende lo contrario.
Pero la CLI de Hoppscotch también es limitada a propósito. Ejecuta colecciones e informa resultados. No diseña APIs, no las simula (mock), no las documenta ni las gestiona como código. Por lo tanto, muchos equipos llegan a un punto en el que desean una única herramienta que haga más que ejecutar un archivo JSON, o se encuentran con un punto de fricción como el requisito de Node v22 y comienzan a buscar alternativas.
Qué hace realmente la CLI de Hoppscotch
La CLI de Hoppscotch se distribuye como el paquete npm @hoppscotch/cli. Lo instalas globalmente:
npm i -g @hoppscotch/cli
Una cosa a saber de antemano: necesita Node.js v22 o posterior. Si estás atascado en Node 20, te quedas en la CLI v0.26.0, lo que puede complicar una imagen de CI compartida donde otros trabajos fijan una versión anterior de Node.
El comando principal es hopp test. Lo apuntas a un archivo de colección (o un ID de colección en la nube) y ejecuta cada solicitud en orden:
hopp test ./collection.json -e ./environment.json -d 500
Para instancias en la nube o autoalojadas, pasas un ID más las credenciales:
hopp test <collection-id> -e <environment-id> --token <access_token> --server <server-url>
Ejecuta scripts previos a la solicitud y scripts de prueba (suites pw.test(), casos pw.expect()), valida las respuestas y sale con un código distinto de cero si alguna aserción falla. También soporta --reporter-junit <path> para JUnit XML, además de --iteration-count y --iteration-data <csv> para ejecuciones basadas en datos. Es un ejecutor gratuito genuinamente capaz.
Por qué los equipos buscan una alternativa a hopp test
Las razones por las que la gente busca un reemplazo para la CLI de Hoppscotch suelen ser prácticas, no ideológicas:
- Es un ejecutor de colecciones, nada más. El diseño, la simulación (mocking) y la documentación residen en otro lugar. Terminas uniendo varias herramientas.
- Primero tienes que exportar JSON. Las especificaciones y los entornos se introducen como archivos de colección/entorno exportados (o IDs de la nube). No hay linting de especificaciones ni capa de diseño en la propia CLI.
- El límite inferior de Node v22. Más nuevo que la versión predeterminada de muchas imágenes de compilación, lo que significa un manejo adicional de versiones.
- No hay flujo de trabajo de "especificación como código". No puedes gestionar puntos finales, esquemas o ramas desde la CLI. La CLI es un eslabón posterior a donde definiste la API.
Nada de eso hace que Hoppscotch sea malo. Lo convierte en una herramienta enfocada. Si deseas una cobertura más amplia, aquí tienes las alternativas que valen la pena.
1. Apidog CLI (la mejor alternativa todo en uno)
Apidog es una plataforma de API todo en uno que cubre el diseño, la depuración, la simulación (mocking), la documentación y las pruebas. La CLI de Apidog lleva el lado de las pruebas y la gestión de recursos al terminal y a CI/CD, lo que la convierte en una fuerte alternativa a un ejecutor de colecciones independiente.
Con apidog run, ejecutas escenarios de prueba y colecciones desde la línea de comandos. Soporta pruebas basadas en datos a través de -d (conjuntos de datos CSV o JSON), entornos mediante -e, reportes en formatos CLI, HTML y JSON, y reportes de prueba en la nube con --upload-report. Más allá de ejecutar pruebas, la CLI puede importar OpenAPI y gestionar recursos de API, puntos finales, esquemas, entornos, ramas y solicitudes de fusión, como código. Así, la definición de tu API y tus pruebas viven en el mismo sistema en lugar de exportarse de un lado a otro.
Para ser precisos sobre el alcance: Apidog valida las especificaciones al importarlas, pero no incluye un linter de OpenAPI independiente ni un comando split/join/bundle. Si el linting de especificaciones puro en CI es tu objetivo, inso (a continuación) es la opción más adecuada. La propuesta de Apidog es la integración: diseñas, simulas, documentas y pruebas en un solo lugar, y luego manejas las capas de prueba y recursos desde la CLI.
Pros:
- Una plataforma para diseño, simulación, documentación y pruebas en lugar de una cadena de herramientas
- Ejecuciones basadas en datos con conjuntos de datos CSV/JSON
- Informes CLI, HTML y JSON, además de informes en la nube subibles
- Recurso como código: gestiona puntos finales, esquemas, ramas y solicitudes de fusión desde la CLI
- Importa OpenAPI directamente
Contras:
- No hay un comando linter de especificaciones independiente (usa inso o Redocly para linting estilo Spectral)
- La plataforma completa es más de lo que necesitas si solo ejecutas una colección
Si estás comparando los dos cara a cara, consulta Apidog CLI vs Hoppscotch CLI y el práctico tutorial migrar Hoppscotch CLI a Apidog CLI. La guía completa de la CLI de Apidog cubre la instalación, autenticación y el conjunto completo de comandos. Para probarla, descarga Apidog.
2. Newman (el ejecutor de Postman)
Newman es el ejecutor oficial de colecciones de Postman para la línea de comandos. Si tu equipo ya utiliza Postman, Newman es el camino de menor resistencia: exporta la colección y el entorno, y luego ejecútalos en CI.
newman run collection.json -e env.json -r cli,json
Soporta múltiples generadores de informes (CLI, JSON, JUnit, HTML a través de un plugin), archivos de datos para iteraciones y un contrato de código de salida estable para pipelines.
Pros:
- Maduro, ampliamente documentado, enorme ecosistema
- Compatibilidad de primera clase con Postman
- Generadores de informes flexibles e iteraciones basadas en datos
Contras:
- Al igual que Hoppscotch CLI, es solo un ejecutor, no tiene capa de diseño o documentación
- Vinculado al formato de colección de Postman y su modelo de scripting
- Aún tienes que exportar JSON para usarlo
Para una comparación directa con el enfoque de Apidog, consulta Apidog CLI vs Newman.
3. inso (CLI de Insomnia de Kong)
inso es el compañero de línea de comandos del cliente de código abierto Insomnia de Kong. Hace algo que la CLI de Hoppscotch no hace: verifica las especificaciones OpenAPI (linting). La verificación se realiza con Spectral, el linter de OpenAPI de Stoplight, por lo que si las puertas de calidad de las especificaciones en CI son importantes para ti, inso es un verdadero contendiente.
inso run test "My Test Suite" --env "Staging"
inso lint spec "My API Design"
inso export spec "My API Design" --output output.yaml
inso lee de un directorio .insomnia (creado por Git Sync de Insomnia) o del directorio de datos de la aplicación, y hace referencia a suites y especificaciones por nombre. Puedes instalarlo con brew install inso o docker pull kong/inso:latest.
Pros:
- Verificación real de OpenAPI mediante Spectral
- Ejecuta pruebas y colecciones, exporta especificaciones, todo desde el terminal
- Rutas de instalación con Brew y Docker
Contras:
- Hace referencia a los recursos por nombre, lo que puede ser frágil en scripts
- Insomnia 8 introdujo una cuenta de inicio de sesión/nube obligatoria en 2023 que generó controversia, y hubo incidentes de migración y pérdida de datos relacionados con ese cambio. Es importante saberlo si estás adoptando el ecosistema por primera vez.
Si estás evaluando Insomnia de manera más amplia, Apidog vs Insomnia y las mejores alternativas a la aplicación Insomnia son buenas lecturas. También hay una comparación específica Apidog CLI vs inso (Insomnia CLI).
4. Step CI (pruebas de API de código abierto en YAML)
Step CI es una herramienta de calidad de API de código abierto que define pruebas en YAML declarativo en lugar de JS con scripts. Describes la solicitud y la respuesta esperada, y las verifica. Soporta REST, GraphQL y gRPC, lo que es una cobertura de protocolo más amplia que la mayoría de los ejecutores de colecciones.
npx stepci run workflow.yml
Pros:
- YAML declarativo, fácil de leer en control de versiones
- Multi-protocolo (REST, GraphQL, gRPC)
- Sin dependencia de GUI, la configuración reside completamente en tu repositorio
Contras:
- Comunidad y ecosistema más pequeños
- Sin capa de diseño, simulación o documentación
- Escribes las pruebas a mano en YAML en lugar de grabarlas
Step CI es una buena opción si quieres pruebas nativas de Git, legibles por humanos y no necesitas ninguna interfaz de usuario.
5. Hurl (pruebas HTTP de texto plano)
Hurl ejecuta solicitudes HTTP escritas en un formato de texto plano simple y realiza aserciones sobre las respuestas. Está construido sobre libcurl, se ejecuta rápidamente y produce una salida limpia. No hay scripts ni colecciones JSON, solo archivos .hurl que puedes comparar en una pull request.
GET https://api.example.com/health
HTTP 200
[Asserts]
jsonpath "$.status" == "up"
Ejecútalo con:
hurl --test health.hurl
Pros:
- Extremadamente ligero, binario único, rápido
- Archivos de texto plano que se leen como documentación
- Excelente para pruebas de humo y comprobaciones de estado en CI
Contras:
- Nivel más bajo que un marco de pruebas completo
- Sin características de diseño, simulación o documentación
- Menos conveniente para escenarios complejos, encadenados o basados en datos
Hurl destaca por sus comprobaciones rápidas y legibles de contratos y pruebas de humo. No intenta ser una plataforma.
Tabla comparativa
| Herramienta | Licencia | Enfoque principal | Basado en datos | Linting de especificaciones | Diseño/simulación/docs | Formatos de informe |
|---|---|---|---|---|---|---|
| Apidog CLI | Comercial (nivel gratuito) | Plataforma completa + pruebas CLI | Sí (CSV/JSON) | No (valida en la importación) | Sí | CLI, HTML, JSON, nube |
| Hoppscotch CLI | Código abierto | Ejecutor de colecciones | Sí (iteraciones CSV) | No | No | CLI, JUnit |
| Newman | Código abierto | Ejecutor de Postman | Sí (archivos de datos) | No | No | CLI, JSON, JUnit, HTML |
| inso | Código abierto | Ejecutor de Insomnia + linter | Limitado | Sí (Spectral) | Parcial (docs de diseño) | CLI, JUnit |
| Step CI | Código abierto | Pruebas de API en YAML | Sí | No | No | CLI, JUnit |
| Hurl | Código abierto | Pruebas HTTP de texto plano | Mediante plantillas | No | No | CLI, JUnit, HTML |
Cómo elegir
- Quieres una herramienta para todo, desde el diseño hasta las pruebas: Apidog CLI. Elimina el baile de exportar JSON y luego ejecutar, y mantiene tus recursos de API y pruebas en el mismo sistema.
- Tu equipo ya usa Postman: Newman. El costo de cambio más bajo.
- Necesitas linting de OpenAPI en CI: inso, debido a Spectral.
- Quieres pruebas declarativas y nativas de Git: Step CI (YAML) o Hurl (texto plano).
- Estás contento con un ejecutor OSS gratuito y solo quieres dejar Node 22: cualquiera de los anteriores, ya que Newman, Step CI y Hurl no comparten ese requisito.
Si tu principal razón para cambiar es el límite del ejecutor de colecciones en lugar de una molestia específica, la ruta integrada es la primera que debes considerar. Consulta Apidog CLI vs Postman CLI y pipeline CI/CD de Apidog CLI para ver cómo el lado de las pruebas encaja en un pipeline real, y informes de prueba de Apidog CLI para las opciones de informes.
Preguntas Frecuentes
¿La CLI de Hoppscotch es gratuita? Sí. @hoppscotch/cli es de código abierto y de uso gratuito. Ejecuta colecciones, scripts de prueba y emite informes JUnit. Las alternativas aquí no se refieren a que Hoppscotch sea costoso, sino a querer más que un simple ejecutor.
¿Cuál es la alternativa más simple a la CLI de Hoppscotch si no quiero Node v22? Hurl es un binario único sin dependencia de Node. inso se instala a través de Homebrew o Docker. Step CI se ejecuta a través de npx pero no está vinculado a Node 22 de la misma manera que la CLI actual de Hoppscotch.
¿Puedo mover mis colecciones existentes de Hoppscotch a otra herramienta? Sí. La mayoría de las herramientas aceptan colecciones exportadas o OpenAPI. Para la ruta integrada, la guía migrar Hoppscotch CLI a Apidog CLI te muestra cómo importar y volver a ejecutar tus suites.
¿La CLI de Apidog verifica las especificaciones OpenAPI como lo hace inso? No. Apidog valida las especificaciones al importarlas, pero no tiene un comando linter independiente. Si la aplicación de una guía de estilo estilo Spectral en CI es un requisito estricto, combina Apidog con inso o usa Apidog CLI vs Redocly CLI para comparar la opción centrada en el linting.
¿Qué alternativa es mejor para un pipeline de CI? Todas devuelven códigos de salida distintos de cero en caso de fallo, por lo que todas funcionan en CI. El factor decisivo es qué más necesitas: las ejecuciones puras favorecen a Newman o Hurl; una única fuente de verdad para el diseño más las pruebas favorece a Apidog CLI; las puertas de especificación favorecen a inso.
La CLI de Hoppscotch hace bien su único trabajo. Si ese único trabajo es todo lo que necesitas, quédate con ella. Si prefieres consolidar el diseño, la simulación, la documentación y las pruebas en un único flujo de trabajo en lugar de conectar ejecutores, una plataforma integrada es la opción. Comienza con la guía completa de la CLI de Apidog, luego descarga Apidog y ejecuta tu primer escenario.