Tavern es una pieza de ingeniería inteligente. Se integra con pytest, permite describir una prueba de API como un archivo YAML y ejecuta ese archivo como si fuera una prueba pytest normal. Obtienes todo el ecosistema de pytest de forma gratuita: fixtures, plugins, ejecuciones paralelas con pytest-xdist, cobertura, el mismo comando que tu equipo de Python ya usa. Para un equipo de backend que vive en pytest, escribir un test_*.tavern.yaml más junto a las pruebas unitarias se siente natural.
La fricción aparece una vez que el YAML crece. Una sola solicitud que envía un cuerpo, guarda un token y verifica algunos campos de respuesta se convierte en un bloque anidado de claves request, response, save y verify_response_with que debes identar exactamente bien. Los flujos de varias etapas (iniciar sesión, crear un recurso, leerlo, eliminarlo) apilan esos bloques en un archivo largo donde un espacio mal colocado rompe el análisis y el contrato de la API que la prueba verifica reside en otro lugar completamente diferente: un archivo Swagger, una página wiki, una colección de Postman que quedó desactualizada hace meses.
Lo que Tavern hace bien
Empecemos por el crédito, porque Tavern se lo gana.
Se basa en pytest en lugar de reemplazarlo. Tavern es un plugin de pytest. Lo instalas con pip install tavern, colocas un archivo YAML en tu directorio de pruebas, y pytest lo descubre y lo ejecuta como cualquier otra prueba. Esto significa que mantienes todos los hábitos de pytest que tu equipo ya tiene: -k para filtrar, -x para detenerse en el primer fallo, pytest-html para informes, pytest-xdist para ejecuciones paralelas, fixtures para una configuración compartida. Nada de tu runner cambia. Para una empresa de Python, esto es una verdadera ventaja, y pocas herramientas de prueba de API se integran tan limpiamente con una suite existente.
El YAML es declarativo y legible. Una prueba sencilla de Tavern es realmente fácil de escanear:
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
Sin código de unión, sin biblioteca de aserciones que importar, sin arnés de pruebas que escribir. La solicitud y la respuesta esperada se encuentran una al lado de la otra. Para verificar un código de estado y un par de campos, esto se lee mejor que el equivalente de requests más assert en Python.
Guardado y encadenamiento de variables. Tavern puede extraer un valor de una respuesta e inyectarlo en la siguiente etapa con save y la sustitución de {variable}, por lo que un flujo de inicio de sesión y luego llamada funciona sin código personalizado:
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
Hace más que HTTP. Tavern también prueba MQTT, lo cual es importante si trabajas con IoT o sistemas basados en mensajes. Y como está bajo pytest, puedes mezclar pruebas de API YAML y pruebas de Python regulares en la misma ejecución y el mismo informe.
Nada de esto es marketing. Tavern es una herramienta sólida. La pregunta es si sus suposiciones coinciden con las tuyas.
Donde el código repetitivo YAML se acumula
Tres costos vienen incluidos con el modelo de Tavern, y su importancia depende de cuán grande se vuelva tu suite.
YAML distingue los espacios en blanco, y el esquema es profundo. El ejemplo simple anterior es limpio. Una prueba realista no lo es. Una vez que añades encabezados, parámetros de consulta, un cuerpo de solicitud, aserciones de cuerpo de respuesta, comprobaciones de tipo, variables guardadas y funciones externas verify_response_with, te encuentras anidando cuatro o cinco niveles de profundidad en un formato donde un espacio incorrecto es un error de análisis, no un mensaje claro. Los editores no autocompletan las claves de Tavern como un IDE autocompleta un método de Python, así que tienes que consultar la documentación para saber si es status_code o status, json o body, en cada nuevo campo.
La prueba y el contrato de la API son dos artefactos separados. Tu YAML de Tavern codifica la URL, el método, los campos esperados y sus tipos. La definición real de la API reside en un archivo OpenAPI, en los decoradores de rutas de un framework, o nadie está seguro de dónde. Cuando la API cambia el nombre de un campo, nada se lo dice al YAML. La prueba sigue afirmando la forma antigua hasta que falla en CI o, peor aún, sigue pasando contra una expectativa obsoleta. Alguien tiene que mantener ambos sincronizados manualmente, y ese alguien suele ser la persona que recibe la notificación de fallo a las 2 de la mañana.
Asume una cadena de herramientas de Python y gente de Python. Tavern es excelente si tus testers escriben en Python. Si tu grupo de QA, tus ingenieros frontend o tu personal de producto quieren añadir o leer una prueba, se encuentran con pip, virtualenvs, convenciones de pytest y reglas de esquema YAML, todo a la vez, solo para enviar una solicitud HTTP y verificar una respuesta. La curva de aprendizaje es pronunciada para cualquiera fuera del mundo de Python.
El camino para saltarse el YAML
La alternativa es dejar de crear pruebas como archivos de texto y empezar a construirlas a partir de la definición de API que ya tienes.
En Apidog, la especificación de la API, la solicitud y la prueba son el mismo objeto. Importas o diseñas tu API una vez (importaciones de OpenAPI, Swagger o una colección de Postman con un clic), y cada endpoint lleva consigo su esquema real. Construyes un escenario de prueba encadenando esos endpoints visualmente: arrastra la llamada de inicio de sesión, arrastra la llamada que necesita el token y pasa el valor sin escribir bloques save: o cadenas {variable} a mano. Las aserciones son casillas de verificación y expresiones en un panel, no claves YAML indentadas que tengas que recordar.
Dado que la prueba se construye a partir de la especificación, esta es la única fuente de verdad. Si cambias un campo de respuesta en el diseño, los escenarios de prueba que lo referencian reflejan el cambio en lugar de desviarse silenciosamente. Esa es la parte que Tavern estructuralmente no puede hacer: su YAML no tiene un vínculo con el contrato.
Y cuando llega el momento de automatizar, no pierdes la propiedad sin interfaz gráfica y compatible con CI que hizo atractivo a Tavern. El Apidog CLI ejecuta esos mismos escenarios desde la línea de comandos, en CI, sin GUI, exactamente de la misma manera que pytest ejecuta tus archivos Tavern hoy.
Instalación y ejecución de Apidog CLI
El ejecutor es un paquete npm gratuito llamado apidog-cli. Instálalo globalmente:
npm install -g apidog-cli
Luego, ejecuta un escenario de prueba con el comando apidog run:
apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 -r cli
Esto es lo que hace cada parte:
--access-tokenautentica la ejecución con tu cuenta de Apidog. Genera el token desde la pestaña CI/CD del escenario y guárdalo como un secreto, nunca en el archivo.-tes el ID del escenario de prueba.-ees el ID del entorno (dev, staging, prod), para que el mismo escenario apunte a la URL base y variables correctas.-relige los reporteros.cliimprime una salida legible en la terminal.
No tienes que memorizar esos IDs. Abre el escenario de prueba en Apidog, cambia a su pestaña CI/CD, elige la opción de línea de comandos y haz clic en 'Generar token'. Apidog construye el comando completo apidog run para ti con el ID del escenario y el ID del entorno ya completados. Cópialo, luego mueve el token a un secreto de CI.
Si prefieres no instalar globalmente, especialmente en un ejecutor de CI efímero, ejecútalo con npx:
npx apidog-cli run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 -r cli
Los reporteros cubren cli, html, json y junit. Para CI, la combinación útil es -r html,junit: junit emite el XML estándar que casi todos los paneles de CI analizan en un árbol de aprobado/fallido, y html produce un informe navegable que puedes archivar como un artefacto de compilación. Añade --out-dir para controlar dónde se guardan:
apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 -r html,junit --out-dir ./apidog-reports
Para la lista completa de banderas en tu versión instalada, ejecuta 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 (paquete npm) |
| Autoría | Escribir e identar YAML a mano | Arrastrar y encadenar endpoints, aserciones con casillas de verificación |
| 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} |
Pasar valores entre pasos en la interfaz de usuario |
| Reporteros | pytest-html, JUnit a través de plugins de pytest |
cli, html, json, junit integrados |
| Quién puede escribir pruebas | Testers cómodos con Python | Cualquiera del equipo, incluidos los no programadores |
| Protocolos | HTTP y MQTT | HTTP, además de SOAP, WebSocket, gRPC y más |
Tavern gana si tu equipo está totalmente enfocado en Python y quieres que las pruebas residan en el mismo repositorio y la misma ejecución de pytest que tus pruebas unitarias. Apidog gana si quieres eliminar el mantenimiento de YAML, mantener el contrato y la prueba como una sola cosa, y permitir que personas que no escriben Python contribuyan con pruebas.
Integrándolo en CI
La ejecución sin interfaz gráfica es el objetivo principal de pasar de un archivo de prueba local a una pipeline. Así es como se ve en 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
El token proviene de los secretos del repositorio y llega al paso como una variable de entorno. El if: always() en el paso de carga significa que aún obtendrás el informe cuando las pruebas fallen, que es exactamente cuando querrás leerlo. Si una aserción falla, el paso apidog run sale con un código distinto de cero, el trabajo se marca en rojo y la pull request muestra una verificación fallida.
Ese comportamiento de código de salida es la puerta de calidad, y funciona de la misma manera que el de Tavern: CI lee el código de salida de cada paso, una salida no nula falla el trabajo, y un trabajo fallido bloquea la fusión o el despliegue. No configuras nada extra. Para configuraciones de pipeline más profundas, Apidog CLI en tu pipeline de CI/CD y el recorrido de GitHub Actions también cubren variantes de GitLab CI y Jenkins.
Una nota sobre pytest y el mundo más amplio de las pruebas en Python
Abandonar el YAML de Tavern no significa abandonar pytest. Muchos equipos mantienen sus pruebas unitarias y de integración de Python puro en pytest y usan Apidog para la capa de pruebas de contrato de API, la parte donde la prueba debe seguir la especificación y ejecutarse también para colaboradores que no son de Python. Los dos no son mutuamente excluyentes. El valor de Tavern siempre fue permitir a la gente de pytest escribir pruebas de API en un formato más ligero que el código requests puro; el valor de Apidog es hacer que esas pruebas de API sigan el contrato y permanezcan legibles a medida que la suite crece más allá de un puñado de archivos.
Si también estás considerando otros runners, la misma lógica se aplica a la historia de línea de comandos de Postman en Postman CLI vs Newman y a la ejecución de colecciones sin herramientas adicionales en pruebas de API sin Postman.
Preguntas Frecuentes
¿Es gratuito el Apidog CLI? Sí. El paquete npm apidog-cli es gratuito para instalar y ejecutar con npm install -g apidog-cli. Ejecuta los escenarios de prueba de tu proyecto Apidog, por lo que lo que puedes ejecutar depende de tu plan de Apidog, pero el propio ejecutor de línea de comandos no es un producto de pago separado.
¿Puedo seguir usando pytest junto con Apidog? Sí. Mantén tus pruebas unitarias y de integración de Python en pytest y usa Apidog para la capa de pruebas de contrato de API. Muchos equipos ejecutan ambos. La diferencia es que las pruebas de Apidog siguen la especificación en lugar de codificarla rígidamente en un archivo separado.
¿Cómo bloquea Apidog una fusión incorrecta en CI? A través del código de salida. Cuando cualquier aserción falla, apidog run sale con un código distinto de cero. CI lee ese código de salida, marca el paso como fallido y bloquea la fusión o el despliegue. No necesitas configurar nada adicional para que esto funcione.
¿Qué reportero debo usar para CI? Usa junit para el resultado legible por máquina que tu panel de CI analiza en un árbol de aprobado/fallido, y añade html si quieres un informe navegable guardado como un artefacto. Una opción común es -r html,junit, manteniendo cli para una salida de registro de compilación legible.
¿Apidog solo prueba HTTP, como el modo HTTP de Tavern? No. Apidog cubre HTTP además de SOAP, WebSocket, Server-Sent Events y gRPC. Tavern añade MQTT a HTTP, que es el único lugar donde su cobertura de protocolos va más allá de la de Apidog, así que tenlo en cuenta si MQTT es central para tu pila tecnológica.
La conclusión honesta
Tavern es una forma limpia de escribir pruebas de API si ya piensas en pytest y YAML, y la integración con pytest es genuinamente su mejor característica. El costo es el propio YAML: se vuelve profundo y frágil a medida que las suites escalan, y no tiene un vínculo con el contrato de API que verifica. Si quieres el mismo comportamiento sin interfaz gráfica, que falle ruidosamente en CI, sin identar YAML a mano y sin mantener una segunda copia de tu especificación, construir pruebas contra el contrato y ejecutarlas con apidog run es el camino más ligero.
Descarga Apidog e importa una API existente para experimentar el flujo de trabajo 'la especificación es la prueba' antes de comprometerte. Es gratis empezar.