Blog

Cómo configurar Pruebas de API automatizadas nocturnas en GitHub Actions, GitLab y Jenkins

Configura un build nocturno para tus APIs: programa pruebas de regresión automatizadas en CI con la CLI de Apidog. Copia y pega las configuraciones cron de GitHub Actions, GitLab y Jenkins para detectar fallos por la mañana.

Ashley Innocent

Ashley Innocent

15 June 2026

Cómo configurar Pruebas de API automatizadas nocturnas en GitHub Actions, GitLab y Jenkins

Apidog para empresas

Despliegue local

SSO & RBAC

Conforme con SOC 2

Explorar Apidog Enterprise

Sus pruebas de API pasan en cada pull request. La compilación está en verde. Usted lanza. Luego, a las 9 a.m., alguien en otra zona horaria informa que la caja devuelve un 500, y nadie cambió el código de la caja. Lo que cambió fue un entorno de pruebas de pago de terceros, una migración de base de datos que se ejecutó durante la noche o un token que expiró silenciosamente. Sus pruebas por commit nunca lo detectaron porque nada en su repositorio se movió.

Esta es la brecha que cierra una compilación nocturna. Una compilación nocturna es una ejecución de prueba completa y programada que se dispara una vez al día, generalmente en las primeras horas de la mañana, contra sus servicios y entornos reales en lugar de solo en los cambios de código. Atrapa las fallas que viven entre commits: la deriva de datos, integraciones inestables, credenciales caducadas, fugas lentas de rendimiento y rupturas de contratos introducidas por servicios que usted no controla. Para las API específicamente, una ejecución de regresión nocturna es el sistema de alerta temprana más económico que puede configurar.

Esta guía le mostrará cómo construir ese sistema de principio a fin con Apidog. Diseñará un conjunto de regresión, generará una ejecución de línea de comandos con la CLI de Apidog, la conectará a un trabajo CI programado en GitHub Actions, GitLab y Jenkins, y obtendrá un informe esperándolo antes de la reunión de standup. Si alguna vez ha depurado una interrupción que una ejecución nocturna habría señalado horas antes, este es el flujo de trabajo que le devuelve esas horas.

button

Por qué las pruebas por commit no son suficientes

La integración continua nos enseñó a probar en cada push. Eso es bueno, y debería seguir haciéndolo. Pero las pruebas por commit responden a una pregunta limitada: "¿este cambio rompió algo?". Se ejecutan rápido, se ejecutan a menudo y están diseñadas para mantener a los desarrolladores desbloqueados. Ese alcance es exactamente la razón por la que pasan por alto una clase completa de problemas.

Una compilación nocturna responde a una pregunta más amplia: "¿el sistema sigue sano en este momento, independientemente de si alguien lo tocó?". La diferencia importa porque la producción tiene partes móviles que sus commits nunca ven.

Así que el patrón es de dos niveles, no "uno u otro". Las pruebas rápidas de humo protegen cada commit. Un conjunto de regresión más profundo se ejecuta según un horario. El nivel nocturno es donde se coloca todo lo que es demasiado lento, demasiado amplio o demasiado dependiente del mundo real para pertenecer al ciclo interno.

Qué se incluye en una suite de regresión de API nocturna

Antes de programar cualquier cosa, decida qué es lo que la ejecución nocturna realmente verifica. Una suite nocturna es más amplia que sus pruebas de humo de puerta de commit y más exhaustiva que un rápido ping de salud. Busque una cobertura que le avergonzaría si fallara silenciosamente.

Una sólida suite de API nocturna cubre:

Si nunca ha escrito casos estructurados como estos, la plantilla y ejemplo de caso de prueba de API es un buen punto de partida, y las aserciones de API cubren cómo validar el cuerpo de la respuesta, el estado, los encabezados y la temporización con precisión.

Paso 1: Construir la suite de regresión en Apidog

Apidog trata las pruebas como una parte de primera clase del ciclo de vida de la API, no como un complemento. Usted diseña endpoints, luego los encadena en escenarios de prueba que reflejan flujos de trabajo reales. Un escenario es una lista ordenada de pasos donde cada paso es una solicitud de API con aserciones, y donde los datos fluyen de un paso al siguiente.

Aquí está la forma de un escenario de regresión de pago:

  1. POST /auth/login: envía credenciales, afirma 200, extrae el accessToken de la respuesta a una variable.
  2. POST /carts: crea un carrito usando el token, afirma 201, extrae cartId.
  3. POST /carts/{cartId}/items: añade un producto, afirma 200, afirma que el total del cuerpo de la respuesta es igual al precio esperado.
  4. POST /checkout: envía el carrito, afirma 200, afirma que order.status es "confirmed".
  5. GET /orders/{orderId}: lee el pedido, afirma que persistió con los artículos correctos.

En Apidog, construyes esto visualmente. Cada paso recibe aserciones sin escribir código repetitivo: una aserción visual como "el estado de la respuesta es 200" o "JSONPath $.order.status es igual a confirmado". Para la conformidad del esquema, Apidog puede validar automáticamente la respuesta contra la definición OpenAPI guardada del endpoint, por lo que no tienes que escribir manualmente una verificación para cada campo.

Algunas reglas de diseño mantienen una suite nocturna mantenible:

Si viene de otra herramienta, esto se mapea claramente a conceptos que ya conoce. La imagen más amplia de encadenar escenarios se encuentra en la guía de orquestación de pruebas de API, y si nunca ha ejecutado una prueba estructurada en Apidog, cómo probar una API con Apidog es el punto de partida paso a paso. Descargue Apidog y construya un escenario antes de seguir leyendo; el resto de esta guía asume que tiene una suite para ejecutar.

Paso 2: Ejecute la suite desde la línea de comandos

Una compilación nocturna se ejecuta sin supervisión, por lo que necesita un ejecutor sin interfaz gráfica. Esa es la CLI de Apidog, un paquete npm que ejecuta sus escenarios de prueba guardados desde cualquier terminal, sin necesidad de GUI. Está diseñada precisamente para esto: ejecuciones automatizadas dentro de una tubería de CI/CD.

Instálelo globalmente. La CLI requiere Node.js v16 o posterior.

npm install -g apidog-cli

Para ejecutar un escenario en línea (uno que vive en su proyecto de Apidog), necesita dos cosas: un token de acceso y el ID del escenario o de la suite. Genere el token en Apidog bajo la configuración de CI/CD, donde hay un botón "Add access token". Trate ese token como una contraseña; debe ir en un secreto, nunca en su repositorio.

El comando para ejecutar un único escenario de prueba se ve así:

apidog run \
  --access-token $APIDOG_ACCESS_TOKEN \
  -t 123456 \
  -e 789 \
  -r cli,html \
  --out-dir ./apidog-reports

Bandera por bandera, usando las opciones reales de la CLI de Apidog:

Otras banderas ganan su lugar en una ejecución nocturna. -n, --iteration-count <n> repite la ejecución para detectar inestabilidades. -d, --iteration-data <path> alimenta un archivo CSV o JSON para que un escenario se ejecute a través de muchas filas de datos; perfecto para pruebas de límites. --env-var "key=value" y --global-var "key=value" inyectan valores en tiempo de ejecución, que es como se mantienen las credenciales fuera del escenario guardado.

No tienes que memorizar esto. Apidog genera el comando exacto para ti: abre el panel de CI/CD en el cliente, elige tu escenario o suite, y copia la línea apidog run ya preparada directamente en la configuración de tu pipeline. Ejecútala una vez localmente primero para confirmar que está en verde antes de programarla.

Paso 3: Prográmelo como una compilación nocturna

Una compilación nocturna es este comando en un temporizador. Cada plataforma CI soporta trabajos programados a través de la sintaxis cron. El patrón es idéntico en todas ellas: un disparador diario, el token de acceso desde un secreto, la ejecución de la CLI y el informe archivado como un artefacto.

GitHub Actions

GitHub Actions soporta un disparador schedule con cron estándar. Este flujo de trabajo se ejecuta a las 02:00 UTC todos los días y también expone un botón manual a través de workflow_dispatch.

name: Nightly API Regression

on:
  schedule:
    - cron: '0 2 * * *'   # 02:00 UTC daily
  workflow_dispatch:        # allow manual runs

jobs:
  regression:
    runs-on: ubuntu-latest
    steps:
      - name: Set up Node
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install Apidog CLI
        run: npm install -g apidog-cli

      - name: Run nightly regression suite
        run: |
          apidog run \
            --access-token $APIDOG_ACCESS_TOKEN \
            --test-suite ${{ vars.APIDOG_SUITE_ID }} \
            -e ${{ vars.APIDOG_ENV_ID }} \
            -r cli,html \
            --out-dir ./apidog-reports
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}

      - name: Upload HTML report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: apidog-nightly-report
          path: ./apidog-reports

El if: always() en el paso de carga es importante: desea que el informe se archive incluso cuando la ejecución falle, porque un fallo es precisamente cuando necesita leerlo. Tenga en cuenta que los trabajos programados de GitHub se ejecutan en UTC y pueden retrasarse durante los picos de carga, así que no programe nada que necesite dispararse en un segundo exacto.

GitLab CI/CD

GitLab programa pipelines a través de la interfaz de usuario (CI/CD > Schedules) en lugar de en el YAML, luego su trabajo se basa en una condición de reglas para que solo se ejecute en el horario, no en cada push.

nightly-regression:
  image: node:20
  rules:
    - if: '$CI_PIPELINE_SOURCE == "schedule"'
  before_script:
    - npm install -g apidog-cli
  script:
    - apidog run
        --access-token "$APIDOG_ACCESS_TOKEN"
        --test-suite "$APIDOG_SUITE_ID"
        -e "$APIDOG_ENV_ID"
        -r cli,html
        --out-dir ./apidog-reports
  artifacts:
    when: always
    paths:
      - apidog-reports/
    expire_in: 30 days

Configure APIDOG_ACCESS_TOKEN como una variable CI/CD enmascarada y protegida, luego cree una programación de pipeline con una expresión cron como 0 2 * * *. El bloque rules evita que este trabajo se ejecute en commits ordinarios.

Jenkins

En Jenkins, un pipeline con un disparador cron hace el mismo trabajo. Almacene el token como una credencial y extráigalo con withCredentials.

pipeline {
    agent any
    triggers {
        cron('H 2 * * *')   // alrededor de las 02:00, H distribuye la carga
    }
    stages {
        stage('Install CLI') {
            steps { sh 'npm install -g apidog-cli' }
        }
        stage('Nightly regression') {
            steps {
                withCredentials([string(credentialsId: 'apidog-token',
                                        variable: 'APIDOG_ACCESS_TOKEN')]) {
                    sh '''
                        apidog run \
                          --access-token $APIDOG_ACCESS_TOKEN \
                          --test-suite $APIDOG_SUITE_ID \
                          -e $APIDOG_ENV_ID \
                          -r cli,html \
                          --out-dir ./apidog-reports
                    '''
                }
            }
        }
    }
    post {
        always {
            archiveArtifacts artifacts: 'apidog-reports/**', allowEmptyArchive: true
        }
    }
}

La H en H 2 * * * es una característica de Jenkins: elige un minuto estable dentro de la hora para que todos sus trabajos nocturnos no se amontonen exactamente a las 02:00.

Ese campo cron es el mismo en las tres plataformas. 0 2 * * * significa minuto 0, hora 2, todos los días. ¿Lo quiere dos veces por noche para detectar problemas antes? 0 2,14 * * *. ¿Solo los días laborables? 0 2 * * 1-5. Elija un momento en que su entorno de staging esté tranquilo y los sandboxes externos estén activos.

Paso 4: Haga que los fallos sean imposibles de ignorar

Una ejecución nocturna que falla en un registro que nadie lee es peor que ninguna ejecución nocturna; genera una falsa confianza. El objetivo es la alerta. Conecte el resultado a donde su equipo ya mira.

El código de salida de la CLI es su gancho. apidog run sale con un código distinto de cero cuando un escenario falla, por lo que CI automáticamente pone el trabajo en rojo. A partir de ahí:

Una disciplina mantiene las compilaciones nocturnas confiables: trate un fallo como un error real hasta que se demuestre lo contrario. La forma más rápida de matar una suite nocturna es dejar que las pruebas inestables enseñen a todos a ignorar el rojo. Si un escenario falla intermitentemente, arregle la prueba o el entorno; no lo ignore. Ejecutar con -n para repetir un escenario, o estabilizar los datos de los que depende su escenario, generalmente expone la verdadera inestabilidad.

Por qué Apidog se ajusta al patrón nocturno

Puede ensamblar una pipeline de API nocturna a partir de piezas separadas: una herramienta para diseñar, otra para escribir pruebas, una tercera para ejecutarlas sin interfaz gráfica y un validador de esquemas atornillado. Muchos equipos viven así, y funciona hasta que las piezas se desincronizan. La fricción aparece a las 2 a.m. cuando la prueba que ejecuta el runner ya no coincide con la API que realmente ha lanzado.

Apidog colapsa eso en un solo flujo de trabajo. El endpoint que diseña, el escenario que prueba, el esquema contra el que valida y el comando que programa, todo hace referencia a la misma fuente de verdad. Cuando cambia un endpoint, el escenario y la verificación del esquema se mueven con él. No hay un paso de exportación, ninguna colección que se quede obsoleta silenciosamente, ninguna segunda copia del contrato que mantener sincronizada. Si ha sentido el dolor de las colecciones de Postman que no son una verdadera fuente de verdad, ese diseño de fuente única es la diferencia.

La CLI es el mismo motor que la GUI, por lo que un escenario que depura visualmente en su escritorio se ejecuta de forma idéntica en CI a las 2 a.m. Construye y corrige pruebas con total visibilidad, luego las ejecuta sin interfaz gráfica con un solo comando. Esa simetría es lo que hace que una compilación nocturna sea algo en lo que confía en lugar de algo que tiene que cuidar.

Preguntas frecuentes

¿Cuál es la diferencia entre una compilación nocturna y la integración continua?

La integración continua ejecuta pruebas en cada cambio de código para detectar regresiones en los nuevos commits. Una compilación nocturna se ejecuta en un horario fijo, generalmente durante la noche, independientemente de si algo cambió. CI detecta lo que su equipo rompe; la ejecución nocturna detecta lo que el mundo exterior rompe: tokens caducados, dependencias desviadas, cambios de datos y un lento arrastre del rendimiento. Los pipelines maduros ejecutan ambos. Las pruebas rápidas de humo controlan cada commit, y un conjunto de regresión más amplio se ejecuta por la noche.

¿A qué hora debe ejecutarse una compilación nocturna?

Elija una ventana en la que su entorno de prueba esté inactivo y los servicios externos de los que depende sean accesibles. Para muchos equipos, eso es de 1 a.m. a 4 a.m. hora local. Si sus API llaman a sandboxes de terceros, confirme que estén activos a esa hora; algunos proveedores limitan o pausan durante la noche. Evite programar exactamente a la hora en CI compartido, donde miles de trabajos se activan a la vez; compensar unos minutos (o usar la sintaxis H de Jenkins) distribuye la carga.

¿Puedo ejecutar una suite nocturna contra producción?

Ejecute comprobaciones de solo lectura contra producción de forma segura. Para cualquier cosa que escriba datos, dirija la suite nocturna a un entorno de preparación o preproducción dedicado con datos realistas, o utilice operaciones idempotentes y un paso de limpieza. Un patrón común es una ejecución de regresión completa de lectura-escritura contra staging más una pequeña ejecución de humo de solo lectura contra producción para confirmar que el sistema en vivo es accesible y responde correctamente.

¿En qué se diferencia esto del monitoreo?

El monitoreo de tiempo de actividad responde "¿la API está activa?". Un conjunto de regresión nocturna responde "¿la API es correcta?". El monitoreo hace ping a un endpoint y verifica un 200. Una ejecución de regresión ejercita flujos de trabajo completos, valida los cuerpos de las respuestas contra su esquema, verifica los límites de autenticación y afirma las reglas de negocio. Son complementarios; el monitoreo es continuo y superficial, las pruebas nocturnas son periódicas y profundas.

¿Necesito escribir código para programar pruebas de API?

No. Usted construye escenarios visualmente en Apidog sin necesidad de scripts, luego copia el comando apidog run generado desde el panel de CI/CD. El único "código" son las pocas líneas de YAML o la configuración de pipeline que le dicen a su plataforma de CI cuándo ejecutar, y esas son las plantillas anteriores. Si prefiere ver cómo se comparan los ejecutores de línea de comandos en general, Postman CLI vs Newman y ejecutar colecciones en CI sin Newman cubren las alternativas.

Configure su primera ejecución nocturna

Empiece poco a poco. Elija un flujo de trabajo crítico, su flujo de inicio de sesión o su ruta de pago, y constrúyalo como un único escenario de Apidog con aserciones reales. Ejecútelo localmente con la CLI hasta que esté en verde. Inserte el comando generado en un trabajo programado utilizando una de las plantillas anteriores. Conecte el fallo al chat de su equipo. Eso es una compilación nocturna funcional en una tarde.

A partir de ahí, amplíe la suite. Añada escenarios para los viajes más importantes, active la validación de esquemas en todos los ámbitos y establezca presupuestos de rendimiento en sus endpoints críticos. En una semana tendrá una red de regresión que detecta los fallos que sus pruebas por commit nunca fueron diseñadas para ver, y se enterará de ellos a través de un mensaje de chat a las 2 a.m. en lugar de por un cliente a las 9.

button

Practica el diseño de API en Apidog

Descubre una forma más fácil de construir y usar APIs

Registrarse gratisDescargar