Una pipeline en verde que despliega una API rota es peor que no tener ninguna pipeline. Le dice a tu equipo que todo está bien hasta que un cliente presenta un ticket. La mayoría de las configuraciones de pruebas de API en CI comienzan fuertes y se van deteriorando silenciosamente: se cubren algunos endpoints, luego la suite se vuelve inestable, alguien añade `continue-on-error` para detener el ruido, y en un trimestre las pruebas se ejecutan pero nadie confía en ellas. La pipeline está en verde porque ha aprendido a ignorar los fallos.
La solución no son más pruebas. Son un puñado de decisiones sobre cómo diseñas, ejecutas y controlas esas pruebas para que resistan la presión del mundo real, el tipo de presión que proviene de un hotfix un viernes por la tarde o un cambio de esquema en tres servicios. Esta guía examina doce de esas decisiones, con configuraciones concretas que puedes copiar en GitHub Actions, GitLab CI o cualquier ejecutor que ya utilices.
El hilo conductor de todas ellas es el mismo: tus pruebas de API deben vivir junto a tu contrato de API, ejecutarse con un solo comando portátil y fallar ruidosamente cuando el contrato se rompa. Ese es el flujo de trabajo que construiremos con Apidog, una plataforma de API donde diseñas la especificación, escribes aserciones visualmente y ejecutas toda la suite sin interfaz gráfica en CI a través de la CLI de Apidog. Diseñas las pruebas una vez en la aplicación, y luego ejecutas esa misma suite en cualquier pipeline con un solo comando. Si quieres seguir, descarga Apidog y ten tu propia API a mano.
Si CI/CD es nuevo para ti, la versión corta es esta: la integración continua ejecuta tus pruebas en cada commit, y la entrega continua promueve la compilación que las supera. Tenemos un desglose más completo en Qué es CI/CD y cómo funciona. El resto de este artículo asume que tienes una pipeline y quieres que la parte de pruebas de API realmente se gane su lugar en ella.
1. Pon las pruebas de API en la pipeline, no en una pestaña que olvidaste abrir
La primera mejor práctica es la que la gente se salta: ejecuta tus pruebas de API automáticamente, en cada push, sin que un humano decida hacerlo. Una suite de pruebas que ejecutas manualmente antes de un lanzamiento es una lista de verificación, no una red de seguridad. Para cuando recuerdes ejecutarla, el cambio que rompió las cosas ya está seis commits atrás.
Conecta la suite a la etapa que importa. Para la mayoría de los equipos, esto es en las pull requests, de modo que una API rota bloquea la fusión en lugar de llegar a `main`. Aquí está la forma mínima en GitHub Actions:
name: API Tests
on:
pull_request:
branches: [main]
jobs:
api-tests:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
- name: Install Apidog CLI
run: npm install -g apidog-cli
- name: Run API test suite
run: |
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-t "$SCENARIO_ID" \
-e "$APIDOG_ENV_ID" \
-r cli,junit \
--out-dir ./test-results
env:
APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}
SCENARIO_ID: ${{ vars.SCENARIO_ID }}
APIDOG_ENV_ID: ${{ vars.APIDOG_ENV_ID }}
Esa es toda la integración. La CLI sale con `0` cuando todas las aserciones pasan y con un código distinto de cero cuando alguna falla, por lo que GitHub pone el trabajo en rojo ante un fallo real sin cableado adicional. Cubrimos la configuración completa de GitHub en Cómo automatizar pruebas de API en GitHub Actions; el patrón se aplica a cualquier ejecutor.
El objetivo de la mejor práctica número uno es que la decisión de probar la toma la máquina, no el desarrollador. Los humanos olvidan. Las pipelines no.
2. Mantén el comando de ejecución portátil entre proveedores de CI
Las pipelines migran. Los equipos se mueven de Jenkins a GitHub Actions, añaden GitLab para un nuevo repositorio o configuran un ejecutor autoalojado para cumplir con la normativa. Si tus pruebas de API están soldadas al ecosistema de plugins de un proveedor, cada migración significa reescribirlas.
La forma de evitar eso es hacer que la invocación de la prueba sea un único comando de shell que cualquier ejecutor pueda llamar. Con la CLI de Apidog, el comando que ejecuta tu suite es idéntico sin importar quién lo invoque:
apidog run --access-token "$APIDOG_ACCESS_TOKEN" -t "$SCENARIO_ID" -e "$ENV_ID" -r cli,junit
Esa misma línea funciona en un paso `run` de GitHub Actions, un bloque `script` de GitLab, una etapa shell de Jenkins o una sección `script` de Travis. Solo cambia el envoltorio. GitLab, por ejemplo:
api-tests:
image: node:20
script:
- npm install -g apidog-cli
- apidog run --access-token "$APIDOG_ACCESS_TOKEN" -t "$SCENARIO_ID" -e "$ENV_ID" -r cli,junit
artifacts:
when: always
reports:
junit: ./test-results/*.xml
Debido a que el trabajo pesado (orquestación de solicitudes, aserciones, resolución de entorno) reside en la CLI y las definiciones de prueba residen en Apidog, tu YAML de pipeline se mantiene delgado. Cuando cambias de proveedor, copias seis líneas, no seiscientas. La variante de Jenkins se detalla en Cómo integrar las pruebas automatizadas de Apidog con Jenkins para CI/CD si ese es tu stack.
3. Afirma sobre el comportamiento, no solo sobre los códigos de estado
Una prueba que solo verifica `200 OK` pasará mientras tu API devuelve un array vacío, la moneda incorrecta o un nulo donde el cliente espera un objeto. Las pruebas que solo verifican códigos de estado son la razón principal por la que las pipelines en verde despliegan respuestas rotas.
Las aserciones reales verifican la forma y el contenido de la respuesta: los campos que existen, sus tipos, los valores que importan a un consumidor. En Apidog, construyes estas visualmente contra la respuesta, por lo que estás afirmando sobre la carga útil real en lugar de adivinar una ruta JSON en tu cabeza. Una prueba sólida de búsqueda de pedidos afirma que el estado es `200`, que `order.total` es un número, que `currency` es igual al valor que enviaste y que el array `items` no está vacío. Cada una de ellas es una aserción separada que falla de forma independiente, por lo que una compilación en rojo te indica qué contrato se rompió.
Tres reglas hacen que las aserciones se mantengan a lo largo del tiempo:
- Afirma sobre el contrato, no sobre los datos. Verifica que `total` es un número, no que sea igual a `49.99`. El valor exacto cambia; el tipo no.
- Una preocupación por aserción. Agrupar seis verificaciones en una sola aserción oculta cuál falló.
- Cubre el camino infeliz. Un `400` en una entrada incorrecta y un `401` en un token faltante también forman parte de tu contrato. Prueba que sigan funcionando.
Para un tratamiento más profundo sobre cómo escribir aserciones que sobrevivan a las refactorizaciones, consulta nuestra guía sobre aserción de API. Las aserciones fuertes son las que convierten una prueba de humo en una prueba de contrato, y las pruebas de contrato son las que detectan las regresiones importantes.
4. Gestiona entornos y secretos como configuración, nunca como valores codificados
Tus pruebas se ejecutan contra diferentes objetivos: un stack local, una API de staging, un endpoint de smoke testing de producción. La URL base, los tokens de autenticación y los IDs de tenant cambian entre ellos. Codificar cualquiera de ellos en una prueba es cómo una prueba de staging accidentalmente llega a producción, o cómo un token termina en tu historial de git.
Mantén los entornos como configuraciones con nombre e inyecta las diferencias. En Apidog, un entorno contiene la URL base y las variables para un objetivo; tú eliges cuál usar en una ejecución de CI con la bandera `-e`. La pipeline proporciona el token de acceso desde su almacén de secretos, nunca desde un archivo en el repositorio:
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-t "$SCENARIO_ID" \
-e "$STAGING_ENV_ID" \
-r cli,junit
El mismo escenario, apuntando a un valor `-e` diferente, se convierte en tu prueba de humo de producción. Nada cambia en la prueba; solo el entorno contra el que se resuelve. Almacena `APIDOG_ACCESS_TOKEN` en GitHub Secrets, variables de GitLab CI/CD o el gestor de credenciales de tu ejecutor, y referéncialo por su nombre. La regla es simple: cualquier cosa que difiera entre entornos o cualquier secreto es configuración, y la configuración se inyecta en tiempo de ejecución.
5. Haz que las pruebas sean deterministas para que la pipeline sea confiable
Una prueba inestable es una prueba que falla por razones no relacionadas con tu código. También es la forma más rápida de destruir la credibilidad de una pipeline. Una vez que una suite "a veces falla", los desarrolladores comienzan a volver a ejecutar trabajos hasta que se ponen en verde, lo que significa que un fallo real ahora se esconde en el ruido de los falsos.
La mayoría de la inestabilidad en las pruebas de API proviene de algunas fuentes predecibles:
- Estado mutable compartido. Dos pruebas creando un usuario con el mismo correo electrónico, o una prueba dependiendo de datos que otra prueba eliminó. Cada prueba debe configurar y desmontar sus propios datos, o usar tenants aislados.
- Suposiciones de tiempo. Afirmar sobre un resultado asíncrono antes de que esté listo. Si una operación es eventual, sondea la condición en lugar de esperar un número fijo de segundos.
- Dependencias reales que no controlas. Un sandbox de pago de terceros que te limita la tasa, o un servicio ascendente que está caído por mantenimiento. Simula esos límites para que tu prueba mida tu API, no el tiempo de actividad de otra persona. Apidog puede levantar un mock para una dependencia inestable a partir de su esquema, lo que mantiene la inestabilidad externa fuera de tu compilación.
- Dependencia del orden. Pruebas que solo pasan cuando se ejecutan en una secuencia específica. Una suite debería pasar cuando se ejecuta en cualquier orden, porque los ejecutores se paralelizan.
El determinismo es la diferencia entre una pipeline que la gente respeta y una que evitan. Dedica el esfuerzo de ingeniería a ello temprano; las pruebas inestables son un interés compuesto.
6. Mantén rápida la etapa de pruebas de API, o los desarrolladores la evitarán
Una suite de pruebas que tarda veinte minutos en cada pull request se convierte en un impuesto que los desarrolladores resienten y, finalmente, deshabilitan. La velocidad no es un lujo en CI; es lo que mantiene la suite en funcionamiento. El objetivo al que aspiran la mayoría de los equipos es una etapa de API de menos de cinco minutos en las PRs.
Algunas palancas te llevarán allí:
- Ejecuta escenarios independientes en paralelo. Si tus pruebas son deterministas (mejor práctica cinco), nada te impide dividirlas en trabajos paralelos o dejar que el ejecutor las distribuya. Las suites independientes pueden ejecutarse una al lado de la otra.
- Organiza tus pruebas por niveles. Ejecuta una suite de humo rápida en cada PR y la suite de regresión completa al fusionar a `main` o en un horario nocturno. No todas las pruebas necesitan controlar cada commit.
- Almacena en caché la instalación. Almacenar en caché la instalación global de npm de `apidog-cli` entre ejecuciones reduce el tiempo de configuración de cada trabajo.
- Falla rápido donde ayude, termina donde no. En una PR, detente en el primer fallo para dar retroalimentación rápida. En una ejecución completa nocturna, usa `--on-error continue` de la CLI para que un endpoint roto no oculte los otros cuarenta que también fallaron.
Aquí está el patrón escalonado en GitHub Actions, con una ejecución rápida de humo en las PRs y la suite completa en un horario:
on:
pull_request:
branches: [main]
schedule:
- cron: '0 2 * * *' # nightly full regression
jobs:
api-tests:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
- run: npm install -g apidog-cli
- name: Run suite
run: |
if [ "${{ github.event_name }}" = "pull_request" ]; then
apidog run --access-token "$APIDOG_ACCESS_TOKEN" -t "$SMOKE_ID" -e "$ENV_ID" -r cli,junit --out-dir ./test-results
else
apidog run --access-token "$APIDOG_ACCESS_TOKEN" -t "$FULL_ID" -e "$ENV_ID" -r cli,junit --on-error continue --out-dir ./test-results
fi
env:
APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}
Una etapa rápida que se ejecuta vale más que una etapa exhaustiva que se deshabilita.
7. Publica resultados legibles por máquina, no solo un muro de texto de consola
Cuando una compilación falla, "las pruebas de API fallaron" no es suficiente. Necesitas saber qué aserción falló, en qué escenario, en qué solicitud. Una compilación en rojo con mil líneas de salida de consola es apenas mejor que no tener ninguna prueba; alguien todavía tiene que leerla.
La solución es emitir resultados en un formato que tu servidor de CI analice de forma nativa. JUnit XML es el formato estándar de resultados de pruebas de CI, y casi todas las plataformas lo leen. La CLI de Apidog escribe uno con el reportero `junit`:
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-t "$SCENARIO_ID" \
-e "$ENV_ID" \
-r cli,html,junit \
--out-dir ./test-results
Ese comando emite tres vistas de la misma ejecución: `cli` para la salida de consola en vivo, `html` para un informe navegable que un humano puede abrir, y `junit` para la máquina. Apunta tu pipeline al XML y la plataforma lo convierte en resultados estructurados, por prueba:
- name: Publish test report
if: always()
uses: actions/upload-artifact@v4
with:
name: api-test-results
path: ./test-results
Observa el `if: always()`. Quieres que el informe se publique incluso cuando la ejecución falla, porque una ejecución fallida es exactamente cuando lo necesitas. La recompensa es real: en lugar de "la compilación de la API está rota", obtienes "la aserción `cart-total` en el escenario de pago comenzó a fallar", lo que convierte una sesión de depuración en un simple vistazo.
8. Bloquea fusiones en la suite con protección de rama
Una suite de pruebas que pasa y no bloquea nada es solo una notificación. El objetivo de CI es hacer que el código roto no sea fusionable, y eso requiere un paso más de lo que la mayoría de los equipos configuran: la protección de rama.
El código de salida hace el trabajo local. Debido a que la CLI de Apidog sale con un valor distinto de cero ante cualquier aserción fallida, el trabajo se pone en rojo ante un fallo real. Pero un trabajo en rojo en una PR es solo una advertencia hasta que haces que la verificación sea obligatoria. En GitHub, establece la verificación de pruebas de API como una verificación de estado requerida en `main`; el botón de fusión permanece deshabilitado hasta que esté en verde. GitLab y Bitbucket tienen el equivalente en sus configuraciones de solicitud de fusión.
Esta es la diferencia entre una suite que detecta regresiones y una que las documenta a posteriori. Sin una verificación obligatoria, un desarrollador bajo presión por una fecha límite hace clic en fusionar y la API rota se despliega con una verificación roja justo al lado. Con la puerta, la plataforma se niega. La prueba deja de ser una sugerencia y se convierte en una regla que las herramientas te obligan a cumplir.
Combina esto con los resultados legibles por máquina de la mejor práctica siete y una integración de estado de commit, y tu host Git mostrará la verificación fallida exacta en línea en la PR. El ciclo de retroalimentación se cierra: push, prueba, bloqueado, arreglar, verde, fusionar.
9. Genera la cobertura de pruebas a partir de la especificación de tu API en lugar de escribirla a mano
La parte más lenta de las pruebas de API es mantener las pruebas sincronizadas con la API. Cada nuevo endpoint necesita una nueva prueba; cada campo modificado necesita una aserción actualizada. Hecho a mano, las pruebas siempre van por detrás de la API, y esa brecha es donde residen las regresiones.
La jugada estratégica es impulsar las pruebas desde el contrato. Si tu API tiene una especificación OpenAPI, puedes generar el andamiaje de pruebas a partir de ella: una solicitud por endpoint, con el esquema ya describiendo la forma de respuesta esperada. En Apidog, la especificación y las pruebas viven en el mismo espacio de trabajo, por lo que un escenario de prueba se puede construir directamente a partir de los endpoints documentados en lugar de transcribirlos. Recorremos el flujo de generación en Cómo generar colecciones de pruebas de API a partir de especificaciones OpenAPI.
Esto es importante en CI porque las pruebas impulsadas por especificaciones detectan un error específico y común: la divergencia entre lo que prometen tus documentos y lo que devuelve tu API. Cuando la prueba se genera a partir de la especificación y se ejecuta contra la API en vivo, una discrepancia falla la compilación. El contrato se vuelve ejecutable. Aún escribes las aserciones que codifican el significado comercial a mano, pero no escribes a mano el código repetitivo de "este endpoint existe y devuelve la forma documentada". Deja que la especificación asuma esa carga.
10. Usa pruebas basadas en datos para cubrir casos límite sin duplicar escenarios
El mismo endpoint se comporta de manera diferente según las entradas: un pedido válido, un pedido que supera el límite de crédito, un pedido con un SKU desconocido, un pedido en una moneda no soportada. Escribir un escenario separado para cada uno es cómo las suites se inflan a cientos de pruebas casi idénticas que nadie mantiene.
Las pruebas basadas en datos ejecutan un escenario contra muchas filas de entrada. Defines la solicitud y las aserciones una vez, luego alimentas una tabla de casos. La CLI de Apidog toma un archivo de datos con la bandera `-d`:
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-t "$SCENARIO_ID" \
-e "$ENV_ID" \
-d ./test-data/orders.csv \
-r cli,junit \
--out-dir ./test-results
Cada fila en `orders.csv` se convierte en una iteración con su propio paso o fallo. Un escenario, una invocación de CLI, cobertura completa de casos límite y un informe JUnit que muestra qué filas de entrada fallaron. Esto mantiene tu suite pequeña y tu cobertura amplia, que es exactamente lo que quieres en CI. Nuestra guía sobre pruebas de API basadas en datos con CSV o JSON profundiza en la estructuración del archivo de datos.
El patrón resulta más rentable en la lógica de validación y las reglas de precios, los lugares donde un solo endpoint tiene la mayor cantidad de ramas y las mayores formas de regresión silenciosa.
11. Ejecuta una prueba de humo post-despliegue contra el entorno real
Las pruebas que pasan en staging te dicen que la compilación es buena. No te dicen que el despliegue funcionó. Desvío de configuración, una variable de entorno faltante, un balanceador de carga mal enrutado, un certificado caducado: todos estos pasan todas las pruebas pre-fusión y fallan solo en el entorno al que realmente desplegaste.
La salvaguarda es una prueba de humo que se ejecuta después del despliegue, contra el objetivo en vivo. Es una suite pequeña y rápida, solo los caminos críticos, tu flujo de autenticación, tus endpoints de lectura y escritura más importantes, apuntando a producción o al entorno recién desplegado. Debido a que el comando de ejecución es portátil (mejor práctica dos) y los entornos son solo configuración (mejor práctica cuatro), esta es la misma suite con un `-e` diferente:
smoke-after-deploy:
needs: deploy
runs-on: ubuntu-latest
steps:
- uses: actions/setup-node@v4
with:
node-version: '20'
- run: npm install -g apidog-cli
- name: Smoke test production
run: |
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-t "$SMOKE_SCENARIO_ID" \
-e "$PROD_ENV_ID" \
-r cli,junit \
--out-dir ./smoke-results
env:
APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}
Si la prueba de humo falla, esa es tu señal para revertir antes de que los usuarios se den cuenta. Para los equipos que ejecutan despliegues blue-green o canary, ejecutas la suite de humo contra el nuevo color antes de desviar el tráfico hacia él, de modo que tu primer usuario real nunca sea quien encuentre el despliegue roto. El costo es un minuto de tiempo de pipeline. La alternativa es enterarse a través de un ticket de soporte.
12. Trata la suite de pruebas como código que mantienes, no como una configuración que terminas
La última mejor práctica es una mentalidad. Una suite de pruebas de CI no es un proyecto que completas; es un activo que mantienes junto a la API que protege. Los equipos cuyas pipelines se mantienen confiables son los que tratan una prueba inestable como un error, una etapa lenta como deuda técnica y una brecha en la cobertura como una regresión a la espera de ocurrir.
Algunos hábitos mantienen una suite saludable a largo plazo:
- Añade la prueba con la característica. Un nuevo endpoint se lanza con su escenario en la misma PR, no en un seguimiento que nunca se materializa.
- Arregla las inestabilidades el día que aparecen. Una prueba inestable en cuarentena es una brecha de cobertura con luz verde. No dejes que `continue-on-error` se vuelva permanente.
- Revisa lo que la suite no cubre. Revisa periódicamente qué endpoints no tienen aserciones. Los no probados son donde comienza el próximo fallo.
- Mantén la configuración de la pipeline en control de versiones. Tu YAML, tus definiciones de entorno y tus datos de prueba viven en el repositorio, revisados como cualquier otro cambio.
Debido a que las definiciones de prueba residen en Apidog y la pipeline solo contiene una invocación mínima, la mayor parte de este mantenimiento ocurre donde es fácil: añades escenarios y aserciones en la aplicación, y la configuración de CI apenas cambia. Los equipos que lo hacen bien dedican su tiempo a mejorar la cobertura, no a supervisar el YAML. Para una visión más amplia de cómo organizar grandes suites, consulta Suites de pruebas de Apidog: Una forma más inteligente de automatizar las pruebas de API.
Juntándolo todo
Estas doce prácticas se refuerzan mutuamente. Los comandos de ejecución portátiles hacen que las pruebas de humo post-despliegue sean triviales. Las pruebas deterministas hacen que el paralelismo sea seguro, lo que mantiene la etapa rápida, lo que a su vez mantiene a los desarrolladores usándola. Los resultados legibles por máquina hacen que la protección de rama sea significativa, porque la puerta apunta a una verificación fallida específica en lugar de un muro de texto. Las pruebas impulsadas por especificaciones y por datos mantienen la suite completa sin que sea lenta de mantener.
La base común es mantener tus pruebas cerca de tu contrato y ejecutables desde un solo comando. Ese es el flujo de trabajo de Apidog en una frase: diseña la API y sus pruebas en un solo lugar, luego ejecuta esa suite exacta en cualquier pipeline con `apidog run`. La CLI sale con un valor distinto de cero en caso de fallo, emite JUnit para que tu CI lo analice, y se comporta igual ya sea que la llamen GitHub Actions, GitLab, Jenkins o un ejecutor autoalojado.
Empieza pequeño. Conecta un escenario crítico a tu pipeline de PR con aserciones reales y una verificación de estado requerida. Haz que ese bucle sea confiable, luego añade el resto: ejecuciones escalonadas, casos límite basados en datos, una prueba de humo post-despliegue. Una pipeline en la que confías es una que se pone en rojo solo cuando algo está realmente roto, y en verde solo cuando es realmente seguro desplegar. Descarga Apidog y construye el primer escenario hoy.
Preguntas Frecuentes
¿Cuál es la diferencia entre las pruebas de API en CI y CI/CD? CI (integración continua) ejecuta automáticamente tus pruebas de API en cada commit o pull request para detectar regresiones tempranamente. CD (entrega continua) promueve una compilación a un objetivo de despliegue una vez que pasa esas verificaciones. Las pruebas de API se encuentran en ambos: una suite pre-fusión controla la integración, y una suite de humo post-despliegue verifica la entrega. El mismo comando de la CLI de Apidog sirve para ambas etapas.
¿Necesito escribir código para ejecutar pruebas de API en una pipeline? No. Construyes las solicitudes y aserciones visualmente en Apidog, luego las ejecutas sin interfaz gráfica con un solo comando `apidog run`. La pipeline solo necesita ese comando, lo que mantiene tu configuración de CI delgada y significa que los ingenieros de QA pueden ser dueños de las pruebas sin mantener un framework basado en código. El tutorial completo está en Cómo automatizar pruebas de API en CI/CD.
¿Cómo evito que mis pruebas de API sean inestables en CI? Las tres causas principales son los datos de prueba mutables compartidos, las suposiciones de tiempo en operaciones asíncronas y las dependencias de terceros no controladas. Dale a cada prueba sus propios datos, sondea las condiciones asíncronas en lugar de esperar un tiempo fijo, y simula los límites externos que no controlas. Una suite que pasa en cualquier orden y en cualquier ejecución es el objetivo.
¿Cómo hago que una prueba de API fallida bloquee una fusión? Dos partes. Primero, el ejecutor de pruebas debe salir con un valor distinto de cero en caso de fallo; la CLI de Apidog hace esto en cualquier aserción fallida, por lo que el trabajo se pone en rojo automáticamente. Segundo, marca ese trabajo como una verificación de estado requerida en las reglas de protección de rama de tu host Git. El botón de fusión permanece deshabilitado hasta que la verificación pasa.
¿Puedo ejecutar las mismas pruebas de API en GitHub Actions, GitLab y Jenkins? Sí. Debido a que la lógica de las pruebas reside en Apidog y la pipeline solo llama a `apidog run`, el comando es idéntico entre proveedores; solo cambia el YAML o el script de la pipeline circundante. Esa portabilidad es lo que hace que migrar proveedores de CI sea una edición de seis líneas en lugar de una reescritura. Consulta Cómo automatizar pruebas de API en GitHub Actions para la configuración específica de GitHub.
¿Qué tan rápida debe ser mi etapa de pruebas de API? Apunta a menos de cinco minutos en las pull requests. Consíguelo ejecutando una suite de humo rápida en las PRs y la suite de regresión completa por la noche, paralelizando escenarios independientes y almacenando en caché la instalación de la CLI. Una etapa lenta es una etapa que los desarrolladores terminan deshabilitando, lo que anula el propósito.