Una Perspectiva Práctica para Probar Pipelines de Extracción y Carga

En mi trayectoria como ingeniero de datos, he visto de todo: pipelines que funcionan como relojes suizos, y otros que parecen hechos con cinta adhesiva y buenas intenciones.

Y aunque la tecnología y los paradigmas han evolucionado (el cambio de ETL a ELT es un buen ejemplo), hay algo que sigue siendo una constante: las pruebas en los procesos de datos son un dolor de cabeza. Hoy quiero compartir contigo una estrategia que me ha resultado útil a la hora de escribir pruebas relevantes y efectivas.

El Problema: Testear lo que de verdad importa

Uno de los errores más comunes que he visto en los pipelines de EL (Extract & Load), es caer en la trampa de las pruebas redundantes. ¿Te suena esto? Creas pruebas funcionales que simulan datos específicos para validar configuraciones concretas. Por ejemplo, imagina un pipeline con esta configuración:

[
  {"table_name": "invoices", "columns": {"id": "integer", "amount": "float"}},
  {"table_name": "employees", "columns": {"id": "integer", "name": "str"}}
]

Y entonces, te pones a escribir pruebas que verifican si las tablas se crean correctamente usando una muestra de datos obtenida de la API y añadiendo un mock de la API. Suena bien, ¿no? Pues no tanto. Este enfoque tiene más agujeros que un queso suizo:

Dependencia de la API: Si la API cambia, tus pruebas se vuelven obsoletas. Y algunas APIs cambian más que el estado de ánimo de un adolescente.
Escaso Valor Añadido: Estas pruebas no te protegen de errores en la configuración, como valores incorrectos o tipos de datos mal mapeados, ya que se limitan a validar una muestra muy reducida de datos (¿Qué hace este null en este campo en la página 145 de la llamada?).
Mantenimiento Innecesario: Cada vez que cambia la configuración (por ejemplo, añadir una columna nueva), tienes que reescribir las pruebas. ¿Y para qué? Para validar algo que probablemente ya sabes que funciona.

Lo Que Realmente Deberías Probar: Menos Es Más

Con la experiencia he aprendido que no todas las pruebas son iguales. Algunas son esenciales, y otras nos pueden dar una falsa sensación de seguridad. Aquí te propongo un enfoque práctico, dividido en cuatro niveles:

1. Pruebas Unitarias

Estas pruebas son como el cinturón de seguridad de tu pipeline. Verifican que los componentes individuales funcionan como deberían. Por ejemplo:

¿Puede tu función mapear correctamente los tipos de datos de la configuración a tipos compatibles con la base de datos? Por ejemplo, ¿Convierte str en VARCHAR(255) correctamente?
¿Se manejan correctamente los errores si la configuración está mal formada? Por ejemplo, ¿Qué pasa si el nombre de una tabla incluye caracteres especiales?

No son glamurosas, pero son tu primera línea de defensa. Si fallan, sabes que el problema está en el código, no en la configuración.

2. Pruebas Funcionales Genéricas

Aquí es donde empiezas a ganar tiempo. En lugar de probar configuraciones específicas, te centras en lo genérico. Consideremos una configuración genérica como esta:

{"table_name": "generic_table", "columns": {"col1": "integer", "col2": "string"}}

Con esta configuración, podrías probar las siguientes funcionalidades:

Creación de Tablas: ¿Puede tu pipeline crear una tabla nueva si no existe? ¿Se crea generic_table con las columnas col1 (integer), col2 (string), etc.?
Validación de Tipos: ¿Se aplican correctamente los tipos de datos definidos (e.g., integer, string, float)? Si cambias col3 de float a string, ¿el pipeline actualiza la tabla sin borrar datos históricos?
Actualizaciones/Reemplazos: ¿Puede tu pipeline manejar actualizaciones o reemplazos de tablas? ¿Funciona el upsert cuando hay claves duplicadas? ¿El replace elimina registros antiguos correctamente?

Estas pruebas cubren los mismos casos que configuraciones específicas (invoices, employees, etc.). Es como probar un molde para galletas en lugar de cada galleta individual.

3. Pruebas de Integración

Este es el nivel donde te aseguras de que todo funciona en conjunto. Aquí validas:

Extracción de datos: ¿La API devuelve los datos esperados con la configuración actual?
Interoperabilidad: ¿Funcionan bien juntas las configuraciones de extracción y carga? ¿Se escriben los datos en el formato correcto?

Estas pruebas son como el ensayo general antes del concierto. Si todo va bien aquí, es probable que tu pipeline funcione en producción.

Pero ojo: Las pruebas de interoperabilidad en un entorno de CI/CD pueden volverse complejas. En mi experiencia, probar el pipeline en un entorno de pruebas (como una instancia dedicada de Airflow, y una bases de datos de prueba) funcionan bien para este tipo de comprobaciones.

4. Pruebas de calidad del dato

Comprobar la calidad de los datos es la última pieza de este rompecabezas, y hay varias herramientas que nos pueden ayudar con este objetivo. Veamos dos enfoques complementarios:

Pruebas Pre-Carga con Great Expectations: Si necesitas detectar problemas antes de que los datos lleguen al data warehouse, Great Expectations es tu aliado. Con esta herramienta puedes validar numerosos aspectos de la calidad de los datos y generar documentación. Por ejemplo, para el dataset de invoices, podrías evaluar que la cantidad total se encuentra en un cierto rango, que los impuestos aplicados son de un determinado porcentaje, o que se ha creado en un determinado rango de fechas.

Pruebas Post-Carga con dbt y Elementary: En la fase de transformación, dbt y Elementary te permiten ir un poco más allá (por ejemplo, añadiendo tests de anomalías de volumen, outliers, etc.) e integrarlo con tus modelos que encapsulan la lógica de negocio. En mi experiencia, es en la fase de transformación cuando realmente se tiene la información suficiente para hacer pruebas de calidad de datos que sean relevantes.

Conclusión: Menos Pruebas, Más Valor

Al final del día, el objetivo no es escribir más pruebas, sino escribir mejores pruebas. Crear pruebas efectivas en pipelines de EL consiste en encontrar un equilibrio entre cobertura, mantenibilidad y valor práctico. Priorizar lo genérico sobre lo específico no solo te ahorra tiempo, sino que también te da la tranquilidad de saber que tu pipeline es robusto y confiable.

Happy testing!