No todas las integraciones ocurren mediante bases de datos, APIs o colas. Muchas aplicaciones también integran componentes a través de archivos, carpetas, almacenamiento externo, cachés, recursos compartidos o ubicaciones temporales.
Un sistema puede generar reportes, importar archivos, guardar imágenes, leer configuraciones, escribir logs, compartir documentos o procesar lotes de datos. Cada una de estas operaciones tiene riesgos de integración.
En este tema veremos cómo probar integraciones que involucran archivos, almacenamiento y recursos compartidos de forma segura y repetible.
En pruebas de integración, almacenamiento puede significar varios tipos de recursos:
Lo importante es que la aplicación lee o escribe información fuera de la memoria inmediata del proceso.
Las pruebas de integración con archivos y almacenamiento pueden verificar:
Las rutas de archivos suelen variar entre ambientes. Una ruta válida en desarrollo puede no existir en el ambiente de pruebas o puede apuntar a una ubicación incorrecta.
Conviene probar y configurar:
Las pruebas deben usar rutas de prueba, no carpetas productivas ni ubicaciones compartidas sin control.
Muchas integraciones comienzan leyendo un archivo. Por ejemplo, importar clientes desde CSV, procesar una planilla o leer un archivo de configuración.
Una prueba de integración puede verificar:
El objetivo es comprobar que el componente lector colabore correctamente con el resto del sistema y maneje errores sin dejar estados inconsistentes.
Otras integraciones generan archivos: reportes, comprobantes, exportaciones, logs de auditoría o archivos para otro sistema.
Una prueba puede verificar:
Si otro proceso depende del archivo generado, la prueba debe representar ese contrato de salida.
El formato del archivo es parte del contrato entre componentes. Puede tratarse de CSV, JSON, XML, texto plano, planillas u otros formatos.
Conviene revisar:
Un archivo puede existir y aun así ser inútil para el consumidor si su formato no respeta el contrato.
Los permisos son una fuente frecuente de errores. La aplicación puede funcionar en desarrollo y fallar en pruebas porque el usuario del proceso no tiene permisos para leer, escribir o borrar archivos.
Casos a considerar:
Una prueba de integración puede ayudar a detectar estos problemas temprano, siempre que el ambiente represente permisos realistas.
Los archivos temporales se usan para procesar datos intermedios. Deben manejarse con cuidado para no dejar residuos ni interferir con otras pruebas.
Buenas prácticas:
Un archivo temporal viejo puede hacer que una prueba lea datos incorrectos o falle por duplicados.
Un recurso compartido es usado por más de un componente, prueba o proceso. Puede ser una carpeta, un archivo, una caché, un bucket, una cola de archivos o una ubicación de intercambio.
Riesgos:
Los recursos compartidos requieren nombres únicos, aislamiento o limpieza controlada.
Cuando varios procesos acceden al mismo archivo o recurso, pueden aparecer problemas de concurrencia.
Ejemplos:
Las pruebas de integración pueden incluir escenarios donde el recurso no está disponible o está parcialmente preparado.
El almacenamiento externo puede ofrecer APIs o servicios para subir, descargar y eliminar archivos. En pruebas, debemos decidir si usar un ambiente real de prueba, una simulación o una implementación local.
| Enfoque | Ventaja | Cuidado |
|---|---|---|
| Almacenamiento real de prueba | Mayor realismo. | Puede tener costos, permisos y limpieza más compleja. |
| Simulación | Permite controlar errores y respuestas. | Debe respetar el contrato real. |
| Filesystem local | Simple y rápido para muchos casos. | Puede no representar permisos o comportamiento del proveedor real. |
La limpieza es fundamental. Una prueba que genera archivos debe eliminarlos o usar una ubicación aislada que pueda descartarse.
Conviene definir:
En almacenamiento externo, también puede ser necesario limpiar objetos antiguos para evitar costos o interferencias.
Verificar contenido es más importante que verificar solo existencia. Si una exportación genera un archivo vacío, la prueba no debería pasar solo porque el archivo fue creado.
Se puede verificar:
Supongamos una integración que importa clientes desde un archivo CSV y los guarda en la base de datos.
| Paso | Qué se verifica |
|---|---|
| Preparar archivo CSV válido. | El formato de entrada es reconocido. |
| Ejecutar importación. | El proceso lee el archivo y transforma datos. |
| Consultar base de datos. | Los clientes fueron guardados correctamente. |
| Probar archivo inválido. | El proceso informa error y no deja datos inconsistentes. |
| Limpiar archivo y datos. | La prueba no afecta ejecuciones posteriores. |
En una exportación de reporte, la prueba puede preparar datos, ejecutar la generación y verificar el archivo producido.
Se debería comprobar:
Al probar archivos y almacenamiento, suelen aparecer errores como:
Antes de confiar en una prueba con archivos o almacenamiento, conviene revisar:
Las integraciones con archivos, almacenamiento y recursos compartidos son comunes y pueden producir fallas difíciles de diagnosticar si no se controlan rutas, permisos, contenido y limpieza.
Una prueba de integración útil debe verificar que los datos se lean o escriban correctamente, que los formatos respeten el contrato y que el ambiente no quede contaminado para futuras ejecuciones.
En el próximo tema veremos manejo de errores, timeouts y reintentos.