30. Automatización básica de pruebas de integración

30.1 Introducción

Automatizar pruebas de integración significa hacer que ciertos escenarios se ejecuten de forma repetible mediante herramientas, código o scripts, sin depender de una persona que realice todos los pasos manualmente.

La automatización es especialmente útil cuando una integración debe verificarse muchas veces: después de cambios, antes de publicar una versión o cuando se modifica una dependencia importante.

En este tema veremos los conceptos básicos para automatizar pruebas de integración de manera clara, estable y mantenible.

30.2 Qué significa automatizar

Automatizar no es solo ejecutar una acción. Una prueba automatizada debe preparar el escenario, ejecutar la operación, verificar resultados y limpiar lo necesario.

En integración, una prueba automatizada puede hacer varias tareas:

  • Configurar dependencias.
  • Crear datos iniciales.
  • Ejecutar una operación entre componentes.
  • Consultar base de datos o estado final.
  • Revisar mensajes, archivos o respuestas.
  • Limpiar datos creados.
Una prueba de integración automatizada debe poder repetirse con el mismo resultado esperado cuando el sistema no cambió.

30.3 Qué conviene automatizar primero

No todas las pruebas deben automatizarse al mismo tiempo. Conviene empezar por escenarios de alto valor.

Buenos candidatos iniciales:

  • Flujos críticos del negocio.
  • Integraciones que fallaron antes.
  • Escenarios que se repiten en cada versión.
  • Contratos entre componentes importantes.
  • Persistencia de datos críticos.
  • Manejo de errores de dependencias relevantes.

Automatizar primero casos poco importantes puede consumir esfuerzo sin reducir riesgos significativos.

30.4 Qué no conviene automatizar al principio

Al comenzar, conviene evitar pruebas que sean demasiado frágiles, ambiguas o costosas de mantener.

Puede no convenir automatizar primero:

  • Escenarios que todavía cambian todos los días.
  • Flujos con requisitos poco claros.
  • Integraciones inestables por ambiente no preparado.
  • Casos de bajo impacto.
  • Pruebas que requieren demasiada intervención manual.
  • Escenarios que ya están mejor cubiertos por pruebas unitarias.

Antes de automatizar, el equipo debe entender bien qué resultado se espera.

30.5 Estructura de una prueba automatizada

Una estructura común para pruebas automatizadas es: preparar, ejecutar, verificar y limpiar.

Etapa Propósito Ejemplo
Preparar Crear estado inicial conocido. Crear usuario y producto con stock.
Ejecutar Disparar la integración. Confirmar compra.
Verificar Comprobar resultado esperado. Orden pagada y stock descontado.
Limpiar Eliminar residuos de la prueba. Borrar datos creados y vaciar mensajes.

30.6 Preparación del ambiente

La automatización depende de un ambiente que pueda prepararse de forma repetible. Si el ambiente requiere pasos manuales confusos, las pruebas automatizadas serán difíciles de ejecutar.

Conviene automatizar o documentar claramente:

  • Creación de base de datos de prueba.
  • Aplicación de migraciones.
  • Carga de datos semilla.
  • Inicio de servicios simulados.
  • Configuración de variables de entorno.
  • Limpieza de colas, archivos y cachés.

30.7 Datos de prueba automatizados

Las pruebas automatizadas deben crear o preparar sus datos de forma controlada. Depender de datos cargados manualmente vuelve frágil la suite.

Buenas prácticas:

  • Crear datos dentro de la prueba o mediante helpers.
  • Usar identificadores únicos.
  • Evitar modificar datos compartidos.
  • Preparar solo los datos necesarios.
  • Limpiar lo creado.
  • Usar datos ficticios y no sensibles.

30.8 Dependencias reales y simuladas

Una prueba automatizada debe indicar claramente qué dependencias usa. Algunas pueden ser reales de prueba y otras simuladas.

Ejemplos:

  • Base de datos real de prueba.
  • Proveedor de pagos simulado.
  • Correo falso que captura mensajes.
  • Cola local o de prueba.
  • Servicio externo en sandbox para pruebas específicas.

Cuanto más automatizada sea la prueba, más importante es controlar la disponibilidad de esas dependencias.

30.9 Verificaciones automatizadas

Una prueba automatizada debe comparar resultados reales contra resultados esperados de manera precisa.

Puede verificar:

  • Códigos o respuestas.
  • Registros en base de datos.
  • Estados finales.
  • Mensajes publicados.
  • Archivos generados.
  • Llamadas recibidas por servicios simulados.
  • Ausencia de efectos indebidos.

Las verificaciones demasiado genéricas pueden hacer pasar pruebas que no demostraron realmente la integración.

30.10 Limpieza automatizada

La limpieza debe formar parte de la automatización. Si una prueba deja datos residuales, puede afectar ejecuciones futuras.

La limpieza puede incluir:

  • Revertir transacciones.
  • Eliminar registros creados.
  • Vaciar colas.
  • Borrar archivos temporales.
  • Reiniciar servicios simulados.
  • Limpiar cachés.

Una buena prueba debe limpiar incluso cuando falla, siempre que la herramienta y el ambiente lo permitan.

30.11 Pruebas repetibles

Una prueba repetible puede ejecutarse varias veces con el mismo resultado esperado. Esta propiedad es esencial para automatización.

Señales de problemas de repetibilidad:

  • La prueba falla por datos duplicados.
  • Depende del orden de ejecución.
  • Depende de la hora actual sin control.
  • Depende de servicios externos inestables.
  • Deja archivos o mensajes de ejecuciones anteriores.

Si una prueba no es repetible, primero hay que estabilizarla antes de confiar en ella.

30.12 Pruebas deterministas

Una prueba determinista produce el mismo resultado cuando recibe las mismas condiciones iniciales. En integración esto puede ser difícil por tiempos, procesos asíncronos y dependencias externas.

Para mejorar determinismo:

  • Controlar datos iniciales.
  • Usar esperas controladas en procesos asíncronos.
  • Evitar dependencias externas reales innecesarias.
  • Fijar fechas o relojes cuando el tiempo afecta el resultado.
  • Usar identificadores únicos por ejecución.

30.13 Evidencia automática

Una prueba automatizada debe ayudar a diagnosticar cuando falla. Para eso puede capturar evidencia automáticamente.

Ejemplos:

  • Respuesta recibida.
  • Estado final consultado.
  • Logs relevantes.
  • Mensajes publicados.
  • Contenido de archivos generados.
  • Datos recibidos por un servicio simulado.

La evidencia debe ser suficiente para investigar sin exponer secretos o datos sensibles.

30.14 Ejecución local

Es útil que las pruebas de integración puedan ejecutarse localmente, al menos un subconjunto importante. Esto permite a los desarrolladores detectar problemas antes de subir cambios.

Para facilitar ejecución local:

  • Documentar comandos simples.
  • Usar configuración de prueba clara.
  • Reducir dependencias manuales.
  • Permitir levantar servicios simulados fácilmente.
  • Separar pruebas rápidas de pruebas más pesadas.

30.15 Ejecución automatizada en pipeline

Las pruebas de integración también pueden ejecutarse en un pipeline de integración continua. Esto permite detectar fallas después de cada cambio o antes de integrar una versión.

En un pipeline conviene cuidar:

  • Ambiente reproducible.
  • Datos limpios en cada ejecución.
  • Dependencias disponibles.
  • Tiempo de ejecución razonable.
  • Evidencia clara en caso de falla.
  • Separación entre pruebas críticas y pruebas más lentas.

Este curso no profundiza todavía en CI/CD, pero es importante entender que la automatización debe poder ejecutarse sin intervención manual.

30.16 Ejemplo: automatizar compra aprobada

Una prueba automatizada de compra aprobada podría seguir estos pasos:

Etapa Acción
Preparar Crear cliente activo y producto con stock 10.
Configurar Proveedor de pagos simulado devuelve aprobado.
Ejecutar Confirmar compra de 2 unidades.
Verificar Orden pagada, stock 8 y pago registrado.
Limpiar Eliminar orden, pago, producto y cliente creados.

30.17 Errores comunes

Al automatizar pruebas de integración, suelen aparecer errores como:

  • Automatizar antes de entender el escenario.
  • Depender de datos cargados manualmente.
  • No limpiar recursos creados.
  • Usar dependencias externas inestables para pruebas frecuentes.
  • Verificar resultados de forma demasiado superficial.
  • No capturar evidencia cuando falla.
  • Crear una suite tan lenta que nadie la ejecuta.

30.18 Lista de verificación

Antes de confiar en una prueba automatizada de integración, conviene revisar:

  • ¿El objetivo de la prueba está claro?
  • ¿El ambiente se prepara de forma repetible?
  • ¿Los datos iniciales son creados o controlados por la prueba?
  • ¿Las dependencias están disponibles o simuladas de forma confiable?
  • ¿Las verificaciones prueban el resultado importante?
  • ¿La limpieza está automatizada?
  • ¿La falla deja evidencia útil?

30.19 Qué debes recordar de este tema

  • Automatizar una prueba de integración implica preparar, ejecutar, verificar y limpiar.
  • Conviene automatizar primero escenarios críticos y repetitivos.
  • El ambiente debe ser reproducible y separado de producción.
  • Los datos de prueba deben ser controlados por la prueba o por helpers confiables.
  • Las pruebas automatizadas deben ser repetibles, deterministas y diagnosticables.
  • No todas las pruebas tienen que ejecutarse con la misma frecuencia.

30.20 Conclusión

La automatización básica de pruebas de integración permite verificar colaboraciones importantes de forma repetible. Bien diseñada, reduce riesgos y ayuda a detectar regresiones antes de que lleguen a etapas más costosas.

La clave es no automatizar por automatizar: cada prueba debe tener un objetivo claro, datos controlados, verificaciones útiles y limpieza confiable.

En el próximo tema veremos ejecución local y ejecución en entornos compartidos.