Cómo Programar Pruebas de API Automatizadas en Apidog (Nube, Runner y CLI)

Un conjunto de pruebas que pasa solo aporta valor si sigue pasando. Su flujo de pago puede funcionar hoy, pero una dependencia puede introducir un cambio disruptivo a las 2 a.m., un certificado puede caducar durante el fin de semana o una desviación de configuración puede desactivar el endpoint de pagos un domingo. Si descubre el problema por un cliente molesto en lugar de por una ejecución automática, está llegando tarde. La solución es simple: ejecute pruebas de API según una programación y reciba una alerta en cuanto falle algo.

Prueba Apidog hoy

Apidog incluye Tareas Programadas para ejecutar escenarios de prueba ya definidos, establecer una cadencia, seleccionar una máquina de ejecución y configurar alertas. Si es nuevo en las comprobaciones desatendidas contra endpoints activos, consulte esta introducción a la monitorización de API y la documentación de Tareas Programadas de Apidog.

La función de Tareas Programadas está marcada como Beta. Además, el número de ejecuciones programadas disponibles depende de su plan.

Qué hacen las tareas programadas

Una tarea programada ejecuta uno o más Escenarios de Prueba guardados en un ciclo recurrente. Casos habituales:

• Regresión nocturna sobre la API principal.
• Prueba de humo cada pocas horas en staging.
• Comprobación de salud durante el fin de semana.
• Validación posterior a un despliegue.

La tarea conserva estos elementos:

1. Los escenarios que debe ejecutar.
2. El entorno de destino.
3. La frecuencia de ejecución.
4. El Runner que realizará las solicitudes.
5. Los canales de notificación ante fallos.

No confunda esta función con tareas programadas de scraping. Aquí no configura selectores ni reglas de rastreo: ejecuta escenarios de prueba de API existentes, incluidas aserciones, solicitudes encadenadas y variables extraídas. El resultado es un informe de aprobación o fallo de su contrato de API.

Antes de empezar: configure un Runner autohospedado

Para ejecutar tareas programadas, primero debe registrar un Runner autohospedado.

El Runner es la máquina que ejecuta la suite. Cuando se activa una tarea, Apidog no envía las solicitudes desde su cliente de escritorio: entrega el trabajo al Runner seleccionado. Puede utilizar:

• Un agente de CI.
• Un servidor siempre encendido.
• Una máquina virtual dedicada.
• Una máquina dentro de la misma VPC que su API.

La máquina debe permanecer disponible durante las horas programadas.

Actualmente, el selector de destino muestra dos opciones:

• Apidog Cloud: marcado como “próximamente”.
• Runner autohospedado: opción disponible actualmente.

Como las solicitudes salen desde la red del Runner, su ubicación afecta los resultados. Por ejemplo, un Runner detrás de una VPN corporativa, en otra región o dentro de una subred con firewall puede recibir respuestas distintas a las de su portátil. Para monitorización realista, normalmente debe colocar el Runner donde se origine tráfico similar al de sus usuarios.

Paso a paso: crear una tarea programada

El siguiente ejemplo configura una regresión nocturna para una API de comercio electrónico: registro, catálogo, carrito y pago con Stripe.

1. Abra Tareas Programadas

En el cliente de Apidog:

1. Abra el módulo Pruebas.
2. En el árbol de carpetas, seleccione Tareas Programadas.
3. Revise las tareas existentes, su estado y sus próximas ejecuciones.

Esta sección centraliza la administración de las tareas programadas del proyecto.

2. Cree la tarea

Haga clic en + Nuevo.

Defina:

• Nombre de tarea: use un nombre identificable, por ejemplo, Regresión nocturna - Producción.
• Descripción: indique cobertura, entorno y propósito.
• Estado: active o desactive la tarea sin eliminarla.

También puede crear carpetas para agrupar tareas, por ejemplo:

Tareas Programadas/
├── Producción/
│   ├── Regresión nocturna
│   └── Health check cada 6 horas
└── Staging/
    ├── Smoke test pre-release
    └── Validación post-deploy

3. Seleccione los escenarios de prueba

En Escenario de Prueba, agregue uno o más escenarios existentes.

Para una ruta crítica de comercio electrónico, podría incluir:

• Registro e inicio de sesión
• Explorar y añadir al carrito
• Pagar con tarjeta de prueba de Stripe

Cada escenario puede usar su propia configuración de ejecución:

• Entorno.
• Datos de prueba.
• Número de iteraciones.
• Retraso entre solicitudes.
• Guardado de solicitudes y respuestas.

Si todos los escenarios deben ejecutarse igual, active Usar la misma configuración de ejecución. Esto reduce configuraciones duplicadas y evita inconsistencias en suites grandes.

Como regla práctica, mantenga una tarea por entorno cuando sea posible:

Tipo de tarea	Entorno recomendado	Frecuencia sugerida
Regresión completa	Producción	Nocturna
Prueba de humo	Staging	Cada 6 horas
Validación post-despliegue	Staging o producción	Tras cada despliegue

4. Configure el ciclo de ejecución

Defina la cadencia en el campo que la interfaz puede mostrar como Ciclo de Ejecución o Modo de Ejecución.

Ejemplos documentados:

• Cada domingo a las 11 PM.
• Cada 6 horas.
• Cada 8 horas.

Para una regresión nocturna, programe la ejecución fuera del horario de mayor actividad. Para una prueba de humo en staging, una frecuencia de seis horas puede detectar regresiones con rapidez sin cargar innecesariamente el entorno.

Antes de elegir una frecuencia agresiva, revise el límite de ejecuciones de su plan.

5. Seleccione el Runner

En el campo que puede aparecer como Se ejecuta en, Ejecutar en o Se ejecuta en, seleccione su Runner autohospedado.

Elija un Runner que represente correctamente la red desde la que quiere validar su API:

API pública global        → Runner en una región representativa
API interna detrás de VPN → Runner dentro de la red corporativa
API en una VPC privada    → Runner dentro de la misma VPC

Todas las solicitudes de la suite saldrán desde la máquina configurada aquí.

6. Active las notificaciones

Habilite Notificación para recibir alertas cuando una tarea falle.

Apidog admite estos canales:

• Slack.
• Teams.
• Webhook.
• Jenkins.
• Correo electrónico.

Para correo electrónico, las direcciones de miembros del proyecto se completan automáticamente. También puede añadir direcciones externas, como una lista de guardia o un buzón compartido.

Seleccione cuándo notificar:

• Solo fallos: recomendado para regresiones nocturnas estables.
• Después de cada ejecución: útil durante despliegues, migraciones o periodos de inestabilidad.

Use un webhook si necesita conectar la alerta con su propio sistema de incidentes o endpoint personalizado.

7. Guarde y habilite la tarea

Guarde la configuración y active el interruptor de la tarea.

La suite comenzará a ejecutarse según la cadencia definida. Puede deshabilitarla temporalmente sin borrarla, por ejemplo, durante una ventana de mantenimiento o una migración que genere fallos esperados.

8. Revise el historial de ejecución

Después de cada ejecución, el Runner envía los resultados al servidor. Abra:

Tareas Programadas → Historial de Ejecución

Use este historial para responder rápidamente a una alerta:

1. Identifique la ejecución fallida.
2. Abra el escenario afectado.
3. Revise la aserción que falló.
4. Compruebe las solicitudes y respuestas guardadas.
5. Compare el resultado con ejecuciones anteriores.

El historial funciona como registro de auditoría de sus comprobaciones automatizadas.

Configuración avanzada

Defina el ámbito de las variables

Cuando los escenarios comparten datos, Apidog ofrece tres niveles de alcance:

1. Compartir solo en el escenario de prueba actual
   
   Mantiene la variable aislada en ese escenario.

2. Compartir entre todos los escenarios de prueba en la tarea programada actual
   
   Permite que escenarios de una misma tarea reutilicen valores.

3. Compartir entre todas las tareas programadas en la carpeta actual
   
   Comparte valores entre tareas relacionadas dentro de una carpeta.

Elija siempre el ámbito más pequeño que cubra su caso de uso. Por ejemplo, no comparta un token de autenticación entre tareas no relacionadas si basta con compartirlo dentro de una sola suite.

Active la persistencia de variables cuando sea necesaria

Los valores solo se transmiten entre ejecuciones si activa Conservar valores de variable en la página de diseño del escenario.

Use esta opción si una ejecución necesita reutilizar datos capturados en una ejecución anterior, como:

• Un ID de pedido.
• Un token actualizado.
• Un identificador generado por una integración externa.

Sin esta opción, cada ejecución comienza desde cero.

Organice tareas con carpetas

Use carpetas para separar suites por entorno, servicio o nivel de criticidad:

Producción/
├── API de pagos
├── API de usuarios
└── API de catálogo

Staging/
├── Smoke tests
└── Validación pre-release

Esta estructura también ayuda a controlar el ámbito de variables a nivel de carpeta.

Revise los límites de su plan

El número de ejecuciones programadas depende de su suscripción. Revise el límite antes de programar ejecuciones frecuentes, especialmente si combina varias tareas cada hora.

Para profundizar, consulte estas guías:

• Tareas programadas avanzadas
• Lógica condicional en escenarios de prueba de API
• Ejecuciones nocturnas de pruebas de API en CI

Automatice el flujo de trabajo con la CLI de Apidog

La interfaz de Tareas Programadas no es la única opción. La CLI de Apidog permite ejecutar un escenario guardado sin interfaz gráfica y delegar la programación a cron o a su plataforma de CI.

La CLI no incluye un comando nativo de programación: la cadencia se configura fuera de Apidog.

Instale la CLI, autentíquese y ejecute un escenario por ID. Consulte la guía de instalación de la CLI de Apidog para el proceso completo de configuración del token:

npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>
apidog run --access-token $APIDOG_ACCESS_TOKEN -t <SCENARIO_ID> -e <ENV_ID> -r cli,junit

Parámetros principales:

• -t: ID del escenario de prueba.
• -e: ID del entorno.
• -r: reportero. Puede usar cli, html o junit; sepárelos con comas para generar varios reportes.

Para ejecutar una suite cada noche con cron:

0 2 * * * cd /srv/api-tests && apidog run --access-token $APIDOG_ACCESS_TOKEN -t 4471 -e 88 -r junit >> run.log 2>&1

También puede lanzarla desde un workflow programado de GitHub Actions. El reporte JUnit se integra con los paneles y artefactos existentes de su pipeline.

Consulte La CLI de Apidog en su pipeline CI/CD para ver una configuración completa con cron y disparadores programados de GitHub Actions.

Preguntas frecuentes

¿Puedo ejecutar pruebas programadas en Apidog Cloud hoy?

Todavía no. Apidog Cloud aparece como “próximamente”, por lo que debe registrar y seleccionar un Runner autohospedado.

¿Con qué frecuencia pueden ejecutarse las tareas programadas?

La cadencia es flexible: puede usar configuraciones como cada seis horas o cada domingo a las 11 PM. Sin embargo, el número total de ejecuciones disponibles depende de su plan.

¿Cómo recibo alertas solo cuando falle una prueba?

En la configuración de Notificación, seleccione solo fallos y añada un canal como Slack, Teams, Webhook, Jenkins o correo electrónico. Para una señal rápida adicional, combine la suite de regresión con una comprobación de salud de API.

¿Por qué los resultados programados difieren de mis pruebas locales?

Porque las solicitudes se envían desde el Runner, no desde su portátil. La región, la VPN, las reglas de firewall y la red del Runner influyen en las respuestas.

¿Por qué mis variables se restablecen en cada ejecución?

Active Conservar valores de variable en el diseño del escenario de prueba. Sin esa opción, cada ejecución programada comienza sin valores persistidos de ejecuciones anteriores.

Conclusión

Las pruebas programadas convierten “creemos que la API funciona” en una comprobación continua y verificable. El flujo de implementación es directo:

1. Cree escenarios de prueba fiables.
2. Registre un Runner autohospedado.
3. Configure el ciclo de ejecución.
4. Seleccione el entorno correcto.
5. Active alertas solo para fallos.
6. Revise el Historial de Ejecución cuando llegue una notificación.

Si necesita integrar esas mismas comprobaciones en CI, use la CLI con cron o un workflow programado. Descargue Apidog para configurar su primera suite de regresión programada. Es gratis para empezar y no requiere tarjeta de crédito.