33. Buenas prácticas y errores comunes en pruebas de integración

33.1 Introducción

Después de estudiar componentes, contratos, ambientes, datos, dependencias, errores, automatización y reportes, conviene reunir las ideas principales en forma de buenas prácticas.

Las pruebas de integración pueden aportar mucha confianza, pero también pueden volverse lentas, frágiles y difíciles de mantener si se diseñan sin criterio.

En este tema repasaremos recomendaciones prácticas y errores comunes para construir una suite de integración útil.

33.2 Buena práctica: definir un objetivo claro

Cada prueba de integración debe tener un objetivo concreto. Debe quedar claro qué colaboración se está verificando.

Ejemplos de objetivos claros:

• Crear orden válida debe persistir orden e ítems.
• Pago rechazado no debe descontar stock.
• Evento de orden creada debe incluir campos obligatorios.
• Archivo CSV inválido debe rechazar importación.

Si el objetivo no puede explicarse en una frase, probablemente la prueba esté intentando cubrir demasiado.

33.3 Error común: probar todo en una sola prueba

Una prueba demasiado grande puede fallar por muchas razones distintas. Esto dificulta el diagnóstico y vuelve la suite lenta.

Señales de este problema:

• La prueba involucra muchos flujos no relacionados.
• Requiere demasiada preparación.
• Cuando falla, no se sabe qué componente causó el problema.
• Repite lo que debería cubrir una prueba end-to-end.

33.4 Buena práctica: controlar el estado inicial

La prueba debe saber en qué estado comienza. Esto incluye datos, archivos, colas, cachés, servicios simulados y configuración.

Recomendaciones:

• Preparar datos necesarios dentro de la prueba o con helpers confiables.
• Evitar depender de datos manuales.
• Usar identificadores únicos.
• Limpiar recursos antes o después según corresponda.
• Evitar que el resultado dependa del orden de ejecución.

33.5 Error común: datos compartidos sin control

Usar los mismos datos para muchas pruebas puede parecer práctico, pero suele generar interferencias.

Problemas frecuentes:

• Una prueba modifica datos que otra necesita.
• Aparecen duplicados de ejecuciones anteriores.
• La prueba pasa sola y falla en suite completa.
• El diagnóstico se complica porque no se sabe quién cambió el dato.

Los datos compartidos deben limitarse a catálogos estables o datos que ninguna prueba modifica.

33.6 Buena práctica: limpiar lo que se crea

Las pruebas de integración suelen crear registros, archivos, mensajes o estados temporales. Si no se limpian, contaminan el ambiente.

La limpieza puede incluir:

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

33.7 Error común: verificar solo la respuesta

En integración, una respuesta exitosa no siempre garantiza que el sistema quedó bien. Puede haber datos mal guardados, eventos no publicados o efectos secundarios incorrectos.

Además de la respuesta, conviene verificar:

• Estado persistido.
• Mensajes publicados.
• Archivos generados.
• Llamadas a dependencias simuladas.
• Ausencia de efectos indebidos.

33.8 Buena práctica: probar errores importantes

Las pruebas de integración deben cubrir errores relevantes, no solo caminos exitosos.

Escenarios importantes:

• Datos inválidos.
• Dependencia no disponible.
• Timeout.
• Respuesta externa rechazada.
• Mensaje duplicado.
• Falla de persistencia.

Probar errores ayuda a detectar cambios parciales, reintentos peligrosos y errores silenciosos.

33.9 Error común: simular demasiado

Simular dependencias puede ser útil, pero si se simula todo, la prueba puede dejar de verificar integración real.

Riesgos:

• Falsa confianza.
• Contratos simulados desactualizados.
• Errores reales ocultos.
• Pruebas que no detectan configuración incorrecta.

Conviene mantener una estrategia mixta: algunas dependencias simuladas para control y algunas reales de prueba para realismo.

33.10 Buena práctica: mantener dobles alineados

Si se usan stubs, fakes o servicios simulados, deben representar el contrato relevante de la dependencia real.

Recomendaciones:

• Actualizar dobles cuando cambia el contrato.
• Incluir respuestas de error.
• Validar solicitudes recibidas.
• Evitar respuestas siempre perfectas.
• Comparar periódicamente con sandbox o servicio real si es crítico.

33.11 Buena práctica: usar nombres descriptivos

El nombre de una prueba debe explicar qué escenario cubre.

Buenos ejemplos:

• Compra aprobada debe descontar stock y registrar pago.
• Pago rechazado no debe publicar evento de orden confirmada.
• CSV sin email debe rechazar importación.
• Evento duplicado no debe crear notificación duplicada.

Los nombres genéricos como “test integración 1” no ayudan a mantener la suite.

33.12 Error común: pruebas intermitentes ignoradas

Una prueba intermitente es una prueba que a veces pasa y a veces falla sin cambios claros en el código. Ignorarla es peligroso.

Causas frecuentes:

• Dependencia externa inestable.
• Falta de limpieza.
• Datos compartidos.
• Procesos asíncronos con esperas mal diseñadas.
• Pruebas en paralelo sin aislamiento.

Una prueba intermitente debe investigarse, estabilizarse o retirarse temporalmente con justificación.

33.13 Buena práctica: capturar evidencia útil

Cuando una prueba falla, debe ayudar a diagnosticar. Para eso conviene capturar evidencia enfocada.

Puede incluir:

• Resultado esperado y obtenido.
• Logs relevantes.
• Estado final consultado.
• Mensajes publicados.
• Respuesta de dependencias.
• Identificador de correlación.

La evidencia debe ser suficiente, pero no debe exponer secretos o datos sensibles.

33.14 Buena práctica: priorizar por riesgo

Las pruebas de integración suelen costar más que las unitarias. Por eso deben priorizarse por riesgo e impacto.

Prioriza integraciones donde:

• Una falla afecta dinero, datos críticos o usuarios.
• Hay varias dependencias conectadas.
• El contrato cambia con frecuencia.
• Hubo defectos anteriores.
• El diagnóstico sería difícil si falla tarde.

33.15 Error común: duplicar cobertura sin valor

Una suite puede crecer con pruebas muy parecidas que no agregan nueva información.

Señales:

• Varias pruebas verifican el mismo camino con datos casi iguales.
• Reglas simples ya cubiertas por unitarias se repiten en integración.
• Pruebas lentas agregan poca cobertura de riesgo.
• Nadie sabe qué prueba eliminar porque no hay trazabilidad.

Más pruebas no siempre significa más confianza. Importa la calidad de los escenarios elegidos.

33.16 Tabla de buenas prácticas y errores

La siguiente tabla resume algunas relaciones importantes:

33.17 Lista de verificación

Para revisar una suite de pruebas de integración, podemos preguntar:

• ¿Cada prueba tiene un objetivo claro?
• ¿Los datos iniciales están controlados?
• ¿Las pruebas limpian lo que crean?
• ¿Se verifican respuestas y estados finales?
• ¿Se cubren errores importantes?
• ¿Las dependencias simuladas están alineadas con contratos reales?
• ¿Las pruebas fallidas dejan evidencia útil?
• ¿La suite prioriza integraciones de mayor riesgo?

33.18 Qué debes recordar de este tema

• Las pruebas de integración deben tener objetivo, alcance y datos claros.
• El estado inicial y la limpieza son claves para evitar pruebas inestables.
• Verificar solo la respuesta suele ser insuficiente.
• Los errores importantes deben probarse, no solo los caminos felices.
• Simular dependencias es útil, pero debe hacerse con criterio.
• Una suite valiosa prioriza riesgos y facilita el diagnóstico.

33.19 Conclusión

Las buenas prácticas en pruebas de integración buscan equilibrio: suficiente realismo para detectar errores importantes, suficiente control para repetir las pruebas y suficiente claridad para diagnosticar fallas.

Evitar errores comunes permite que la suite siga siendo útil a medida que el sistema crece.

En el próximo tema cerraremos el curso con un caso práctico integrador: probar la colaboración entre componentes.