31. Ejecución local y ejecución en entornos compartidos

31.1 Introducción

Las pruebas de integración pueden ejecutarse en distintos lugares. Algunas se ejecutan en la computadora del desarrollador, otras en un ambiente compartido por el equipo y otras en procesos automatizados.

Cada contexto tiene ventajas y riesgos. Ejecutar localmente facilita depurar rápido. Ejecutar en un entorno compartido permite acercarse más a una configuración común, pero puede introducir interferencias entre usuarios o pruebas.

En este tema compararemos ejecución local y entornos compartidos para entender cómo usarlos de forma efectiva.

31.2 Qué significa ejecutar localmente

Ejecutar localmente significa correr las pruebas en la computadora de una persona del equipo. La aplicación, base de datos, servicios simulados y otros recursos pueden estar instalados o levantados en ese mismo entorno.

La ejecución local permite:

• Probar cambios antes de compartirlos.
• Depurar con mayor facilidad.
• Ejecutar un subconjunto de pruebas rápidamente.
• Modificar datos y configuración sin afectar a otros.
• Reproducir fallas específicas.

31.3 Ventajas de la ejecución local

La ejecución local tiene varias ventajas prácticas:

• Feedback rápido durante el desarrollo.
• Mayor control sobre datos y dependencias.
• Facilidad para usar depuradores y logs detallados.
• Menor interferencia con otros integrantes del equipo.
• Posibilidad de ejecutar pruebas individuales.

Cuando una prueba falla localmente, suele ser más fácil detener el proceso, inspeccionar estado y repetir el escenario.

31.4 Riesgos de la ejecución local

La ejecución local también tiene riesgos. Si cada persona tiene configuraciones distintas, una prueba puede pasar en una computadora y fallar en otra.

Problemas frecuentes:

• Versiones distintas de base de datos o servicios.
• Variables de entorno diferentes.
• Migraciones no aplicadas.
• Datos locales viejos o contaminados.
• Dependencias no instaladas.
• Rutas de archivos específicas de una máquina.

Para que la ejecución local sea útil, debe ser fácil de preparar y reproducir.

31.5 Qué es un entorno compartido

Un entorno compartido es un ambiente usado por varias personas, procesos o equipos. Puede ser un ambiente de pruebas, integración, staging o similar.

Puede incluir:

• Aplicaciones desplegadas.
• Bases de datos compartidas.
• Servicios internos reales.
• Colas y recursos de infraestructura.
• Configuración parecida a otros ambientes.
• Datos comunes de prueba.

Estos entornos sirven para validar integraciones en un contexto más parecido al del equipo completo.

31.6 Ventajas de los entornos compartidos

Los entornos compartidos ofrecen ventajas importantes:

• Permiten probar con servicios desplegados.
• Revelan problemas de configuración común.
• Facilitan pruebas entre componentes de distintos equipos.
• Se parecen más a un flujo integrado real.
• Ayudan a validar dependencias que no existen localmente.

Son especialmente útiles cuando la integración depende de infraestructura que sería costosa o compleja de reproducir en cada computadora.

31.7 Riesgos de los entornos compartidos

El principal riesgo de un entorno compartido es la interferencia. Varias personas o pruebas pueden modificar los mismos datos o recursos.

Problemas frecuentes:

• Datos cambiados por otra prueba.
• Servicios desplegados en versiones incompatibles.
• Ambiente parcialmente caído.
• Colas con mensajes de otras ejecuciones.
• Archivos residuales.
• Dificultad para saber quién modificó algo.

Estos problemas pueden producir fallas que no corresponden al código probado.

31.8 Comparación general

La siguiente tabla resume diferencias:

31.9 Configuración local reproducible

Para que la ejecución local sea útil, el ambiente debe poder reproducirse con pasos claros.

Buenas prácticas:

• Documentar comandos de preparación.
• Usar configuración de prueba separada.
• Automatizar migraciones.
• Levantar servicios simulados de forma simple.
• Usar datos semilla conocidos.
• Evitar rutas absolutas propias de una persona.

Si preparar el ambiente local requiere conocimiento informal, las pruebas serán difíciles de adoptar.

31.10 Datos en entornos compartidos

Los datos compartidos deben manejarse con cuidado. Si todos usan los mismos registros, las pruebas pueden interferirse.

Opciones para reducir problemas:

• Usar datos propios por prueba.
• Usar prefijos o identificadores únicos.
• Separar datos por equipo o ejecución.
• Limpiar datos generados.
• Evitar modificar datos semilla comunes.
• Restaurar el ambiente en momentos definidos.

31.11 Versiones de servicios

En entornos compartidos, distintos servicios pueden estar desplegados en versiones diferentes. Esto puede producir fallas de integración por incompatibilidad.

Conviene saber:

• Qué versión de cada servicio está desplegada.
• Qué cambios de contrato incluye cada versión.
• Qué pruebas dependen de esos contratos.
• Si hay despliegues en curso durante la ejecución.
• Cómo revertir o estabilizar el ambiente si una versión falla.

Una prueba puede fallar porque el ambiente tiene versiones incompatibles, no porque el cambio local sea incorrecto.

31.12 Aislamiento en ambiente compartido

El aislamiento es más difícil en ambientes compartidos, pero sigue siendo necesario.

Estrategias:

• Crear recursos por ejecución.
• Usar bases o esquemas separados cuando sea posible.
• Usar colas con nombres específicos para pruebas.
• Separar archivos por carpeta o prefijo.
• Limpiar datos al finalizar.
• Evitar pruebas paralelas sobre los mismos recursos.

31.13 Diagnóstico en entornos compartidos

Diagnosticar una falla en un entorno compartido puede requerir más evidencia porque intervienen más factores.

Conviene registrar:

• Versión de servicios usados.
• Identificador de ejecución.
• Datos creados por la prueba.
• Configuración relevante.
• Mensajes publicados.
• Hora aproximada de ejecución.

Esta información ayuda a distinguir fallas reales de interferencias del entorno.

31.14 Qué ejecutar localmente

Conviene que localmente se puedan ejecutar pruebas que dan feedback rápido y cubren colaboraciones importantes.

Buenos candidatos:

• Integración servicio-repositorio-base de datos de prueba.
• Pruebas con servicios externos simulados.
• Validación de contratos internos simples.
• Procesamiento de archivos con carpetas temporales.
• Casos críticos que no requieren infraestructura pesada.

31.15 Qué ejecutar en entorno compartido

En entornos compartidos conviene ejecutar pruebas que necesitan componentes desplegados o infraestructura común.

Buenos candidatos:

• Integración entre servicios de distintos equipos.
• Validación de configuración compartida.
• Pruebas contra servicios internos reales.
• Pruebas con colas o almacenamiento del ambiente.
• Validaciones previas a una entrega.

Estas pruebas deben diseñarse para minimizar interferencias y dejar evidencia clara.

31.16 Ejemplo de estrategia mixta

Para una funcionalidad de compras, una estrategia podría ser:

31.17 Errores comunes

Al ejecutar pruebas localmente o en entornos compartidos, suelen aparecer errores como:

• Asumir que todos tienen la misma configuración local.
• Depender de datos manuales en ambiente compartido.
• No saber qué versión está desplegada.
• Ejecutar pruebas destructivas sobre recursos compartidos.
• No limpiar datos generados.
• No capturar evidencia suficiente en fallas compartidas.
• Usar el entorno compartido para todo, incluso cuando una prueba local sería suficiente.

31.18 Lista de verificación

Antes de ejecutar pruebas de integración, conviene revisar:

• ¿La prueba está pensada para local o compartido?
• ¿La configuración del ambiente es clara?
• ¿Los datos están aislados?
• ¿Se conocen las versiones de servicios involucrados?
• ¿La prueba limpia lo que crea?
• ¿Hay riesgo de interferir con otras personas o procesos?
• ¿La falla dejará evidencia suficiente para diagnosticar?

31.19 Qué debes recordar de este tema

• La ejecución local da feedback rápido y facilita el diagnóstico.
• Los entornos compartidos dan más realismo, pero agregan riesgo de interferencia.
• La configuración local debe ser reproducible.
• Los datos compartidos deben aislarse o limpiarse cuidadosamente.
• Las versiones de servicios importan en fallas de integración.
• Una estrategia práctica combina pruebas locales, compartidas y automatizadas según el riesgo.

31.20 Conclusión

Ejecutar pruebas de integración en el lugar adecuado mejora la velocidad y la confiabilidad del proceso. Las pruebas locales ayudan a detectar problemas temprano; las pruebas en entornos compartidos permiten validar colaboraciones más realistas.

La clave es elegir el contexto según el objetivo de la prueba, controlar datos y configuración, y evitar interferencias que hagan perder confianza en los resultados.

En el próximo tema veremos criterios de finalización y reporte de resultados.