Pruebas de integración en CI/CD: guía práctica de pipelines

Un cambio en un servicio de pagos puede superar miles de unit tests y aun así romper producción porque el API de facturación interpreta una clave de idempotencia de forma distinta a lo que el servicio espera. El fallo puede pasar desapercibido hasta que un job de integración nocturno llega a la interfaz, mucho después de que el commit haya recorrido la parte rápida del pipeline.

Ese es el problema operativo de las pruebas de integración en CI/CD. Los unit tests demuestran que la lógica aislada funciona correctamente. Los tests de integración aportan evidencia de que los componentes, servicios, esquemas, queues y dependencias externas siguen siendo coherentes. En un pipeline de entrega moderno, esa evidencia debería guiar las decisiones de triage, no convertirse en un muro de checks lentos que los desarrolladores aprenden a ignorar.

CI/CD se ha convertido en un modelo estándar de entrega de software. Un informe de pruebas DevOps 2024 de mabl señala que casi el 90% de las organizaciones globales están priorizando las transformaciones DevOps, mientras que poco menos de 50% de los testers participan en la definición y el mantenimiento de procesos CI/CD, y solo 10% de las organizaciones informan que no despliegan CI/CD en absoluto. La consecuencia práctica es clara: la verificación de integración ahora tiene que operar a escala de entrega.

Tabla de contenidos

• Por qué las pruebas de integración son el punto de control de CI/CD
  • Construye el punto de control de forma deliberada
• Dónde encajan las pruebas de integración entre unitarias y end-to-end
  • Tres patrones de integración útiles
• Gestión de entornos y datos para pruebas fiables
  • Una secuencia de jobs reproducible
  • Usa la virtualización con criterio
• Ejemplos de pipelines para GitHub, GitLab CI y Jenkins
  • Acciones de GitHub
  • GitLab CI
  • Jenkins
• Tácticas de fiabilidad para tests de integración inestables
  • Mide antes de cambiar la política
  • Elimina las causas habituales
• Políticas de gating y reglas de promoción de despliegue
  • Usa gates específicos por etapa
  • Haz visibles los bypasses
• Checklist de adopción y observabilidad para confianza a largo plazo
  • Fase uno: haz que la señal existente sea confiable
  • Fase dos: aumenta la fidelidad del entorno
  • Fase tres: conecta la observabilidad con el triaje

Por qué las pruebas de integración son el punto de control de CI/CD

La integración testing es donde el riesgo de la liberación se vuelve concreto. Una prueba unitaria puede confirmar que un manejador de pagos formatea correctamente una clave de idempotencia, pero solo una prueba de integración puede demostrar que el manejador, el cliente HTTP, la facturación API, la capa de persistencia y el comportamiento de reintento coinciden cuando operan juntos.

Eso convierte a la etapa de integración en el punto de control natural entre la integración continua y la entrega continua. Un commit no debería considerarse desplegable solo porque su suite de pruebas unitarias esté en verde. Debería ganarse la promoción al generar evidencia confiable de que las interfaces que modifica siguen funcionando en un entorno similar al de producción.

La distinción es importante porque integrar con frecuencia sin verificación automática solo acelera la propagación de defectos. Una revisión sistemática de enfoques para mejorar CI/CD identificó prioridades recurrentes, como reducir el tiempo de build y pruebas, mejorar la visibilidad de los resultados, apoyar el testing continuo, detectar fallos y mejorar la fiabilidad del despliegue. Otra revisión en el mismo registro de investigación define la integración continua en torno a la integración frecuente de code verificada por un build automatizado que incluye pruebas, para que los defectos se detecten rápidamente.

Construye el punto de control de forma deliberada

Empieza clasificando los tests de integración según la decisión que respaldan:

• Tests bloqueantes protege contratos críticos y ejecútalos de forma síncrona antes de un merge o promoción.
• Tests en cuarentena permanecen visibles y siguen generando evidencia, pero no bloquean el delivery mientras el equipo investiga la inestabilidad.
• Tests asíncronos ponen a prueba workflows más amplios, composiciones completas de staging o infraestructura costosa después de que el commit supere el gate rápido.

Esto es más útil que debatir si cada test debería estar “en CI”. La pregunta correcta es si un test es lo bastante fiable y valioso como para influir en una decisión de promoción concreta.

Regla práctica: Filtra por evidencia de integración estable, no por la simple existencia de una suite de integración.

El resto de la implementación se deriva de esa regla. Usa dependencias similares a producción donde una interfaz pueda fallar, paraleliza checks independientes, mide falsos fallos y define condiciones explícitas para la cuarentena y la promoción. Los equipos que quieran conectar este trabajo con prácticas de delivery más amplias también pueden revisar los beneficios de la integración continua.

Dónde encajan las pruebas de integración entre unitarias y end-to-end

La pirámide de testing es un modelo de costes, no una ley rígida. Los unit tests son rápidos porque aíslan una función, clase o módulo. Esa velocidad los hace ideales para obtener feedback inmediato, pero los mocks pueden ocultar precisamente los fallos que ocurren en las interfaces del sistema, como diferencias de serialización, restricciones de base de datos, configuración de autenticación o el comportamiento de las colas.

Los tests end-to-end ocupan la posición opuesta. Ejecutan el user journey a través de todo el stack, lo que los hace valiosos para workflows de alto riesgo. También cruzan límites de navegador, red, servicios e infraestructura, por lo que el diagnóstico y la estabilidad se vuelven más complejos. Si cada merge debe esperar a todo el entorno end-to-end, los desarrolladores reciben una señal lenta que a menudo aporta menos que un test de integración enfocado a nivel API.

Los tests de integración ocupan el punto medio. Utilizan dependencias reales o casi reales para verificar el comportamiento entre servicios sin requerir una orquestación completa de la UI. Esta capa puede cubrir llamadas HTTP y gRPC, publicación en colas, migraciones de base de datos, interacción con caché y compatibilidad de esquemas.

Tres patrones de integración útiles

Tests de componentes in-process con Testcontainers levantar el componente de la aplicación junto con dependencias como PostgreSQL, Redis o Kafka. Este patrón compensa el coste de configuración cuando el riesgo de defectos implique persistencia, serialización, transacciones o semántica de brokers. Le da a la prueba una dependencia real y mantiene acotado el alcance de la prueba.

Pruebas de contrato entre servicios con Pact o un registro de esquemas centrarse en el acuerdo entre un consumidor y un proveedor. Son una opción sólida cuando los equipos publican servicios de forma independiente y necesitan feedback rápido sobre la deriva del contrato. Las pruebas de contrato no deben reemplazar las pruebas de integración de comportamiento, pero pueden evitar que una interfaz incompatible llegue a un entorno compartido.

Pruebas a nivel de API contra un stack de staging compuesto llamar a varios servicios desplegados a través de sus rutas de red reales. Usa este patrón para flujos de trabajo en los que importen el enrutamiento, la autenticación, el descubrimiento de servicios, la configuración de despliegue o la política de infraestructura. Mantén el conjunto centrado en las rutas críticas para el negocio, porque un stack de staging completo cuesta más aprovisionar y es más difícil de aislar cuando falla.

Mantén la suite de merge síncrona deliberadamente acotada. Un objetivo práctico es mantener el path de integración por debajo de 10 minutos por commit de merge, y luego pasa los escenarios amplios a ejecución asíncrona. Los equipos que quieran una base más amplia para esta separación pueden revisar qué incluye el testing automatizado, pero el principio rector sigue siendo simple: paga por realismo cuando cambie una decisión de release.

Gestión de entornos y datos para pruebas fiables

Un test en el entorno incorrecto puede dar una falsa sensación de seguridad. Un test en un entorno compartido inestable puede dar falsos fallos. La fiabilidad pruebas de integración en CI/CD requiere una estrategia de entornos que haga explícita la frontera de dependencias y reproducible el estado de los datos.

Empieza con dependencias que puedas ejecutar fielmente. Testcontainers puede aprovisionar instancias desechables de PostgreSQL, Redis y Kafka para cada job. La clave no es Docker en sí, sino el control sobre versiones, configuración, arranque y teardown.

Una secuencia de jobs reproducible

Usa una secuencia fija en lugar de dejar que el code improvise su setup:

1. Arrancar dependencias. Levanta el contenedor de PostgreSQL y espera un health check real en lugar de asumir que un proceso en ejecución está listo para recibir tráfico.
2. Aplica las migraciones. Ejecuta la misma ruta de migración que usa la aplicación. No crees un esquema de pruebas manual que pueda desincronizarse de producción.
3. Carga fixtures deterministas. Siembra solo los registros necesarios para el escenario y asigna datos aislados a cada job para que las ejecuciones en paralelo no muten el estado entre sí.
4. Ejecuta aserciones de contrato. Verifica formatos de request, comportamiento de response, esquemas de eventos, transiciones de estado y resultados de persistencia.
5. Desmontarlo todo. Destruye contenedores y volúmenes temporales incluso si un test falla, para que los siguientes jobs no hereden un estado corrupto.

Un arranque de PostgreSQL de 90 segundos puede ser un costo razonable si detecta defectos de migración y transacciones. Un cluster de staging completo es otra decisión: consume más infraestructura, introduce más drift de configuración y aumenta el número de puntos donde puede originarse un fallo. Empieza con el entorno más estrecho y fiel posible, y amplíalo cuando la cobertura de contratos o los incidentes en producción demuestren que el límite más pequeño no está cubriendo un modo de fallo relevante.

Usa la virtualización con criterio

Algunos sistemas de terceros no pueden aprovisionarse de forma segura en cada pipeline. WireMock, Mountebank y Hoverfly pueden simular esas dependencias, pero la simulación debe tratarse como un contrato mantenido, no como una válvula de escape cómoda. Un mock que solo devuelva respuestas ideales no revelará la expiración de la autenticación, el rate limiting, payloads malformados, el manejo de timeouts o la evolución de esquemas.

Los entornos de preview efímeros son útiles cuando el riesgo depende de varios servicios desplegados que trabajan juntos. Docker Compose puede ofrecer una composición local y de CI compacta, mientras que los namespaces de Kubernetes pueden aislar entornos de pull request cuando el comportamiento del deployment en sí necesita probarse. Sea cual sea el enfoque, fija las versiones de las dependencias y registra la configuración usada en cada ejecución.

Los secrets requieren la misma disciplina que los datos. Guarda las credenciales fuera de los test fixtures y rota el acceso mediante los mecanismos protegidos de la plataforma. El guía de Capgo para gestionar secrets en pipelines de CI/CD ofrece orientación relevante para mantener los valores sensibles fuera de la configuración del repositorio.

Un breve recorrido visual puede ayudar a los equipos a alinearse con el ciclo de vida del entorno:

Ejemplos de pipelines para GitHub, GitLab CI y Jenkins

El runner importa menos que la estructura del workflow. Haz build una vez, aprovisiona dependencias de forma predecible, separa los grupos de tests independientes, publica resultados legibles por máquina y deja clara la barrera de bloqueo. La sintaxis cambia entre plataformas, pero esas reglas operativas se mantienen constantes.

Acciones de GitHub

Una matriz funciona bien cuando los tests de integración pueden dividirse por dominio o shard. Los service containers mantienen las dependencias cerca del runner, mientras que el output de JUnit ofrece un formato de resultado estable para los pull requests y los sistemas downstream.

name: integration

on:
  pull_request:

jobs:
  integration:
    strategy:
      fail-fast: false
      matrix:
        suite: [billing, orders, notifications]
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_PASSWORD: test
          POSTGRES_DB: app_test
        options: >-
          --health-cmd "pg_isready -U postgres -d app_test"
          --health-interval 5s
          --health-timeout 5s
          --health-retries 12
      redis:
        image: redis:7
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - run: npm run test:integration, --suite=${{ matrix.suite }}
      - if: always()
        uses: actions/upload-artifact@v4
        with:
          name: junit-${{ matrix.suite }}
          path: test-results/*.xml

Fijar las versiones de las actions y dependencias reduce el drift del entorno. GitHub Actions ofrece paralelismo principalmente mediante matrices y jobs separados, así que usa una matriz solo cuando cada shard tenga datos aislados y una duración predecible.

GitLab CI

GitLab CI permite separar la preparación, la ejecución de tests y el reporte. Los child pipelines son útiles cuando un repositorio grande gestiona múltiples servicios con distintos entornos de integración. Los artifacts conservan los resultados de JUnit incluso cuando falla el job de test.

stages:
  - build
  - integration

build-image:
  stage: build
  script:
    - docker build --tag "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA" .
    - docker push "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"

integration:
  stage: integration
  parallel:
    matrix:
      - SUITE: [billing, orders, notifications]
  image: "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"
  services:
    - name: postgres:16
      alias: postgres
    - name: redis:7
      alias: redis
  script:
    - ./scripts/migrate-test-db.sh
    - npm run test:integration, --suite="$SUITE" --reporter=junit
  artifacts:
    when: always
    reports:
      junit: test-results/*.xml

Usa child pipelines de GitLab cuando la propiedad del servicio o la topología de despliegue dificulten el mantenimiento de un archivo monolítico. Deja la decisión de promoción en el parent pipeline; de lo contrario, un child pipeline individual podría pasar mientras la señal de release general sigue siendo ambigua.

Jenkins

Jenkins es útil cuando los equipos necesitan agentes self-hosted o acceso a redes poco habituales. Un Jenkinsfile declarativo puede asignar agentes basados en Docker y ejecutar suites en paralelo, pero el equipo se encarga del mantenimiento de plugins, controller, agentes e imágenes.

pipeline {
  agent none

  stages {
    stage('Build') {
      agent { docker 'node:22' }
      steps {
        sh 'npm ci'
        sh 'npm run build'
        stash name: 'build', includes: 'dist/**'
      }
    }

    stage('Integration') {
      parallel {
        stage('Billing') {
          agent { docker 'my-org/integration-runner:stable' }
          steps {
            unstash 'build'
            sh './scripts/start-test-dependencies.sh'
            sh 'npm run test:integration, --suite=billing'
          }
        }
        stage('Orders') {
          agent { docker 'my-org/integration-runner:stable' }
          steps {
            unstash 'build'
            sh './scripts/start-test-dependencies.sh'
            sh 'npm run test:integration, --suite=orders'
          }
        }
      }
    }
  }

  post {
    always {
      junit 'test-results/*.xml'
    }
  }
}

Para equipos que ya usan GitHub, compilación y publicación automatizadas con GitHub Actions puede ofrecer un patrón de despliegue útil. La decisión de diseño importante sigue siendo la misma en los tres runners: no conviertas cada prueba costosa en un bloqueador síncrono de merge.

Tácticas de fiabilidad para tests de integración inestables

Los reintentos son útiles para el diagnóstico, pero los reintentos indiscriminados son una mala estrategia de fiabilidad. Pueden convertir un defecto real en un build verde, ocultar la inestabilidad del entorno y hacer que los dashboards de tasa de éxito parezcan más sanos de lo que realmente es la pipeline.

La magnitud del problema se ve en los datos de ingeniería publicados. Google informó que aproximadamente el 16% de las pruebas presentan cierta flakiness y alrededor del 1,5% de todas las ejecuciones de pruebas devuelve un resultado flaky, mientras que otro estudio encontró que 4.56% de fallos en los tests de Google fueron causados por pruebas flaky, según se resume en la guía de AWS sobre pruebas de integración y entrega continuaLos datos de Google también mostraron que 84% de las transiciones pass-to-fail en CI fueron flaky en lugar de bugs reales, y proyectos de Microsoft reportaron cerca de un 4,6% de pruebas flaky en un estudio, según la revisión de estadísticas de tests flaky de Panto.

Mide antes de cambiar la política

Rastrea el flakiness como:

fallos flaky ÷ ejecuciones totales × 100

Usa un Ventana de 7 a 30 días, y calcúlalo por suite, test, imagen del runner, dependencia y entorno. Un test que falla solo en un runner requiere una solución distinta a uno que falla en todos los entornos.

Usa estas categorías de triaje:

• Fallo de producto: bloquea el gate correspondiente y corrige el code o el contrato.
• Fallo de entorno: reparar health checks, límites de recursos, red o configuración de dependencias.
• Fallo de prueba: corrige el orden de las aserciones, el estado compartido, el timing, la limpieza o el diseño de fixtures.
• Inestabilidad no clasificada: aisla temporalmente, pero asigna un responsable y una fecha de expiración.

Elimina las causas habituales

El estado mutable compartido crea dependencias de orden. Aísla los esquemas, usa identificadores únicos o define un límite de rollback de transacción para cada job. Los sistemas asíncronos necesitan polling basado en condiciones con timeouts acotados, no sleeps arbitrarios. Inyecta relojes en la lógica de expiración y espera la salud del contenedor, no solo el arranque del proceso.

El sharding reduce el tiempo real, pero no arregla un test deficiente. Ejecuta los shards de forma independiente, conserva los logs de cada uno y vuelve a ejecutar solo el test o shard fallido para diagnosticar. No reejecutes todo el pipeline solo porque una verificación de integración tuvo un fallo ambiental.

Un test solo puede salir de cuarentena si cumple una política de estabilidad definida, como ejecuciones verdes consecutivas en los entornos donde se ejecutará. El umbral exacto debe elegirse por el equipo y documentarse en la política. Lo clave es que la promoción se gana mediante estabilidad observada, no eliminando la etiqueta de cuarentena.

Políticas de gating y reglas de promoción de despliegue

Una quality gate debe responder a una sola pregunta: ¿tiene este artifact evidencia confiable suficiente para pasar al siguiente entorno? No debe convertirse en un vertedero para cada test que la organización haya acumulado.

La brecha de aplicación es una advertencia. Una encuesta de 2025 citada por Análisis de pruebas de CI/CD de Testkube indica que el 72% de las organizaciones tienen QA automatizado en CI/CD, mientras que solo 26% impón quality gates que bloqueen el despliegue si los tests fallan. Adoptar esto sin aplicarlo deja la decisión de release a la memoria, la urgencia o una lista manual.

Usa gates específicos por etapa

Al hacer commit, bloquea con unit tests rápidos y el subset de integración estable que proteja interfaces críticas o modificadas. En staging, añade checks de entorno compuesto y validación de la configuración de despliegue. Antes de producción, exige el artifact aprobado, validación exitosa en entorno protegido y una aprobación explícita cuando tu modelo de riesgo lo requiera.

No confundas el “pass rate” con un objetivo de porcentaje puro. Una suite puede mostrar un pass rate alto mientras falla repetidamente en la ruta exacta de pago o autenticación que importa. Define la cobertura de rutas críticas por comportamiento y exige que esos checks pasen de forma determinista.

Haz visibles los bypasses

Configura la protección de ramas para que un check bloqueante fallido impida el merge. Configura reglas de protección de entornos para que la promoción requiera las aprobaciones y los artifacts esperados. Un override manual puede ser necesario durante un incidente, pero debe requerir un motivo explícito, un aprobador identificado, un timestamp y un ticket de seguimiento.

La cuarentena no es un permiso para ignorar fallos. Es una forma controlada de mantener el delivery en marcha sin perder la evidencia. Si un test en cuarentena cubre una ruta de release protegida, la política debe devolverlo al estado bloqueante o exigir una decisión de riesgo antes de la promoción.

Checklist de adopción y observabilidad para confianza a largo plazo

Los equipos suelen fallar en el testing de integración de dos formas: o empiezan con una suite enorme que ralentiza cada merge, o crean una suite rápida con mocks tan amplios que nunca reproducen los fallos que expone producción. Un plan de adopción por etapas evita ambas trampas.

Fase uno: haz que la señal existente sea confiable

Empieza con el pipeline que ya tienes:

• Establece el primer gate: Identifica contratos de servicio críticos y haz que solo los checks estables sean bloqueantes.
• Define el comportamiento de reintentos: Permite reruns dirigidos para diagnóstico; evita reintentos silenciosos que conviertan un fallo en un éxito.
• Habilita la paralelización: Divide las suites por dominio acotado, dependencia o shard, con datos aislados por job.
• Publica los resultados de los tests: Almacena reportes JUnit, logs, estado del contenedor y clasificación de fallos de cada ejecución.

En esta etapa, no busques la máxima cobertura. Elimina primero las fuentes de ruido más costosas y luego usa la confianza recuperada de los desarrolladores para ampliar la cobertura real de dependencias.

Fase dos: aumenta la fidelidad del entorno

Añade Testcontainers para dependencias que sean baratas de reproducir. Introduce contract tests donde la propiedad de los servicios está distribuida. Usa entornos efímeros cuando el enrutamiento, la configuración de despliegue o el comportamiento entre servicios no se pueda representar con precisión en un job compacto.

La decisión de selección debe basarse en evidencias. Si un incidente en producción reveló un desajuste de migración, añade una ruta de base de datos real. Si un API divergió entre servicios desplegados de forma independiente, añade un contrato consumer-provider. Si un fallo depende de la configuración de Kubernetes, ejecuta el check correspondiente en un namespace efímero en lugar de fingir que un mock demuestra lo mismo.

Fase tres: conecta la observabilidad con el triaje

Captura percentiles de duración de tests, diferencias de configuración de entorno, versiones de dependencias fijadas, ratios de reintentos hasta pasar, y logs y trazas de la aplicación correlacionados mediante OpenTelemetry. Un dashboard útil debería mostrar:

• Tasa de flakiness: Qué suites y tests se están volviendo menos deterministas.
• Tiempo medio hasta verde: Dónde pierde tiempo un pipeline fallido antes de recuperarse.
• Clusters de modos de fallo: Si los fallos se agrupan en torno a code, el entorno, las dependencias o el diseño de los tests.
• Inventario de cuarentena: Qué tests están en cuarentena, quién es el responsable y cuándo deben revisarse.
• Evidencia de promoción: Qué gates se superaron antes de cada cambio de entorno.

Este es el significado operativo de la observabilidad de aplicaciones. El dashboard no es un archivo retrospectivo. Debe cambiar la decisión de hoy sobre si un test bloquea, espera de forma asíncrona o vuelve a cuarentena.

Mantén una política de equipo de una página con el subconjunto de tests que bloquean, las reglas de cuarentena, los responsables de cada entorno, los límites de reintento, los requisitos de artefactos y el proceso de override. Revísala cuando cambien los datos de fallos, no solo cuando un incidente grave obligue a tener la conversación.

Capgo ofrece integraciones de CI/CD para automatizar los uploads de bundles de Live Update firmados después de un build web, con canales que pueden soportar workflows de feature-branch, staging y producción. Si tu equipo de CapacitorJS o Electron necesita conectar la evidencia de los integration tests con el delivery móvil controlado, visita Capgo para evaluar el workflow de API y de rollout.