Tavern encaja muy bien si tu equipo ya vive en pytest: instalas el plugin, escribes pruebas de API en YAML y las ejecutas con el mismo comando que usas para tus tests de Python. El problema aparece cuando esos archivos crecen: login, tokens, recursos encadenados, validaciones de respuesta y variables guardadas terminan convirtiéndose en YAML profundo, frágil y difícil de mantener.
Lo que Tavern hace bien
Tavern merece crédito: resuelve bien el caso de uso de pruebas de API declarativas dentro de un stack Python.
1. Se integra con pytest
Tavern es un plugin de pytest. Lo instalas, colocas un archivo *.tavern.yaml en tu carpeta de tests y pytest lo descubre como cualquier otra prueba.
pip install tavern
pytest
Eso significa que puedes seguir usando:
pytest -kpara filtrar pruebas.
pytest -xpara detenerte en el primer fallo.
pytest-xdistpara ejecución paralela.
pytest-htmlo reportes JUnit mediante plugins.- Fixtures de pytest para configuración compartida.
Para equipos backend centrados en Python, esto es una ventaja real.
2. El YAML es legible para casos simples
Una prueba básica de Tavern se entiende rápido:
test_name: Get a single order
stages:
- name: Fetch order 1042
request:
url: https://api.shop.test/orders/1042
method: GET
response:
status_code: 200
json:
id: 1042
status: shipped
La solicitud y la respuesta esperada están juntas. Para validar un status_code y algunos campos, esto puede ser más claro que escribir una prueba completa con requests y assert.
3. Permite guardar y reutilizar variables
Tavern también soporta flujos de varias etapas. Puedes extraer un valor de una respuesta con save y usarlo después con {variable}:
stages:
- name: Log in
request:
url: https://api.shop.test/auth/login
method: POST
json:
username: tester
password: hunter2
response:
status_code: 200
save:
json:
token: access_token
- name: Read the profile with the saved token
request:
url: https://api.shop.test/me
method: GET
headers:
Authorization: "Bearer {token}"
response:
status_code: 200
Esto cubre flujos comunes como:
- Iniciar sesión.
- Guardar un token.
- Usar el token en una llamada posterior.
- Validar la respuesta.
4. No se limita a HTTP
Tavern también puede probar MQTT, algo útil en sistemas IoT o arquitecturas basadas en mensajes. Además, al ejecutarse dentro de pytest, puedes mezclar pruebas YAML de API con pruebas Python tradicionales en la misma ejecución.
Tavern es una buena herramienta. La pregunta práctica es si su modelo escala bien para tu equipo.
Dónde se acumula la fricción con YAML
El costo de Tavern aparece cuando pasas de pruebas pequeñas a una suite real.
1. YAML es sensible a la indentación
El ejemplo simple es limpio. Pero una prueba real suele incluir:
- Headers.
- Query params.
- Body de solicitud.
- Validaciones del body de respuesta.
- Variables guardadas.
- Validaciones externas con
verify_response_with. - Fixtures o configuración compartida.
El resultado puede terminar con varios niveles de anidación:
stages:
- name: Create order
request:
url: https://api.shop.test/orders
method: POST
headers:
Authorization: "Bearer {token}"
Content-Type: application/json
json:
product_id: 123
quantity: 2
response:
status_code: 201
json:
status: created
save:
json:
order_id: id
Un espacio mal colocado rompe el parser. Además, el editor no siempre autocompleta las claves específicas de Tavern como un IDE autocompleta métodos de Python. Tienes que recordar si corresponde usar status_code, json, save, verify_response_with, etc.
2. La prueba y el contrato de API viven separados
En Tavern, el YAML contiene el método, la URL, los campos esperados y las validaciones. Pero el contrato real de la API suele vivir en otro lugar:
- Un archivo OpenAPI.
- Una especificación Swagger.
- Decoradores del framework backend.
- Una wiki.
- Una colección de Postman.
Cuando cambia un campo en la API, el YAML no se actualiza automáticamente. Alguien debe mantener sincronizados ambos artefactos.
Ese mantenimiento manual suele fallar en suites grandes.
3. Depende de un stack Python
Tavern funciona muy bien para testers y developers cómodos con Python. Pero si QA, frontend o producto quieren revisar o añadir pruebas, tienen que entender al mismo tiempo:
pip.- Entornos virtuales.
- Convenciones de
pytest. - Estructura YAML.
- Esquema específico de Tavern.
Para equipos mixtos, esa barrera puede limitar la colaboración.
El camino para saltarse el YAML
Una alternativa es no escribir pruebas como archivos YAML separados, sino construirlas desde la especificación de API que ya tienes.
En Apidog, la especificación, la solicitud y la prueba forman parte del mismo flujo. Puedes importar o diseñar la API una vez usando OpenAPI, Swagger o una colección de Postman, y después crear escenarios de prueba a partir de esos endpoints.
El flujo práctico es:
- Importa o define tu API en Apidog.
- Crea un escenario de prueba.
- Añade los endpoints en orden.
- Encadena valores entre pasos, como tokens o IDs.
- Configura aserciones desde la interfaz.
- Ejecuta el escenario localmente o en CI con
apidog run.
La diferencia principal es que no mantienes una segunda copia del contrato en YAML. La prueba se construye alrededor de la especificación.
Cuando necesitas automatizar, puedes ejecutar esos mismos escenarios sin interfaz gráfica con Apidog CLI, de forma similar a como ejecutarías Tavern con pytest.
Instalación y ejecución de Apidog CLI
El runner es un paquete npm llamado apidog-cli.
Instálalo globalmente:
npm install -g apidog-cli
Luego ejecuta un escenario:
apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 -r cli
Qué significa cada opción:
--access-token: autentica la ejecución. Guárdalo como secreto de CI, no en el repositorio.
-t: ID del escenario de prueba.
-e: ID del entorno, por ejemplodev,stagingoprod.
-r: reportero de salida.cliimprime resultados en la terminal.
No necesitas memorizar los IDs. En Apidog:
- Abre el escenario de prueba.
- Ve a la pestaña CI/CD.
- Elige la opción de línea de comandos.
- Genera el token.
- Copia el comando generado.
- Mueve el token a un secreto de CI.
Si prefieres no instalar el paquete globalmente, usa npx:
npx apidog-cli run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 -r cli
Para CI, suele ser útil generar reportes HTML y JUnit:
apidog run \
--access-token $APIDOG_ACCESS_TOKEN \
-t 605067 \
-e 1629989 \
-r html,junit \
--out-dir ./apidog-reports
Reporteros disponibles:
clihtmljsonjunit
Para ver las opciones disponibles en tu versión instalada:
apidog run --help
Comparativa
| Tavern | Apidog | |
|---|---|---|
| Formato de prueba | Archivos YAML (*.tavern.yaml) | Escenarios visuales construidos a partir de la especificación |
| Tiempo de ejecución | Python + pytest | apidog run sin interfaz gráfica mediante paquete npm |
| Autoría | Escribir e indentar YAML a mano | Encadenar endpoints y configurar aserciones desde la interfaz |
| Contrato de API | Artefacto separado, sincronizado manualmente | La especificación es la fuente de verdad de la prueba |
| Encadenamiento de variables | Bloques save: y sustitución de {var} | Paso de valores entre pasos en la interfaz |
| Reporteros | pytest-html, JUnit mediante plugins de pytest | cli, html, json, junit integrados |
| Quién puede escribir pruebas | Testers cómodos con Python | Miembros del equipo, incluidos perfiles no centrados en Python |
| Protocolos | HTTP y MQTT | HTTP, además de SOAP, WebSocket, gRPC y más |
Tavern gana si tu equipo está completamente orientado a Python y quieres mantener las pruebas de API dentro del mismo repositorio y ejecución de pytest.
Apidog gana si quieres reducir el mantenimiento de YAML, mantener contrato y prueba conectados, y facilitar que más personas del equipo contribuyan a las pruebas.
Integrándolo en CI
Este es un ejemplo completo con GitHub Actions:
name: Pruebas de API
on: [push, pull_request]
jobs:
api-tests:
runs-on: ubuntu-latest
steps:
- name: Instalar Apidog CLI
run: npm install -g apidog-cli
- name: Ejecutar escenario de prueba de API
run: |
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-t 605067 \
-e 1629989 \
-r html,junit \
--out-dir apidog-reports
env:
APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}
- name: Subir informe
if: always()
uses: actions/upload-artifact@v4
with:
name: apidog-report
path: apidog-reports
Puntos importantes:
- El token se guarda en
secrets.APIDOG_ACCESS_TOKEN.
apidog runfalla con código distinto de cero si falla una aserción.- CI marca el job como fallido.
- La pull request queda bloqueada si tu configuración exige checks en verde.
if: always()permite subir el reporte incluso cuando las pruebas fallan.
Ese comportamiento es el mismo patrón que ya usas con otros runners: el código de salida actúa como puerta de calidad.
Para pipelines más completas, revisa Apidog CLI en tu pipeline de CI/CD y el recorrido de GitHub Actions, que también cubren variantes con GitLab CI y Jenkins.
Una nota sobre pytest
Dejar de escribir YAML de Tavern no significa abandonar pytest.
Muchos equipos mantienen:
- Pruebas unitarias en
pytest. - Pruebas de integración Python en
pytest. - Pruebas de contrato de API en Apidog.
Ese enfoque separa responsabilidades:
pytestsigue siendo ideal para lógica interna de Python.- Apidog cubre escenarios de API basados en la especificación.
- CI ejecuta ambos como puertas de calidad.
Si quieres profundizar en el lado Python, puedes revisar esta guía sobre pytest para pruebas automatizadas de API.
Si también estás comparando runners de línea de comandos, revisa Postman CLI vs Newman y esta guía sobre pruebas de API sin Postman.
Preguntas frecuentes
¿Apidog CLI es gratuito?
Sí. El paquete npm apidog-cli es gratuito para instalar y ejecutar:
npm install -g apidog-cli
Ejecuta escenarios de prueba de tu proyecto Apidog. Lo que puedes ejecutar depende de tu plan de Apidog, pero el runner de línea de comandos no es un producto de pago separado.
¿Puedo seguir usando pytest junto con Apidog?
Sí. Puedes mantener tus pruebas unitarias y de integración en pytest y usar Apidog para pruebas de contrato de API. No son opciones excluyentes.
¿Cómo bloquea Apidog una fusión incorrecta en CI?
Mediante el código de salida. Si una aserción falla, apidog run sale con un código distinto de cero. CI interpreta ese resultado como fallo y bloquea la fusión o el despliegue según tus reglas.
¿Qué reportero debo usar en CI?
Usa junit si quieres que tu CI lea resultados estructurados. Añade html si quieres un reporte navegable como artefacto.
Ejemplo recomendado:
apidog run \
--access-token $APIDOG_ACCESS_TOKEN \
-t 605067 \
-e 1629989 \
-r html,junit \
--out-dir ./apidog-reports
¿Apidog solo prueba HTTP?
No. Apidog cubre HTTP, SOAP, WebSocket, Server-Sent Events y gRPC. Tavern añade MQTT a HTTP, así que si MQTT es central en tu stack, considéralo dentro de la evaluación.
Conclusión
Tavern es una opción sólida si ya trabajas con pytest y quieres describir pruebas de API en YAML. Su integración con pytest es su mayor fortaleza.
El costo aparece cuando la suite crece: más indentación, más bloques save, más duplicación del contrato y más mantenimiento manual.
Si quieres ejecutar pruebas de API en CI sin interfaz gráfica, pero sin mantener YAML separado de la especificación, puedes construir los escenarios desde el contrato y ejecutarlos con apidog run.
Descarga Apidog e importa una API existente para probar el flujo donde la especificación y la prueba permanecen conectadas.
SOCIAL SHARE CARD GENERATOR