Un despliegue sale a las 4 p.m. un viernes. Las pruebas unitarias estaban en verde, el contenedor se construyó, el lanzamiento finalizó sin errores. Luego la cola de soporte comienza a llenarse: el checkout está arrojando errores 500. El error nunca estuvo en el código que se probó. Estaba en cómo dos servicios se comunicaban entre sí, y ninguna prueba en la tubería (pipeline) ejerció nunca esa conversación.
Esa es la brecha que la automatización de pruebas en DevOps debe cerrar, y la parte en la que la mayoría de los equipos invierten menos es la capa de API. Las pruebas unitarias demuestran que una función funciona de forma aislada. Las pruebas de interfaz de usuario de extremo a extremo demuestran que un navegador puede hacer clic a través de un flujo, de forma lenta e inestable. El contrato entre sus servicios, lo que realmente falla en producción, se encuentra en el medio y a menudo no se verifica. Las pruebas de API viven exactamente ahí.
Qué significa realmente la automatización de pruebas en DevOps
DevOps es un bucle, no una línea. Planificar, codificar, construir, probar, liberar, desplegar, operar, monitorear y luego volver a planificar. La automatización de pruebas en DevOps significa que las pruebas se ejecutan automáticamente en los puntos de ese bucle donde detectan problemas de la manera más económica, en lugar de ser una puerta manual que alguien ejecuta una vez antes de un lanzamiento.
El principio detrás de esto es el "shift-left" (mover a la izquierda): adelantar las pruebas, acercarlas al momento en que un desarrollador escribe el cambio. Un error detectado en una solicitud de extracción (pull request) cuesta minutos de arreglar. El mismo error detectado en producción cuesta un rollback, un canal de incidentes y un postmortem. La automatización es lo que hace posible el "shift-left", porque un humano no puede volver a ejecutar manualmente un conjunto de pruebas de regresión en cada commit, pero un pipeline sí puede.
El error es tratar la "automatización de pruebas" como un único bloque. La pirámide de pruebas la divide en capas, y cada capa responde a una pregunta diferente:
- Las pruebas unitarias preguntan si una única función devuelve el valor correcto. Son rápidas y numerosas.
- Las pruebas de API e integración preguntan si sus servicios producen respuestas correctas y se comunican entre sí correctamente. Hay menos de estas, pero cada una cubre más terreno.
- Las pruebas de extremo a extremo preguntan si todo el sistema funciona desde el punto de vista del usuario. Son lentas, frágiles y conviene mantener pocas.
Las pruebas de API se sitúan en el medio productivo. Se ejecutan en segundos, no en minutos. No dependen de una interfaz de usuario renderizada, por lo que no se rompen cuando un botón se mueve. Y prueban la superficie de la que realmente dependen sus otros servicios y sus clientes. Por eso, en un pipeline de DevOps, las pruebas de API soportan una mayor carga de detección de regresiones que cualquier otra capa. Para los fundamentos de la práctica en sí, la automatización de pruebas de API cubre qué y por qué afirmar antes de preocuparse por dónde se ejecuta.
El ciclo de vida de DevOps, etapa por etapa, y dónde encajan las pruebas de API
Aquí está el mapa práctico. No todos los equipos necesitan pruebas de API en cada etapa, pero conocer las opciones le permite elegir deliberadamente en lugar de volcar todo en un solo trabajo gigante de pre-despliegue.
Durante el desarrollo: local y pre-commit
Antes de que un cambio llegue a CI, un desarrollador debería poder ejecutar las pruebas de API relevantes contra un entorno local o de desarrollo. Este es el ciclo de retroalimentación más rápido que tiene. Detectar una forma de respuesta rota aquí significa que el código defectuoso nunca llega a ser enviado.
En la práctica, este es el mismo escenario que luego ejecutará en CI, solo que apuntando a un entorno local. Lo construye una vez. Si nunca ha creado uno, cómo escribir escenarios de prueba con Apidog le guía a través de la encadenación de solicitudes y la extracción de un valor de una respuesta a la siguiente.
En solicitudes de extracción (pull requests): la puerta de fusión
Este es el lugar de mayor valor para las pruebas de API, y el que los equipos suelen omitir con mayor frecuencia. Cuando se abre una solicitud de extracción (pull request), el pipeline inicia el servicio, ejecuta sus escenarios de API contra él y reporta si pasa o falla como una verificación de estado. Una verificación fallida bloquea la fusión.
La razón por la que esto importa: el costo de un error aumenta drásticamente cuanto más se propaga. Una aserción fallida en un PR es una solución de cinco minutos para el autor, que todavía tiene el cambio fresco en su mente. La misma falla encontrada una semana después en staging es un proyecto de arqueología. Poner pruebas de API en la puerta de PR es el único cambio que mueve la mayoría de los defectos hacia la izquierda (shift left).
Después de la compilación, antes del lanzamiento: verificaciones de integración y contrato
Una vez que el artefacto está construido y desplegado en un entorno de staging o integración, ejecute un conjunto de pruebas más amplio. Aquí es donde prueba el cableado real: ¿el servicio de pagos sigue aceptando el cuerpo de la solicitud del servicio de pedidos, la paginación sigue devolviendo el campo que lee su cliente, un token de autenticación emitido por un servicio es aceptado por otro?
Esta etapa también es donde el pensamiento contractual rinde frutos. Un cambio que es localmente válido aún puede romper un consumidor aguas abajo. Ejecutar el conjunto completo de escenarios contra un entorno integrado detecta las rupturas entre servicios que las pruebas unitarias estructuralmente no pueden ver. Los patrones se trasladan de la práctica más amplia de automatización de pruebas de API.
En el momento del despliegue: pruebas de humo (smoke tests)
Un despliegue no se termina cuando finaliza el lanzamiento. Se termina cuando se tiene la prueba de que la nueva versión realmente sirve el tráfico correctamente. Una prueba de humo es un escenario pequeño y rápido que golpea las rutas críticas justo después del despliegue: ¿puede un usuario autenticarse, puede leer sus datos, el endpoint crítico de salud devuelve 200 con la forma correcta?
Mantenga este conjunto de pruebas pequeño y rápido. Su trabajo es una señal de "ir" o "no ir", no de cobertura. Si falla, se revierte automáticamente. Ejecute el mismo escenario contra el entorno de producción cambiando una única bandera de entorno, sin pruebas duplicadas que mantener.
En producción: monitoreo continuo
Después del despliegue, el bucle no se detiene. Los mismos escenarios de API que ejecuta en CI pueden ejecutarse según un horario en producción como monitoreo sintético, detectando una dependencia de terceros degradada o un certificado caducado antes de que lo haga un cliente. La línea entre una prueba y un monitor es principalmente el horario en que se ejecuta. El monitoreo de API cubre la conversión de pruebas exitosas en un sistema de alerta temprana de producción.
Una regla útil en las cinco etapas: cuanto más cerca de la producción, más pequeño y rápido será el conjunto de pruebas. Amplia cobertura en PRs y en integración; un conjunto de pruebas de humo delgado e implacable en el despliegue y en el monitoreo.
Por qué la capa de API se gana su lugar en el pipeline
Vale la pena ser concreto sobre por qué las pruebas de API merecen un lugar privilegiado en lugar de cargar más peso sobre las pruebas de interfaz de usuario.
Son rápidas. Un escenario de API se comunica directamente por HTTP. No hay que iniciar un navegador, ni esperar el DOM, ni un Chrome sin interfaz gráfica que falle en una renderización lenta. Un escenario que ejercita una docena de endpoints termina en segundos, lo que le permite ejecutarlo en cada commit sin que la gente aprenda a ignorar un trabajo de diez minutos.
Son estables. Las pruebas de interfaz de usuario se rompen cuando cambia el nombre de una clase o un elemento se vuelve a renderizar con un retraso. Las pruebas de API solo se rompen cuando cambia el contrato real, que es exactamente cuando desea saberlo. Menos fallos intermitentes significa que la gente confía en una compilación en rojo, y una compilación en la que la gente confía es la única compilación que bloquea algo.
Prueban lo que se integra. Su aplicación móvil, sus integraciones con socios, sus propios microservicios, todos dependen del contrato de la API, no de su CSS. Cuando ese contrato cambia silenciosamente, todos los consumidores se rompen a la vez. Las pruebas de API son la capa que lo detecta.
Por eso la cuestión del pipeline es realmente una cuestión de API. Puede tener un conjunto de pruebas unitarias exhaustivo y un bonito conjunto de pruebas de interfaz de usuario y aún así enviar el error de checkout del viernes por la tarde, porque ninguna de las capas estaba vigilando la unión donde se encuentran los servicios.
Conectando pruebas de API al pipeline con la CLI de Apidog
La mecánica importa, porque una prueba que existe pero no se ejecuta automáticamente no detecta nada. El patrón es el mismo en todos los sistemas de CI: instalar un ejecutor, apuntarlo a sus pruebas, dejar que su código de salida decida si la compilación pasa.
Con Apidog, no reescribe sus pruebas como código. Construye el escenario una vez en la aplicación, luego la CLI de Apidog ejecuta ese mismo escenario sin interfaz gráfica (headless). La CLI es un paquete npm, por lo que cualquier ejecutor de CI con Node.js instalado puede usarla.
Instálelo:
npm install -g apidog-cli
Luego, ejecute un escenario. Genere el token de acceso y encuentre los IDs de escenario y entorno dentro de la pestaña CI/CD del escenario de prueba en Apidog, que construye el comando completo para que lo copie:
apidog run \
--access-token $APIDOG_ACCESS_TOKEN \
-t 605067 \
-e 1629989 \
-r cli
Algunas cosas están haciendo un trabajo real aquí. El flag -t nombra el escenario por ID; cámbielo por -f <folderId> para ejecutar una carpeta completa, o --test-suite <id> para ejecutar un conjunto de pruebas curado como un solo trabajo. El flag -e selecciona el entorno, que es como el mismo escenario protege un PR contra staging y ejecuta pruebas de humo contra producción sin duplicados. El flag -r elige los reportadores; cli imprime en el registro, y junit emite XML que su dashboard de CI puede renderizar como un informe de prueba.
La parte que lo convierte en una puerta es el código de salida. Cuando todas las aserciones pasan, apidog run sale con 0. Cuando algo falla, sale con un valor distinto de cero. Su sistema de CI lee ese código, marca el paso como fallido y bloquea la fusión o el despliegue. No se configura una puerta separada; el código de salida es la puerta. Ejecute apidog run --help para ver la superficie completa de flags para su versión.
Aquí está la etapa de puerta de PR integrada en GitHub Actions:
name: API Tests
on: [pull_request]
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 scenarios
env:
APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}
run: |
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-t 605067 \
-e 1629989 \
-r cli,junit
El token reside en los secretos del repositorio y llega al paso a través de env:, nunca codificado. El mismo bloque se inserta en GitLab CI, Jenkins, CircleCI o Azure Pipelines con la sintaxis de esa plataforma a su alrededor, porque la única dependencia real es Node. Los tutoriales específicos de la plataforma cubren los detalles: automatización de pruebas de API en GitHub Actions e integración de pruebas de Apidog con Jenkins.
Para la etapa de prueba de humo en el momento del despliegue, el comando apenas cambia. Lo apunta al ID del entorno de producción y mantiene el escenario pequeño:
apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e $PROD_ENV_ID -r cli
Un escenario, un cambio de entorno, dos trabajos. Ese es todo el atractivo de crear pruebas una vez y ejecutarlas a lo largo del ciclo de vida.
Errores comunes que silenciosamente anulan la puerta
Un pipeline puede parecer completamente automatizado y aun así no detectar nada. Esté atento a estos puntos.
Engullir el código de salida. Alguien envuelve el comando de prueba en un pipeline de shell o añade || true para "evitar que rompa la compilación". Eso también evita que detecte nada. La compilación permanece en verde para siempre. Nunca enmascare la salida no nula del ejecutor; esa salida es el objetivo principal.
Solo probar el camino feliz. Un escenario que confirma 200 OK y se detiene ahí, omite la ruptura que realmente importa. Afirme sobre la forma del cuerpo de la respuesta, los tipos de campo, las respuestas de error para entradas incorrectas. Las aserciones de API cubren la validación de más que un código de estado.
Un único trabajo gigante antes del despliegue. Meter todas las pruebas en una sola etapa justo antes del lanzamiento anula el "shift-left". Se entera de un contrato roto minutos antes de la entrega en lugar de en la PR. Distribuya el conjunto de pruebas en varias etapas: amplio en las PRs, delgado en el despliegue.
Probar contra un entorno mutable compartido. Cuando dos pipelines acceden a la misma base de datos, las escrituras de una ejecución contaminan las lecturas de otra, y se obtienen fallos intermitentes que erosionan la confianza. Utilice entornos aislados, o use simulacros de API (API mocking) para sustituir dependencias que no controla, de modo que el tiempo de inactividad de un tercero no ponga en rojo su compilación.
Olvidar el informe en caso de fallo. Si su informe solo se sube cuando las pruebas pasan, nunca verá el informe la única vez que lo necesita. Configure la carga del artefacto para que se ejecute incluso en caso de fallo.
Preguntas Frecuentes
¿En qué parte del pipeline de DevOps deberían ejecutarse las pruebas de API?
Como mínimo, en las solicitudes de extracción (pull requests) como puerta de fusión, ya que eso detecta la mayoría de los defectos al menor costo. Idealmente también después de la compilación contra un entorno integrado para verificaciones de contrato, y como un pequeño conjunto de pruebas de humo justo después del despliegue. El mismo escenario de Apidog se ejecuta en cada etapa; solo se cambia el indicador de entorno. Los equipos que ejecutan Apidog sin Postman siguen la misma preparación.
¿Cuál es la diferencia entre la automatización de pruebas de API y CI/CD?
CI/CD es el pipeline que construye, prueba y entrega su código automáticamente. La automatización de pruebas de API es un tipo de prueba que se ejecuta dentro de ese pipeline. CI/CD es la cinta transportadora; las pruebas de API automatizadas son una estación de calidad en ella. Si el término CI/CD en sí mismo es confuso, qué es CI/CD cubre los fundamentos.
¿Necesito reescribir mis pruebas de API como código para ejecutarlas en CI?
No con Apidog. Usted construye el escenario de prueba visualmente en la aplicación, y la CLI de Apidog ejecuta ese mismo escenario sin interfaz gráfica (headless). La CLI es un paquete npm, por lo que cualquier ejecutor de CI con Node.js instalado puede ejecutarlo con un solo comando.
¿Cómo hacen que fallen las pruebas de API una compilación?
A través del código de salida. Cuando todas las aserciones en un escenario pasan, el ejecutor sale con 0. Cuando cualquier aserción falla, sale con un valor distinto de cero. El sistema de CI lee ese código, marca el paso como fallido y bloquea la fusión o el despliegue. No se necesita una configuración de puerta separada.
¿Deberían ejecutarse las pruebas de rendimiento en el mismo pipeline?
Mantenga las pruebas de API funcionales en cada PR y ejecute pruebas de carga más pesadas y de rendimiento en un programa separado, como por la noche. Las ejecuciones de rendimiento tardan más y necesitan un entorno estable, por lo que incluirlas en cada commit ralentiza la retroalimentación sin añadir mucha señal por commit.
Dónde colocar su primera prueba de API
La automatización de pruebas en DevOps no es una puerta que se construye una sola vez. Son pruebas de API colocadas deliberadamente a lo largo del bucle: en la máquina del desarrollador para una retroalimentación rápida, en la solicitud de extracción como la puerta de fusión que detecta la mayoría de los errores, después de la compilación para verificaciones de contrato, en el momento del despliegue como una señal de humo, y en producción como un monitor. La capa de API se gana la mayor parte del espacio en el pipeline porque es rápida, estable y prueba la unión donde los sistemas realmente fallan.
Si sus pruebas de API todavía existen como pasos en los que alguien hace clic manualmente, la brecha a cerrar es la puerta de fusión. Descargue Apidog, cree un escenario, copie el comando apidog run de su pestaña CI/CD y pegue el bloque de GitHub Actions anterior. Tendrá pruebas de API bloqueando fusiones rotas al final de la tarde, y el error de despliegue del viernes se pondrá en rojo en una solicitud de extracción en lugar de en su cola de soporte.