DEV Community

Cover image for Cómo migrar de la CLI de Hoppscotch a la CLI de Apidog
Roobia
Roobia

Posted on • Originally published at apidog.com

Cómo migrar de la CLI de Hoppscotch a la CLI de Apidog

El CLI de Hoppscotch funciona bien cuando solo necesitas ejecutar colecciones de API desde la terminal o CI. hopp test lee una colección, aplica el entorno, ejecuta scripts de pre-request y pruebas, y devuelve un código distinto de cero si falla una aserción. Si tu flujo termina ahí, no necesitas migrar.

Prueba Apidog hoy

Pero si además mantienes diseño de API, mocks, documentación y pruebas en herramientas separadas, el problema ya no es el runner: es la falta de una fuente única de verdad. En ese caso, migrar del CLI de Hoppscotch al CLI de Apidog te permite ejecutar pruebas en CI mientras el proyecto centraliza diseño, depuración, mocking, documentación y testing.

Cuándo migrar y cuándo quedarte con Hoppscotch

Quédate con Hoppscotch si tu requisito es simple:

npm i -g @hoppscotch/cli
hopp test ./collections/checkout-api.json -e ./environments/staging.json
Enter fullscreen mode Exit fullscreen mode

Es una opción válida si quieres un runner ligero, gratuito y de código abierto.

Considera migrar a Apidog cuando tengas estos problemas:

  • Diseñas APIs en una herramienta, haces mocks en otra y documentas en una tercera.
  • Las pruebas, mocks y documentación no comparten la misma definición de API.
  • Necesitas reportes HTML o JSON además del resultado en CI.
  • Quieres gestionar endpoints, esquemas, entornos y ramas desde un proyecto central.
  • Quieres que CI ejecute pruebas desde el estado real del proyecto, no desde archivos exportados manualmente.

La migración no consiste solo en cambiar hopp test por apidog run. El beneficio principal es mover las pruebas a una plataforma donde el diseño, los mocks, la documentación y las ejecuciones comparten el mismo proyecto.

Paso 1: Exporta tu colección y entorno de Hoppscotch

Hoppscotch usa JSON, así que empieza exportando los dos archivos que ya usas en CI:

  1. Abre Hoppscotch.
  2. Entra en la colección que ejecutas con hopp test.
  3. Usa el menú de la colección y selecciona Exportar.
  4. Guarda el archivo, por ejemplo: 
collections/checkout-api.json
Enter fullscreen mode Exit fullscreen mode
  1. Abre el panel de entornos.
  2. Exporta el entorno usado en CI, por ejemplo: 
environments/staging.json
Enter fullscreen mode Exit fullscreen mode

Tu ejecución actual probablemente se parece a esto:

npm i -g @hoppscotch/cli

hopp test ./collections/checkout-api.json \
  -e ./environments/staging.json
Enter fullscreen mode Exit fullscreen mode

Conserva ambos archivos. La colección contiene las solicitudes y scripts; el entorno contiene variables como base_url, api_token o cualquier valor que uses en URLs, headers y assertions.

Ten en cuenta también la versión de Node.js. El CLI actual de Hoppscotch requiere Node.js v22 o superior; si tu equipo está anclado a Node 20, normalmente debe usar @hoppscotch/cli v0.26.0. La migración es una buena oportunidad para revisar esa restricción dentro de tu pipeline.

Paso 2: Importa la colección a Apidog

Crea o abre un proyecto en Apidog. Luego importa la colección exportada desde Hoppscotch.

Flujo recomendado:

  1. Crea un proyecto en Apidog.
  2. Importa checkout-api.json.
  3. Si también tienes una especificación OpenAPI, impórtala en el mismo proyecto.
  4. Revisa los endpoints importados.
  5. Crea un entorno equivalente a staging.json.
  6. Copia las variables manteniendo los mismos nombres.

Ejemplo:

{
  "base_url": "https://staging.example.com",
  "api_token": "********"
}
Enter fullscreen mode Exit fullscreen mode

Si en Hoppscotch usabas base_url, usa también base_url en Apidog. Si usabas api_token, conserva api_token. Mantener los nombres evita tener que reescribir URLs, headers o scripts.

Después de importar, los endpoints ya no son solo requests dentro de un archivo. En Apidog puedes usarlos como artefactos de diseño, asociarlos a esquemas, generar mocks y publicar documentación desde la misma definición que usas para probar.

Para profundizar después de la importación, consulta la guía completa del CLI de Apidog y la guía de instalación.

Paso 3: Sustituye hopp test por apidog run

El cambio principal en CI es este:

# Hoppscotch
hopp test ./collections/checkout-api.json -e ./environments/staging.json

# Apidog
apidog run --access-token "$APIDOG_TOKEN" -e "Staging"
Enter fullscreen mode Exit fullscreen mode

El contrato para CI se mantiene:

  • Se ejecutan las solicitudes.
  • Se ejecutan scripts de pre-request.
  • Se ejecutan las aserciones.
  • Si falla una aserción, el comando devuelve un código distinto de cero.
  • El job de CI falla automáticamente.

La diferencia está en la fuente de verdad. Hoppscotch ejecuta un archivo local exportado. Apidog ejecuta recursos del proyecto usando autenticación.

Guarda el token como variable de entorno:

export APIDOG_TOKEN="tu_token"
Enter fullscreen mode Exit fullscreen mode

Y ejecútalo así:

apidog run \
  --access-token "$APIDOG_TOKEN" \
  -e "Staging"
Enter fullscreen mode Exit fullscreen mode

Hoppscotch usa --token para colecciones en la nube o autoalojadas. Apidog permite autenticación mediante inicio de sesión o token de acceso, de modo que el CLI pueda acceder a los recursos del proyecto. Si necesitas configurar esto desde cero, revisa el tutorial de autenticación.

Paso 4: Migra las pruebas basadas en datos

Si ya usas CSV o JSON para ejecutar la misma colección con múltiples entradas, puedes conservar ese patrón.

En Hoppscotch:

hopp test ./collections/checkout-api.json \
  -e ./environments/staging.json \
  --iteration-count 50 \
  --iteration-data ./data/orders.csv
Enter fullscreen mode Exit fullscreen mode

En Apidog:

apidog run \
  --access-token "$APIDOG_TOKEN" \
  -e "Staging" \
  -d ./data/orders.csv
Enter fullscreen mode Exit fullscreen mode

El archivo CSV puede seguir usando una fila de encabezado para definir variables:

order_id,email,expected_status
1001,user1@example.com,201
1002,user2@example.com,201
1003,user3@example.com,400
Enter fullscreen mode Exit fullscreen mode

Luego puedes referenciar esas variables dentro de requests y assertions según tu configuración del escenario.

Punto importante: en Hoppscotch, --iteration-count controla el número de iteraciones. En Apidog, el dataset define las iteraciones que se ejecutan. Si el CSV tiene 50 filas de datos, tendrás 50 ejecuciones.

La guía de pruebas basadas en datos explica cómo mapear columnas a variables y ejecutar una fila por iteración.

Paso 5: Convierte los reportes

En Hoppscotch, si tu pipeline consume JUnit XML, puedes tener algo como esto:

hopp test ./collections/checkout-api.json \
  -e ./environments/staging.json \
  --reporter-junit ./reports/results.xml
Enter fullscreen mode Exit fullscreen mode

En Apidog, puedes generar reportes en formatos como CLI, HTML o JSON, y también subir el reporte para conservar historial en la nube.

Ejemplo con reporte HTML:

apidog run \
  --access-token "$APIDOG_TOKEN" \
  -e "Staging" \
  -r html \
  --upload-report
Enter fullscreen mode Exit fullscreen mode

Ejemplo con reporte JSON para procesamiento automático:

apidog run \
  --access-token "$APIDOG_TOKEN" \
  -e "Staging" \
  -r json
Enter fullscreen mode Exit fullscreen mode

Si tu CI depende estrictamente de JUnit XML, valida esa integración antes de eliminar el job anterior. Apidog se enfoca en reportes CLI, HTML, JSON y reportes subidos a la nube, en lugar de una bandera JUnit equivalente.

Para equipos que comparten resultados con QA, backend, frontend o stakeholders, el reporte HTML y el historial en la nube suelen ser más útiles que un XML sin procesar. La guía de informes de prueba detalla cuándo usar cada formato.

Antes y después: mapeo de comandos

Tarea CLI de Hoppscotch CLI de Apidog
Instalar npm i -g @hoppscotch/cli Según la guía de instalación
Ejecutar una colección hopp test collection.json apidog run
Seleccionar entorno -e env.json -e "Staging"
Token de autenticación --token <pat> inicio de sesión / --access-token
Objetivo auto-alojado / en la nube --server <url> proyecto + token de acceso
Entradas basadas en datos --iteration-data orders.csv -d orders.csv
Repetir ejecuciones --iteration-count 50 conjunto de datos de iteración
Añadir retraso entre solicitudes -d <ms> configuración por escenario
Informe JUnit --reporter-junit results.xml -r json o CLI / HTML
Historial de ejecución en la nube no integrado --upload-report

Cuidado con -d: en Hoppscotch significa retraso en milisegundos; en Apidog indica el dataset para pruebas basadas en datos. Es el cambio de flag que más suele causar errores durante la migración.

Paso 6: Añade Apidog a GitHub Actions

No reemplaces el job antiguo a ciegas. Primero ejecuta Apidog en paralelo, valida varias ejecuciones y luego elimina Hoppscotch.

Ejemplo de workflow:

name: API tests

on: [push, pull_request]

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

    steps:
      - uses: actions/checkout@v4

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

      - name: Run API tests
        env:
          APIDOG_TOKEN: ${{ secrets.APIDOG_TOKEN }}
        run: |
          apidog run \
            --access-token "$APIDOG_TOKEN" \
            -e "Staging" \
            -d ./data/orders.csv \
            -r html \
            --upload-report
Enter fullscreen mode Exit fullscreen mode

Checklist para integrarlo correctamente:

  1. Crea un token de acceso para Apidog.
  2. Guárdalo como secreto del repositorio, por ejemplo APIDOG_TOKEN.
  3. Instala el CLI en el job.
  4. Ejecuta apidog run.
  5. Usa el mismo entorno que configuraste en Apidog.
  6. Genera el reporte que necesite tu equipo.
  7. Mantén temporalmente el job anterior de Hoppscotch.
  8. Elimina Hoppscotch cuando Apidog esté estable.

El comportamiento de fallo se mantiene: si una aserción falla, apidog run devuelve un código distinto de cero y GitHub Actions marca el job como fallido.

Para configuraciones más avanzadas, revisa la guía de GitHub Actions y la guía de pipeline CI/CD, que cubre otros entornos como GitLab y Jenkins.

Paso 7: Retira Hoppscotch del pipeline

Cuando el job de Apidog esté en verde durante varias ejecuciones:

  1. Elimina la instalación de Hoppscotch: 
npm i -g @hoppscotch/cli
Enter fullscreen mode Exit fullscreen mode
  1. Elimina el comando anterior: 
hopp test ./collections/checkout-api.json -e ./environments/staging.json
Enter fullscreen mode Exit fullscreen mode
  1. Borra secretos que ya no uses, como tokens específicos de Hoppscotch.
  2. Decide si conservarás las exportaciones JSON como respaldo o si el proyecto de Apidog pasará a ser la fuente principal.

La migración ideal termina sin romper el pipeline: primero duplicas, luego validas y finalmente reemplazas.

Una nota justa sobre Hoppscotch

Hoppscotch sigue siendo una buena herramienta. Su CLI es rápido, gratuito, de código abierto y puede encajar muy bien si solo necesitas ejecutar colecciones.

La razón para migrar no es que hopp test deje de servir. La razón aparece cuando el diseño, los mocks, la documentación y las pruebas deben mantenerse sincronizados. En ese escenario, un runner independiente no resuelve el problema de fondo; una plataforma integrada sí.

Si quieres comparar ambos enfoques, revisa Apidog CLI vs Hoppscotch CLI. Si también estás evaluando las aplicaciones completas, estos análisis añaden contexto: Postman vs Hoppscotch y alternativas a Hoppscotch.

Top comments (0)