La mayoría de los tutoriales de pruebas de API te dirigen a una interfaz gráfica de usuario (GUI). Pero si vives en la terminal, ejecutas pruebas en CI, o quieres una herramienta cuyo código fuente puedas leer, la línea de comandos es donde las pruebas de API se vuelven interesantes. Las herramientas CLI de código abierto te ofrecen algo que un producto alojado no puede: una licencia que puedes auditar, un binario que puedes auto-alojar y un archivo de configuración que puedes incluir junto a tu código.
Esta es una pregunta diferente a "¿cuál es la herramienta más rápida?" o "¿cuál es el binario más pequeño?". Aquí el enfoque es el licenciamiento y el control. ¿Puedes ejecutarlo dentro de tu propia red sin una cuenta? ¿El código fuente está en GitHub bajo una licencia real aprobada por la OSI? ¿Seguirá funcionando si el proveedor cambia los precios el próximo trimestre? Esas son las preguntas que esta lista responde.
A continuación, se presentan ocho herramientas CLI gratuitas y con código fuente disponible para probar APIs REST, GraphQL y HTTP, cada una con su licencia exacta, un comando de instalación real y un comando que muestra su funcionamiento. Si deseas una visión más amplia que incluya herramientas alojadas, consulta el resumen de las mejores herramientas gratuitas para pruebas de API. Para una perspectiva puramente centrada en la terminal para probar endpoints manualmente, la guía de alternativas a curl para pruebas de API REST cubre el lado interactivo.
Qué hace que una herramienta CLI sea "de código abierto" para las pruebas de API
Muchas herramientas son gratuitas para descargar. Eso no es lo mismo que código abierto. Para esta lista, una herramienta califica en tres puntos:
- Una licencia real. El código fuente es público bajo una licencia aprobada por la OSI (MIT, Apache-2.0, MPL-2.0, AGPL-3.0, BSD). Puedes leerlo, bifurcarlo y saber qué se te permite hacer.
- Auto-alojable, sin cuenta. Puedes ejecutar todo en tu propia máquina o en un ejecutor de CI sin necesidad de registrarte para nada. Sin costo por asiento, sin requisito de "llamar a casa".
- Mantenido e inspeccionable. El repositorio está en GitHub con historial de commits e incidencias visibles, para que puedas juzgar si está activo antes de construir una pipeline sobre él.
Cada herramienta a continuación cumple con los dos primeros puntos. He marcado la que ya no cumple con el tercero. La elección de la licencia importa más de lo que parece: AGPL-3.0 (k6) tiene obligaciones de copyleft si construyes un servicio alrededor de ella, mientras que MIT y Apache-2.0 son permisivas. Lee la licencia antes de incrustar una herramienta en un producto.
Hurl: pruebas HTTP de texto plano, un binario de Rust
Hurl ejecuta peticiones HTTP escritas en un formato de texto plano y realiza aserciones sobre las respuestas. Está construido por Orange-OpenSource en Rust, impulsado por libcurl internamente y distribuido como un único binario. Las pruebas se leen casi como las propias peticiones, lo que las hace fáciles de revisar en una solicitud de extracción.
Licencia: Apache-2.0. Fuente: github.com/Orange-OpenSource/hurl.
brew install hurl # o: cargo install --locked hurl
# login.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
Ideal para: comprobaciones de estilo de contrato y pruebas de humo que desees mantener en control de versiones como texto legible. Límite honesto: está enfocado en HTTP, por lo que no impulsará gRPC ni generará carga. Para cualquier cosa más allá de simples cadenas de aserción, escribirás más archivos `.hurl` en lugar de recurrir a un lenguaje de scripting.
Step CI: flujos de trabajo de API en YAML construidos para CI
Step CI es un ejecutor de flujos de trabajo configurado en YAML, diseñado para la integración continua. Cubre REST, GraphQL, gRPC, tRPC y SOAP en un único archivo de flujo de trabajo, y puede realizar pruebas de carga y validación contra un esquema OpenAPI. El ejecutor y la CLI son gratuitos para siempre.
Licencia: MPL-2.0. Fuente: github.com/stepci/stepci.
npm install -g stepci
# workflow.yml describe pasos, comprobaciones y capturas
stepci run workflow.yml
Ideal para: equipos que desean un único archivo declarativo que describa un flujo de API de varios pasos y lo ejecute de la misma manera localmente y en CI. Límite honesto: MPL-2.0 es un copyleft débil, por lo que si modificas los propios archivos de Step CI, debes compartir esos cambios. Usarlo para probar tu aplicación no conlleva tal obligación.Schemathesis: pruebas basadas en propiedades a partir de tu esquema
Schemathesis lee tu esquema OpenAPI o GraphQL y genera miles de casos de prueba a partir de él, utilizando pruebas basadas en propiedades construidas sobre la biblioteca Hypothesis de Python. En lugar de que escribas cada caso, difumina las entradas para encontrar errores 500, violaciones de esquema y respuestas que no coinciden con lo que prometen tus documentos.
Licencia: MIT. Fuente: github.com/schemathesis/schemathesis.
uv pip install schemathesis # o: pip install schemathesis
schemathesis run https://api.example.com/openapi.json
Ideal para: detectar errores de casos extremos para los que nunca pensarías en escribir una prueba, especialmente antes de un lanzamiento. Es una de las razones más sólidas para mantener un esquema preciso. Límite honesto: necesita un esquema real para funcionar, y una API grande puede producir mucho ruido que querrás filtrar con sus hooks y opciones.
Dredd: pruebas de contrato contra tu descripción de API
Dredd comprueba que tu API en vivo realmente coincide con su documento de descripción. Apúntalo a un archivo OpenAPI (o API Blueprint) y a un backend en ejecución, y reproducirá cada solicitud documentada y comparará la respuesta real con la especificación. Es agnóstico al lenguaje y soporta hooks para la configuración y desmantelamiento.
Licencia: MIT. Fuente: github.com/apiaryio/dredd.
npm install -g dredd
dredd apiary.apib http://127.0.0.1:3000
Ideal para: demostrar que tu documentación y tu implementación no se han separado. Límite honesto, y es uno real: el repositorio de Dredd fue archivado en noviembre de 2024 y es de solo lectura. Todavía funciona, pero ya no se mantiene, así que trátalo como una herramienta estable sin futuras correcciones. Si quieres un verificador impulsado por esquemas mantenido activamente, Schemathesis es la opción más segura.
k6: pruebas de carga programadas en JavaScript
k6 es la herramienta de pruebas de carga y rendimiento de Grafana. Programas las pruebas en JavaScript o TypeScript, y un rápido motor Go las ejecuta a escala. Es la opción de código abierto preferida cuando necesitas saber cómo se comporta tu API bajo cientos o miles de usuarios virtuales, no solo si una sola solicitud pasa.
Licencia: AGPL-3.0. Fuente: github.com/grafana/k6.
brew install k6
k6 new script.js # genera una prueba de inicio
k6 run script.js
Ideal para: pruebas de rendimiento y de resistencia que residen en el mismo repositorio que tus pruebas funcionales. Límite honesto: AGPL-3.0 es un copyleft fuerte. Esto está bien para ejecutar pruebas, pero si construyes y distribuyes un servicio alrededor del código de k6, la licencia tiene obligaciones reales; léela primero. k6 también se centra en la carga, no en aserciones de contrato detalladas.
Newman: ejecuta colecciones de Postman sin la GUI
Newman es el propio ejecutor de colecciones de línea de comandos de Postman. Si tu equipo ya tiene peticiones y pruebas de API guardadas como una colección de Postman, Newman ejecuta esa colección exacta desde la terminal o en CI, sin necesidad de una aplicación de escritorio. Es la forma estándar de integrar un flujo de trabajo de Postman en una pipeline.
Licencia: Apache-2.0. Fuente: github.com/postmanlabs/newman.
npm install -g newman
newman run my-collection.json -e staging-environment.json
Ideal para: equipos con colecciones de Postman existentes que desean ejecutar CI sin pagar por asientos adicionales de Postman. Límite honesto: está ligado al formato de colección de Postman, por lo que las pruebas se redactan en la interfaz de usuario de Postman (o su JSON) en lugar de en un archivo de configuración simple. Ejecuta colecciones; no diseña ni simula APIs.
Tavern: pruebas de API como un plugin de pytest
Tavern es una biblioteca de Python, CLI y plugin de pytest que describe pruebas de API en YAML. Debido a que se integra con pytest, obtienes todo el ecosistema de pytest de forma gratuita: fixtures, informes, paralelismo e integraciones de CI que quizás ya utilices. Maneja REST, MQTT y gRPC.
Licencia: MIT. Fuente: github.com/taverntesting/tavern.
pip install tavern
# test_login.tavern.yaml se encuentra junto a tus otras pruebas
pytest test_login.tavern.yaml
Ideal para: empresas Python que ya ejecutan pytest y quieren que las pruebas de API vivan junto a las pruebas unitarias. Límite honesto: asume que te sientes cómodo en una configuración de pruebas de Python. Si tu stack no es Python, la dependencia de pytest es una fricción en lugar de una característica.
Venom: pruebas de integración multi-ejecutor de OVHcloud
Venom, de OVHcloud, ejecuta pruebas de integración en muchos tipos de ejecutores: peticiones HTTP, scripts de shell, IMAP, web, bases de datos y más. Está escrito en Go, utiliza suites de pruebas YAML y emite archivos de resultados xUnit que los sistemas de CI leen de forma nativa. Destaca cuando una sola prueba necesita interactuar con más que solo un endpoint HTTP.
Licencia: BSD (modificada). Fuente: github.com/ovh/venom.
# descarga el binario de los lanzamientos de GitHub, luego:
venom run testsuite.yml
Ideal para: flujos de extremo a extremo que mezclan una llamada a la API con una verificación de base de datos o un paso de script en una suite de pruebas. Límite honesto: con tantos ejecutores, el YAML se vuelve verboso, y la documentación asume que armarás ejemplos del repositorio.
Dónde encaja Apidog (y una nota honesta)
Aquí está la parte honesta. Apidog no es de código abierto. Es un producto comercial con un nivel gratuito, por lo que no pertenece a una lista de herramientas con código fuente disponible. Pero vale la pena conocerlo por una razón: las herramientas anteriores hacen cada una un trabajo, y unir Hurl más Schemathesis más Newman más un servidor simulado en un flujo de trabajo coherente es un trabajo real que debes mantener tú mismo.
Apidog integra el diseño, las pruebas, la simulación y la documentación en una sola plataforma, y apidog-cli lleva el lado de las pruebas a la terminal. Creas escenarios de prueba una vez, y luego los ejecutas en CI con un solo comando:
npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>
apidog run --access-token <TOKEN> # sale con 0 si todo pasa, distinto de 0 en caso de fallo
La salida es JSON estructurado con `agentHints.nextSteps`, lo que facilita la creación de scripts o su entrega a un agente de IA. La guía completa de apidog-cli recorre el conjunto completo de comandos. Así que: no es de código abierto, pero el nivel gratuito más la CLI te ofrecen una alternativa integrada para conectar varias herramientas de propósito único. Si una licencia que puedas auditar es un requisito estricto, elige entre las ocho anteriores. Si un flujo de trabajo integrado importa más, este es el compromiso.
Cómo elegir
| Herramienta | Mejor para | Instalación | ¿Código abierto? | Licencia |
|---|---|---|---|---|
| Hurl | Aserciones HTTP de texto plano en Git | brew install hurl |
Sí | Apache-2.0 |
| Step CI | Flujos de trabajo de CI declarativos | npm i -g stepci |
Sí | MPL-2.0 |
| Schemathesis | Fuzzing basado en propiedades desde un esquema | pip install schemathesis |
Sí | MIT |
| Dredd | Pruebas de contrato entre docs e implementación | npm i -g dredd |
Sí (archivado) | MIT |
| k6 | Pruebas de carga y rendimiento | brew install k6 |
Sí | AGPL-3.0 |
| Newman | Ejecutar colecciones de Postman en CI | npm i -g newman |
Sí | Apache-2.0 |
| Tavern | Pruebas de API dentro de pytest | pip install tavern |
Sí | MIT |
| Venom | Suites de integración multi-ejecutor | Lanzamientos de GitHub | Sí | BSD |
| apidog-cli | Flujo de trabajo integrado de diseño a prueba | npm i -g apidog-cli |
No (nivel gratuito) | Comercial |
Adapta la herramienta al trabajo. Opta por Hurl o Newman cuando quieras comprobaciones de solicitudes rápidas y legibles; Schemathesis cuando tengas un esquema y quieras que se encuentren errores por ti; k6 cuando la cuestión sea la escala; Tavern o Venom cuando las pruebas necesiten vivir en una suite más grande. Si estás comparando esto con un proceso más grande, la guía de estrategias de prueba de API cubre dónde encaja cada tipo, y el artículo sobre herramientas de prueba de API sin interfaz gráfica examina la ejecución de pruebas sin ninguna UI.
Conclusión
Las herramientas CLI de código abierto te brindan pruebas de API que puedes leer, bifurcar y ejecutar bajo tus propios términos. Hurl y Newman manejan las comprobaciones diarias de solicitudes, Schemathesis y Dredd hacen cumplir tu contrato, k6 impulsa el rendimiento, y Tavern y Venom integran las pruebas de API en suites más amplias. Elige por licencia y por el trabajo específico que necesitas hacer; nada te impide ejecutar dos de ellas.
Cuando prefieres diseñar, probar, simular y documentar en un solo lugar en lugar de mantener una cadena de herramientas, Apidog cubre todo el ciclo de vida y ofrece `apidog-cli` para CI. Descarga Apidog para probar la CLI junto con las herramientas anteriores y ver qué combinación se adapta a tu pipeline.
