Un conjunto de pruebas que pasa solo ayuda si sigue pasando. Su flujo de pago funciona hoy, pero una dependencia envía un cambio disruptivo a las 2 a.m., un certificado caduca durante el fin de semana, o una desviación de configuración desactiva el punto final de pagos un domingo. Se entera por un cliente molesto en lugar de una ejecución de prueba. La solución es aburrida y fiable: ejecute sus pruebas de API en un horario, sin que un humano haga clic en un botón, y se le notificará en el momento en que algo falle.
Apidog tiene una función de Tareas Programadas incorporada precisamente para esto. La dirige a escenarios de prueba que ya ha creado, establece una cadencia, elige una máquina en la que ejecutar y configura las alertas. Esta guía lo explica todo honestamente, incluyendo dónde están los límites actuales. Si es nuevo en la ejecución de comprobaciones desatendidas contra puntos finales en vivo, nuestra introducción sobre la monitorización de API establece el contexto más amplio, y la documentación de Tareas Programadas de Apidog es la fuente de referencia para la interfaz de usuario.
Una nota rápida antes de empezar. La función de Tareas Programadas está marcada como Beta en este momento, y el número exacto de ejecuciones programadas que obtiene su cuenta depende de su plan. Tenga ambas cosas en cuenta mientras lee.
Qué hacen las tareas programadas (y en qué se diferencian de los scrapers programados)
Una tarea programada en Apidog ejecuta uno o más Escenarios de Prueba guardados en un ciclo recurrente. Piense en una regresión nocturna en su API principal, una prueba de humo cada pocas horas contra el entorno de ensayo, o una revisión de salud de fin de semana. La tarea recuerda qué escenarios ejecutar, qué entorno usar, con qué frecuencia disparar, qué máquina ejecuta el trabajo y a quién notificar cuando falla.
Si ha visto la frase "tareas programadas" asociada al web scraping o la recopilación de datos, eso es algo diferente. Esta función no se trata de rastrear páginas con un temporizador. Reside dentro del módulo de Pruebas y maneja sus escenarios de prueba de API: aserciones, solicitudes encadenadas, variables extraídas, todo. El resultado es un informe de aprobación o fallo sobre su contrato de API, no un conjunto de datos extraídos.
Esa distinción es importante porque cambia lo que configura. No está escribiendo selectores o reglas de rastreo. Está eligiendo escenarios de prueba existentes y diciéndole a Apidog cuándo y dónde ejecutarlos.
Antes de empezar: configure un Runner autohospedado
Aquí está el prerrequisito que confunde a la gente. Para ejecutar tareas programadas, primero debe configurar un Runner autohospedado. La documentación es explícita al respecto.
Un Runner es una máquina que ejecuta el conjunto de pruebas. Cuando se activa una tarea programada, Apidog no ejecuta las solicitudes en su cliente de escritorio; entrega el trabajo al Runner que seleccionó, y cada solicitud en el conjunto se envía desde esa máquina. Un equipo de CI, un pequeño servidor siempre encendido o una máquina virtual dedicada funcionan bien. Lo que sea que elija permanece activo y accesible en el horario que desee.
El campo de destino del runner ofrece dos opciones: Apidog Cloud, marcado como "próximamente", o un Runner autohospedado. Dado que Apidog Cloud aún no está disponible, un Runner autohospedado es la única opción que funciona hoy. No planifique la ejecución en la nube hasta que se lance.
Debido a que las solicitudes se originan en la máquina del Runner, su entorno de red moldea sus resultados. Un Runner detrás de una VPN corporativa, en una región diferente o en una subred con firewall puede ver respuestas diferentes a las de su portátil. Esto es generalmente lo que desea para una monitorización realista, pero vale la pena saberlo cuando una ejecución programada no coincide con una local.
Paso a paso: crear una tarea programada
Con un Runner registrado, el resto ocurre en el cliente. El ejemplo que se presenta a continuación es un conjunto de regresión nocturna para una API de comercio electrónico que cubre el registro de usuarios, la lista de productos, el carrito y un proceso de pago respaldado por Stripe.
1. Abrir Tareas Programadas en el módulo de Pruebas
Abra el módulo de Pruebas en el cliente de Apidog. En el árbol de carpetas de Pruebas, haga clic en Tareas Programadas para ver y administrar todas las tareas programadas en el proyecto. Todas las tareas del proyecto aparecen aquí en la sección de Tareas Programadas, por lo que este es su único lugar para ver qué se está ejecutando y cuándo.
2. Crear la tarea
Haga clic en + Nuevo para crear una nueva tarea programada. También puede crear una carpeta aquí para agrupar tareas relacionadas, lo cual es útil una vez que tenga conjuntos separados para entornos de ensayo y producción o para diferentes servicios.
Asigne a la tarea un Nombre de Tarea y una Descripción claros. Estos existen para distinguir las tareas y explicar su propósito, de modo que su yo futuro sepa qué cubre realmente "Regresión nocturna, prod" sin tener que abrirla. Cada tarea también tiene un interruptor de habilitar/deshabilitar, y las tareas en el árbol se pueden habilitar o deshabilitar en cualquier momento.
3. Seleccionar los escenarios de prueba a ejecutar
Bajo Escenario de Prueba, elija uno o más escenarios para incluir. Para el ejemplo de comercio electrónico, podría seleccionar "Registro e inicio de sesión", "Explorar y añadir al carrito" y "Pagar con tarjeta de prueba de Stripe" para que una sola tarea cubra toda la ruta crítica.
Cada escenario puede tener su propia configuración de ejecución: Entorno, datos de prueba, iteraciones, retraso y si guardar solicitudes y respuestas. Si prefiere no ajustar cada uno, active Usar la misma configuración de ejecución para aplicar una única configuración de tiempo de ejecución a todos los escenarios seleccionados a la vez. Eso mantiene un conjunto grande consistente y rápido de configurar.
La selección del entorno es la configuración que más importa a la gente. Dirija un monitor de producción nocturno a su entorno de producción, y dirija una prueba de humo previa al lanzamiento al entorno de ensayo. Debido a que cada escenario puede especificar su propio entorno, una tarea puede incluso mezclar destinos si lo necesita, aunque mantener una tarea en un solo entorno es más claro para razonar.
4. Establecer el ciclo de ejecución
Establezca el campo de programación de ejecución en la cadencia que desee. Dependiendo de la pantalla en la que se encuentre, este campo puede leerse como Ciclo de Ejecución o Modo de Ejecución; es la misma configuración, y la redacción de la etiqueta varía en la interfaz de usuario. La documentación proporciona ejemplos concretos que puede replicar: cada domingo a las 11 PM, cada 6 horas o cada 8 horas.
Para la regresión nocturna, una ejecución diaria a altas horas de la noche mantiene el ruido bajo y detecta problemas antes de la jornada laboral. Para una prueba de humo en el entorno de ensayo, cada 6 horas le proporciona una retroalimentación más rápida sin sobrecargar el entorno.
5. Elegir dónde se ejecuta
Establezca el campo de runner en su Runner autohospedado. Al igual que el campo de programación, este se etiqueta de forma inconsistente en las pantallas como Se ejecuta en, Ejecutar en o Se ejecuta en; todos significan lo mismo, la máquina que ejecuta el conjunto. Apidog Cloud también aparece aquí pero estará disponible próximamente, así que elija su Runner autohospedado. Si ha registrado varios Runners de propósito general, elija el específico que desee, por ejemplo, un Runner que se encuentre dentro de la misma VPC que su API.
Recuerde que todas las solicitudes iniciadas en el conjunto de pruebas se envían desde la máquina especificada aquí, así que elija un Runner cuya red vea su API de la misma manera que lo hace el tráfico real.
6. Activar notificaciones
Habilite la Notificación para que la tarea le avise cuando algo falle. La documentación recomienda esto para las tareas programadas, y es el objetivo principal de las ejecuciones desatendidas: el silencio debe significar éxito, y un fallo debe llegarle rápidamente.
Apidog admite estos canales por nombre: Slack, Teams, Webhook, Jenkins y Correo electrónico. Para el correo electrónico, las direcciones de los miembros del proyecto se completan automáticamente, y puede introducir direcciones de no miembros manualmente para una rotación de guardia o una bandeja de entrada compartida. Slack envía los fallos directamente a su canal de equipo; la opción Webhook le permite distribuir a cualquier otra cosa que ejecute, desde PagerDuty hasta un punto final personalizado.
También elige cuándo se activan las alertas: después de cada ejecución, o solo en caso de fallos. Para un conjunto nocturno saludable, "solo fallos" mantiene el canal tranquilo hasta que importa. Durante un despliegue inestable, "cada ejecución" le da un latido que confirma que el trabajo se está ejecutando.
7. Guardar y habilitar
Active el interruptor de la tarea para habilitarla, y comenzará a ejecutarse en la cadencia que haya establecido. Puede deshabilitarla más tarde sin eliminarla, lo cual es útil durante una interrupción planificada o una ventana de migración ruidosa.
8. Leer el historial de ejecución
Después de cada ejecución, los resultados se cargan automáticamente desde el Runner de vuelta al servidor. Abra la sección Tareas Programadas - Historial de Ejecución en el cliente para verlos. Este es su registro de auditoría: qué ejecución pasó, cuál falló, qué aserción se rompió y cuándo. Cuando una alerta llega a Slack, el Historial de Ejecución es donde va para ver los detalles detrás de ella.
Configuración avanzada y variaciones
Una vez que la tarea básica se ejecuta, algunas opciones la hacen más robusta.
Ámbito de la variable. Cuando sus escenarios pasan datos entre ejecuciones, Apidog le ofrece tres niveles de compartición, de menor a mayor: Compartir solo en el escenario de prueba actual, que mantiene una variable en un archivo dedicado para ese escenario; Compartir entre todos los escenarios de prueba en la tarea programada actual, que permite que los escenarios de la misma tarea lean los valores de los demás; y Compartir entre todas las tareas programadas en la carpeta de tareas programadas actual, el ámbito más amplio. Elija el ámbito más pequeño que aún permita el flujo de sus datos, para que un token de autenticación de un escenario no se filtre a uno no relacionado.
Persistencia de variables. Los valores solo se transmiten de una ejecución a la siguiente si la opción Conservar valores de variable está habilitada en la página de diseño del escenario de prueba. Si su ejecución nocturna necesita el ID de pedido capturado de ayer o un token actualizado, active esto. Sin ello, cada ejecución comienza de cero y cualquier suposición entre ejecuciones se rompe silenciosamente.
Agrupación con carpetas. A medida que su suite crece, cree carpetas bajo Tareas Programadas para separar, por ejemplo, los monitores de producción de las comprobaciones previas al lanzamiento. El ámbito de la variable a nivel de carpeta permite que un grupo de tareas relacionadas compartan la configuración de forma limpia.
Límites del plan. El número de ejecuciones programadas que obtiene depende de su suscripción. La documentación remite a la página de precios de Apidog para las cifras exactas, así que revise su plan antes de establecer una cadencia agresiva cada hora. Si necesita una cobertura más profunda de agrupación y patrones de programación más intensos, nuestra guía detallada sobre tareas programadas avanzadas va más allá, y la guía hermana sobre lógica condicional en escenarios de prueba de API le ayuda a construir escenarios que valen la pena programar en primer lugar. Para equipos que implementan sus primeras comprobaciones desatendidas, el artículo sobre ejecuciones nocturnas de pruebas de API en CI combina bien con este.
Automatice el flujo de trabajo con la CLI de Apidog
La interfaz de usuario de Tareas Programadas es un camino. La CLI de Apidog es el tercero, y es uno real: ejecuta un escenario guardado sin interfaz gráfica, luego deja que cron o su proveedor de CI manejen la cadencia. Para ser claros, la CLI no tiene un comando de programación nativo; la programación reside fuera de Apidog en la herramienta en la que ya confía para cron.
Instale y autentique, luego ejecute un escenario por ID contra un entorno elegido. La guía de instalación de la CLI de Apidog cubre la configuración del token en su totalidad:
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
Aquí -t es el ID del escenario de prueba, -e es el ID del entorno y -r es el reportero (cli, html o junit, separados por comas para varios). Para ejecutarlo cada noche con cron, añada una línea:
0 2 * * * cd /srv/api-tests && apidog run --access-token $APIDOG_ACCESS_TOKEN -t 4471 -e 88 -r junit >> run.log 2>&1
O actívelo desde un trabajo programado de GitHub Actions. De cualquier manera, el informe JUnit se incorpora a sus paneles de control de pipeline existentes. Consulte La CLI de Apidog en su pipeline CI/CD para la configuración completa, incluyendo cron y disparadores de programación de GitHub Actions.
Preguntas Frecuentes
¿Puedo ejecutar pruebas programadas en Apidog Cloud hoy? Todavía no. El destino del runner lista Apidog Cloud como "próximamente", por lo que un Runner autohospedado es la única máquina de ejecución que funciona por ahora. Registre un Runner primero, luego selecciónelo en la tarea.
¿Con qué frecuencia pueden ejecutarse las tareas programadas? Con la frecuencia que permita su plan. La cadencia en sí es flexible, con ejemplos documentados como cada 6 horas o cada domingo a las 11 PM, pero el número de ejecuciones programadas está limitado por su suscripción. Consulte la página de precios de Apidog para conocer el límite exacto de su nivel en lugar de asumir un número.
¿Cómo recibo notificaciones solo cuando una prueba falla? En la configuración de Notificación de la tarea, elija la opción "solo fallos" en lugar de "cada ejecución", luego añada un canal: Slack, Teams, Webhook, Jenkins o Correo electrónico. Esto mantiene su canal tranquilo en noches de éxito y ruidoso cuando algo falla. Combínelo con una comprobación de salud de API ligera para una señal rápida de actividad junto con la suite de regresión más profunda.
¿Por qué mis resultados programados difieren de mis ejecuciones de prueba locales? Porque las solicitudes provienen de la máquina del Runner, no de su portátil. Su red, región y cualquier VPN o firewall moldean las respuestas. Esto es lo esperado, y a menudo es la vista más realista de lo que encuentran sus usuarios.
Mis variables se restablecen en cada ejecución. ¿Qué me perdí? La opción "Conservar valores de variable" en la página de diseño del escenario de prueba. Habilítela para que los valores capturados persistan de una ejecución a la siguiente. Sin ella, cada ejecución programada comienza de nuevo y cualquier dependencia entre ejecuciones falla.
Conclusión
Las pruebas programadas convierten "creemos que la API funciona" en "lo sabemos, y ya nos habríamos enterado si no fuera así". Construya sus escenarios una vez, registre un Runner autohospedado, establezca un Ciclo de Ejecución, configure Slack o el correo electrónico para notificaciones de fallo, y déjelo funcionar mientras duerme. Si desea las mismas comprobaciones dentro de un pipeline, la CLI más cron le ofrece la tercera opción sin herramientas adicionales. Descargue Apidog para configurar su primera suite de regresión programada. Es gratis para empezar, no se requiere tarjeta de crédito.