11. Configuración, variables de entorno y dependencias externas

11.1 Introducción

Muchas fallas de integración no ocurren por errores en la lógica del programa, sino por problemas de configuración. Una URL incorrecta, una variable de entorno ausente, una credencial vencida o una dependencia externa mal apuntada pueden hacer fallar un flujo completo.

Las pruebas de integración deben ejecutarse en un ambiente donde la configuración sea clara, controlada y separada de producción. Además, deben permitir comprobar cómo se comporta el sistema cuando una dependencia externa responde correctamente, falla o no está disponible.

En este tema veremos cómo organizar configuración, variables de entorno y dependencias externas para reducir errores y obtener pruebas más confiables.

11.2 Qué entendemos por configuración

La configuración es el conjunto de valores que permiten que una aplicación se ejecute en un ambiente determinado. Estos valores pueden cambiar entre desarrollo, pruebas, staging y producción.

Ejemplos de configuración:

• URL de una API.
• Cadena de conexión a la base de datos.
• Puerto donde escucha un servicio.
• Nombre de una cola de mensajes.
• Ruta de una carpeta temporal.
• Credenciales de acceso.
• Tiempo máximo de espera para una llamada externa.
• Opciones para activar o desactivar funcionalidades.

En integración, la configuración importa porque define con qué recursos reales o simulados se conectan los componentes.

11.3 Variables de entorno

Una variable de entorno es un valor que se define fuera del código y que la aplicación puede leer al ejecutarse. Se usan mucho para configurar aplicaciones sin modificar el código fuente.

Por ejemplo, una aplicación puede leer variables como:

• DATABASE_URL: dirección de la base de datos.
• PAYMENTS_API_URL: URL del servicio de pagos.
• MAIL_ENABLED: indica si se enviarán correos reales.
• QUEUE_NAME: nombre de la cola usada para eventos.
• REQUEST_TIMEOUT: tiempo máximo de espera para llamadas externas.

Las variables de entorno son útiles, pero deben manejarse con orden. Si faltan, tienen nombres distintos o apuntan al lugar incorrecto, las pruebas pueden fallar de forma confusa.

11.4 Configuración por ambiente

Una aplicación suele ejecutarse en varios ambientes. Cada ambiente necesita valores propios.

Las pruebas de integración deben usar configuración de prueba. Usar valores de producción por error puede causar daños reales.

11.5 Errores frecuentes de configuración

Los errores de configuración suelen ser simples, pero su impacto puede ser alto.

Ejemplos frecuentes:

• Una variable de entorno no existe.
• La variable existe, pero tiene un valor vacío.
• El nombre de la variable está mal escrito.
• La aplicación apunta a una base de datos de otro ambiente.
• El timeout es demasiado bajo para una dependencia real.
• Una cola usa el mismo nombre que producción.
• Un archivo de configuración local no fue actualizado.

Una prueba de integración puede detectar estos problemas cuando intenta conectar componentes en condiciones controladas.

11.6 Validar configuración al inicio

Una buena práctica es validar la configuración al iniciar la aplicación o antes de ejecutar la suite de pruebas. Esto permite fallar rápido con un mensaje claro si falta algo importante.

Conviene validar:

• Variables obligatorias presentes.
• Valores no vacíos.
• URLs con formato válido.
• Números dentro de rangos permitidos.
• Opciones booleanas reconocidas.
• Ambiente declarado correctamente como prueba.

11.7 Secretos y credenciales

Algunas configuraciones contienen información sensible, como contraseñas, tokens o claves de API. Esos valores deben tratarse como secretos.

Cuidados importantes:

• No guardar secretos reales en archivos públicos del repositorio.
• Usar credenciales específicas para ambientes de prueba.
• Rotar credenciales si fueron expuestas.
• Evitar imprimir secretos completos en logs.
• Separar permisos de prueba y producción.
• Usar proveedores de secretos cuando el proyecto lo requiera.

Una prueba de integración no debería necesitar credenciales productivas para verificar el comportamiento del sistema.

11.8 Dependencias externas

Una dependencia externa es un sistema fuera del componente o de la aplicación que estamos probando, pero que participa en el flujo. Puede pertenecer a otro equipo, a otra empresa o a una infraestructura compartida.

Ejemplos:

• Pasarela de pagos.
• Servicio de correo.
• Proveedor de identidad.
• API de facturación.
• Servicio de mapas o geolocalización.
• Almacenamiento externo.
• Colas administradas por otra plataforma.

Estas dependencias agregan riesgo porque no siempre están bajo control directo del equipo que escribe la prueba.

11.9 Formas de tratar dependencias externas

Hay varias formas de trabajar con dependencias externas en pruebas de integración:

11.10 Riesgos de usar servicios reales

Usar servicios reales puede aumentar la confianza, pero también tiene riesgos:

• La prueba puede fallar porque el proveedor está caído.
• La ejecución puede ser lenta.
• Puede haber costos por uso.
• Los datos enviados pueden quedar registrados fuera del ambiente.
• El proveedor puede tener límites de llamadas.
• La respuesta puede variar sin control del equipo.

Por eso, antes de usar un servicio real, conviene preguntarse si realmente forma parte del objetivo de esa prueba.

11.11 Riesgos de simular demasiado

Simular dependencias permite controlar la prueba, pero si simulamos demasiado podemos perder realismo. Una simulación mal diseñada puede aceptar datos que el servicio real rechazaría o devolver respuestas que nunca ocurren.

Riesgos de simular en exceso:

• Contratos desactualizados.
• Respuestas demasiado perfectas.
• Errores reales no representados.
• Diferencias en formatos o códigos de estado.
• Falsa confianza sobre una integración externa.

La simulación debe mantenerse alineada con el contrato real de la dependencia.

11.12 Timeouts, reintentos y circuit breakers

Las dependencias externas pueden tardar, fallar o responder de forma intermitente. Por eso la configuración suele incluir timeouts, reintentos y mecanismos de protección.

En una prueba de integración puede ser útil verificar:

• Qué ocurre si una dependencia no responde a tiempo.
• Cuántos reintentos se realizan.
• Si se evita repetir operaciones peligrosas.
• Qué respuesta recibe el componente consumidor.
• Si el sistema registra información suficiente para diagnosticar el problema.

Estos casos ayudan a comprobar que la integración no solo funciona en el camino exitoso.

11.13 Configuración segura para pruebas

Un ambiente de pruebas debe estar protegido contra errores peligrosos. Algunas medidas útiles son:

• Bloquear URLs productivas cuando el modo de ejecución es prueba.
• Usar nombres de bases de datos claramente identificables.
• Prefijar colas o recursos con nombres de ambiente.
• Desactivar envíos reales de correos cuando no sean necesarios.
• Usar cuentas de prueba sin permisos productivos.
• Validar que el ambiente declarado sea coherente con los recursos usados.

Estas medidas reducen el riesgo de que una prueba modifique o invoque recursos reales accidentalmente.

11.14 Ejemplo de configuración para una prueba

Supongamos una prueba de integración para confirmar una compra. Una configuración de prueba podría ser:

11.15 Lista de verificación

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

• ¿Todas las variables obligatorias están definidas?
• ¿Los valores apuntan al ambiente de prueba?
• ¿Las credenciales tienen permisos limitados?
• ¿Las dependencias externas reales son necesarias para este caso?
• ¿Las simulaciones respetan el contrato esperado?
• ¿Los timeouts y reintentos tienen valores razonables?
• ¿Los logs ocultan secretos y muestran errores útiles?

11.16 Qué debes recordar de este tema

• Muchos errores de integración nacen en la configuración, no en la lógica del código.
• Las variables de entorno permiten separar valores por ambiente, pero deben validarse.
• Las pruebas de integración deben usar recursos de prueba, no productivos.
• Las dependencias externas pueden ser reales, sandbox, simuladas o fakes locales.
• Simular dependencias mejora el control, pero debe mantenerse alineado con el contrato real.
• La configuración segura evita efectos secundarios peligrosos durante las pruebas.

11.17 Conclusión

La configuración, las variables de entorno y las dependencias externas son puntos críticos en las pruebas de integración. Si no se controlan bien, pueden generar fallas difíciles de interpretar o, peor aún, efectos sobre recursos reales.

Un ambiente bien configurado permite ejecutar pruebas repetibles, seguras y útiles para detectar problemas de colaboración entre componentes.

En el próximo tema trabajaremos sobre datos de prueba para integración, otro elemento esencial para obtener resultados confiables.