Las pruebas de API ya no dependen de una interfaz gráfica. Hoy se ejecutan en contenedores de CI sin pantalla, entornos de staging accesibles solo por SSH y agentes de IA que operan mediante shell. En todos esos casos, una prueba debe poder instalarse, ejecutarse y devolver un código de salida desde la terminal.
Esta guía reúne herramientas que realizan pruebas reales desde la línea de comandos. Una herramienta «basada en terminal» debe permitir completar el ciclo desde un shell:
- Instalarla con un gestor de paquetes.
- Ejecutar pruebas con un comando.
- Evaluar el resultado mediante el código de salida.
- Generar resultados útiles para CI.
La clasificación prioriza aserciones integradas, flujos de varios pasos, informes para CI y estado de mantenimiento. Clientes manuales como curl también aparecen porque siguen siendo esenciales entre ejecuciones de pruebas. Para una comparación más amplia, incluidas herramientas GUI y alojadas, consulta las mejores herramientas gratuitas para pruebas de API.
Qué diferencia a una herramienta de prueba de un cliente
Un cliente de terminal envía una solicitud y muestra la respuesta. Una herramienta de pruebas evalúa esa respuesta y devuelve un veredicto que tu pipeline puede usar como compuerta de despliegue.
Busca estas cuatro capacidades:
-
Aserciones integradas: valida estados HTTP, encabezados y cuerpos sin depender de scripts improvisados con
jq. -
Códigos de salida útiles:
0para éxito y un valor distinto de cero para fallo. - Repetibilidad: pruebas guardadas en archivos o proyectos versionables, no en el historial del shell.
- Informes: salida legible en consola y formatos como JSON, JUnit o HTML para CI.
Con esos criterios, estas son diez herramientas prácticas para pruebas de API desde terminal.
1. Apidog CLI: crea visualmente y ejecuta sin interfaz gráfica
Apidog es una plataforma API que cubre diseño, pruebas, mocking y documentación. Su CLI, apidog-cli, permite ejecutar desde terminal los escenarios que creas en el editor visual.
El flujo de trabajo es:
- Crea un escenario con solicitudes encadenadas, variables y aserciones.
- Abre la pestaña CI/CD del escenario.
- Copia el comando generado.
- Ejecútalo localmente, en CI o desde un agente.
npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>
# Copia el comando exacto desde la pestaña CI/CD del escenario
apidog run -t <scenario_id> -e <env_id> -r cli
No necesitas adivinar IDs: Apidog genera el comando desde el escenario. Puedes usar los reporteros cli, html, json y junit; los archivos se escriben en apidog-reports/.
Para pruebas controladas por datos, usa archivos CSV o JSON como fuente de iteraciones. La salida JSON estructurada incluye agentHints.nextSteps, útil para agentes de IA que deben decidir el siguiente paso sin interpretar capturas de pantalla.
Ideal para: equipos que diseñan escenarios complejos visualmente y necesitan ejecutarlos de forma idéntica en local, CI y entornos automatizados.
Límite honesto: no es de código abierto ni está pensado como cliente HTTP ad hoc. Los escenarios viven en proyectos de Apidog.
Consulta la guía completa de Apidog CLI para ver todos los comandos.
2. Hurl: pruebas HTTP de texto plano
Hurl ejecuta solicitudes HTTP definidas en archivos de texto y evalúa aserciones sobre las respuestas. Está construido en Rust sobre libcurl y se distribuye como binario único.
Crea un archivo .hurl versionable:
brew install hurl
# Alternativa: cargo install --locked hurl
cat > login.hurl <<'EOF'
POST https://api.example.com/login
{ "user": "acme", "pass": "s3cret" }
HTTP 200
[Asserts]
jsonpath "$.token" exists
EOF
hurl --test login.hurl
Usa --test en CI: Hurl devuelve un código distinto de cero si falla una aserción.
Ideal para: pruebas de humo y verificaciones de contrato que quieres revisar como texto en una pull request.
Límite honesto: se centra en HTTP. No cubre gRPC ni generación de carga, y la lógica compleja suele dividirse en más archivos .hurl.
3. Newman: ejecuta colecciones de Postman sin GUI
Newman es el ejecutor de línea de comandos de código abierto para colecciones de Postman. Si ya tienes solicitudes y pruebas definidas en Postman, exporta la colección y el entorno como JSON para ejecutarlos desde CI.
npm install -g newman
newman run collection.json -e staging.json
Newman falla con código distinto de cero cuando una prueba no pasa, por lo que funciona directamente como compuerta de CI.
Ideal para: equipos que ya trabajan con colecciones de Postman y quieren automatizarlas sin añadir una interfaz gráfica al pipeline.
Límite honesto: ejecuta exclusivamente colecciones con formato Postman. La creación de pruebas sigue ocurriendo en la GUI de Postman.
4. Postman CLI: ejecución vinculada a la nube de Postman
La CLI de Postman es el ejecutor oficial de código cerrado de Postman. A diferencia de Newman, inicia sesión en una cuenta y puede ejecutar colecciones por ID directamente desde un espacio de trabajo.
postman login --with-api-key <YOUR_API_KEY>
postman collection run <collection_id> -e <environment_id>
Los resultados se reportan a la nube de Postman.
Ideal para: equipos que quieren ejecutar colecciones vinculadas a su espacio de trabajo sin exportar JSON.
Límite honesto: requiere una cuenta de Postman, es de código cerrado y coexistir con Newman puede generar dudas sobre cuál adoptar.
La comparación Postman CLI vs Newman explica cuándo conviene cada opción.
5. Bruno CLI: colecciones nativas de Git con bru
Bruno guarda colecciones como archivos .bru de texto plano en carpetas normales. Esto permite revisar solicitudes y pruebas en pull requests como cualquier otro archivo del repositorio.
Instala y ejecuta una colección:
npm install -g @usebruno/cli
# Ejecuta las solicitudes de la colección actual
bru run --env staging
Bruno CLI puede generar informes JSON, JUnit y HTML para CI.
Ideal para: equipos que quieren colecciones locales, revisables en Git y ejecutables sin una cuenta en la nube.
Límite honesto: el enfoque basado en archivos favorece a desarrolladores; el ecosistema es más joven que el de Postman.
Consulta Bruno CLI vs Apidog CLI para comparar ambos enfoques.
6. Schemathesis: genera pruebas desde tu esquema
Schemathesis lee un esquema OpenAPI o GraphQL y genera casos de prueba usando pruebas basadas en propiedades sobre Hypothesis para Python.
En lugar de definir cada entrada manualmente, ejecuta pruebas para descubrir:
- errores
500; - respuestas que incumplen el esquema;
- casos límite no cubiertos por pruebas manuales;
- violaciones del contrato documentado.
pip install schemathesis
schemathesis run https://api.example.com/openapi.json
Ideal para: APIs con una especificación sólida donde quieres encontrar errores inesperados antes de una versión.
Límite honesto: necesita un esquema real y preciso. En APIs grandes, puede producir resultados que tendrás que ajustar mediante opciones y hooks.
7. Step CI: flujos de varios pasos en YAML
Step CI permite describir un flujo de API en un archivo YAML. Puedes definir pasos, capturar valores y verificar respuestas sin escribir un script completo.
También cubre REST, GraphQL, gRPC, tRPC y SOAP, y puede validar contra esquemas OpenAPI.
npm install -g stepci
stepci run workflow.yml
Un caso típico es un flujo de autenticación:
- Iniciar sesión.
- Extraer el token.
- Usarlo en una solicitud posterior.
- Validar la respuesta final.
Ideal para: flujos declarativos de varios pasos sin scripting personalizado.
Límite honesto: requiere un entorno Node y su cadencia de lanzamientos se ha ralentizado. Revisa la actividad reciente del repositorio antes de basar un pipeline crítico en esta herramienta.
8. curl: la base que probablemente ya tienes
curl viene preinstalado en macOS, la mayoría de distribuciones Linux y versiones actuales de Windows. Es el cliente de referencia para solicitudes HTTP desde shell.
Puedes usarlo para una comprobación mínima de estado:
# Envía JSON e imprime solo el estado HTTP
curl -s -o /dev/null -w "%{http_code}\n" \
-X POST https://api.example.com/orders \
-H "Content-Type: application/json" \
-d '{"sku":"A-102","qty":2}'
Para convertirlo en una prueba, debes añadir la lógica tú mismo: capturar el código, compararlo y devolver un fallo cuando sea necesario.
Ideal para: solicitudes puntuales, scripts pequeños y entornos donde no puedes instalar herramientas adicionales.
Límite honesto: no incluye aserciones integradas. Necesitarás combinarlo con shell, jq y control manual de códigos de salida.
Cuando curl deja de ser suficiente, consulta estas alternativas a curl para pruebas de API REST.
9. HTTPie y xh: solicitudes manuales legibles
HTTPie simplifica las solicitudes manuales desde terminal. Usa http como comando y permite enviar campos JSON como pares clave=valor.
xh implementa una sintaxis similar en Rust como binario estático, con inicio rápido y una opción --curl para imprimir la solicitud equivalente de curl.
http POST api.example.com/users name=acme plan=pro
xh POST api.example.com/users name=acme plan=pro
Ideal para: explorar endpoints manualmente mientras construyes las pruebas automatizadas en otra herramienta.
Límite honesto: ambos son clientes, no ejecutores de pruebas. No realizan aserciones sobre la respuesta. HTTPie requiere Python; xh prioriza velocidad con un conjunto de características más reducido.
10. k6: cuando necesitas medir carga
k6 responde otra pregunta: no solo si una respuesta es correcta, sino si la API soporta tráfico bajo condiciones definidas.
Es un binario de Go programado con JavaScript. Puedes definir umbrales que convierten una prueba de carga en una compuerta de CI: si se supera un umbral, k6 devuelve un código distinto de cero.
brew install k6
k6 run load.js
Define VUs, duración y umbrales dentro del script load.js.
Ideal para: verificaciones de rendimiento versionadas junto con tus pruebas funcionales.
Límite honesto: es una herramienta de carga bajo AGPL-3.0, no un cliente de pruebas funcionales. Los escenarios significativos requieren aprender su API de JavaScript.
¿Prefieres algo interactivo?
Si quieres una interfaz tipo Postman dentro del shell, busca clientes TUI como atac y posting. Estos dibujan editores completos de solicitudes en la terminal, pero su objetivo es explorar APIs, no gestionar pipelines.
Consulta la guía de los mejores clientes API REST de terminal y TUI para profundizar en esa categoría.
Tabla comparativa
| Herramienta | Tarea | Aserciones integradas | Instalación | Código abierto |
|---|---|---|---|---|
| Apidog CLI | Ejecutar escenarios creados visualmente en CI | Sí | npm i -g apidog-cli |
No (capa gratuita) |
| Hurl | Pruebas HTTP de texto plano | Sí | brew install hurl |
Apache-2.0 |
| Newman | Colecciones de Postman sin interfaz gráfica | Sí | npm i -g newman |
Apache-2.0 |
| Postman CLI | Ejecuciones de Postman vinculadas a la nube | Sí | Instalador de Postman | No |
| Bruno CLI | Colecciones .bru nativas de Git |
Sí | npm i -g @usebruno/cli |
MIT |
| Schemathesis | Fuzzing a partir de un esquema | Generadas | pip install schemathesis |
MIT |
| Step CI | Flujos YAML de varios pasos | Sí | npm i -g stepci |
MPL-2.0 |
| curl | Solicitudes brutas y scripting | DIY | Preinstalado | Sí |
| HTTPie / xh | Solicitudes manuales legibles | No |
brew install httpie / xh
|
Sí |
| k6 | Carga con umbrales de éxito/fallo | Umbrales | brew install k6 |
AGPL-3.0 |
Cómo elegir
Empieza por el tipo de trabajo que necesitas automatizar:
- Ya tienes colecciones de Postman: usa Newman o Postman CLI.
- Quieres archivos de prueba legibles y revisables en Git: usa Hurl o Bruno CLI.
- Tienes una especificación OpenAPI precisa: añade Schemathesis para descubrir casos límite.
- Necesitas flujos declarativos de varios pasos: prueba Step CI.
- Solo necesitas una solicitud rápida o estás en un entorno restringido: usa curl.
- Quieres explorar manualmente una API: usa HTTPie o xh.
- Necesitas validar capacidad y rendimiento: usa k6.
- Quieres diseñar escenarios visualmente y ejecutarlos en CI: usa Apidog CLI.
La CLI de Apidog es útil cuando quieres mantener diseño de API, datos simulados, documentación y escenarios de prueba en una sola plataforma. Consulta Apidog CLI: el cliente API que vive en tu terminal para ver ese flujo de trabajo.
Para entender cómo encajan estas herramientas en una estrategia mayor, revisa la guía de estrategias de pruebas de API.
Preguntas frecuentes
¿Puedo probar APIs completamente desde la terminal?
Sí. Puedes crear pruebas como archivos con Hurl, Bruno o Step CI, o definirlas en un editor visual con Apidog o Postman. Después, ejecútalas sin interfaz gráfica con su CLI. Los ejecutores devuelven códigos de salida que CI puede interpretar.
¿Cuál es la diferencia entre un cliente API de terminal y una herramienta de prueba?
Un cliente como curl, HTTPie o xh envía solicitudes y muestra respuestas. Una herramienta de pruebas como Apidog CLI, Hurl o Newman aplica aserciones y devuelve un código distinto de cero cuando algo falla. Los clientes sirven para explorar; las herramientas de prueba actúan como compuertas.
¿Cuáles se ejecutan en pipelines de CI?
Todos los ejecutores de esta lista:
apidog run
hurl --test
newman run
postman collection run
bru run
schemathesis run
stepci run
k6 run
Todos pueden devolver un código distinto de cero en caso de fallo. Para un ejemplo práctico, consulta cómo ejecutar pruebas de Apidog CLI en GitHub Actions.
¿Alguna de estas herramientas maneja pruebas de carga?
Sí: k6 es la herramienta especializada en carga de esta lista. Sus umbrales permiten fallar una ejecución cuando se supera una latencia, tasa de errores u otra métrica definida. Las demás herramientas se centran principalmente en corrección funcional.
¿Necesito una especificación OpenAPI?
Solo Schemathesis la necesita para generar pruebas. En las demás herramientas, una especificación ayuda pero no es obligatoria. Apidog puede importar OpenAPI 3.x, Swagger 2.0 y colecciones de Postman; Step CI puede validar respuestas contra un esquema.
El patrón es simple: crea pruebas donde te resulte más cómodo, pero ejecuta esas pruebas desde un shell con un código de salida fiable. Si buscas diseño visual y ejecución automatizada en una sola plataforma, descarga Apidog, crea un escenario y añade apidog run a tu pipeline de CI.
Top comments (0)