¿Cómo prueba la unidad \ usa los métodos TDD para ETL y proyectos de informes?

Los proyectos ETL son proyectos creados usando una herramienta ETL (Extraer - Transformar - Cargar) como SSIS, PowerCenter, etc.

Por lo general, esto implica leer datos de una fuente externa, cargarlos en una base de datos provisional, realizar ciertas transformaciones y cargarlos en una base de datos final

Un ejemplo simple sería usar SSIS para leer archivos de Excel proporcionados por maestros de escuela usando SSIS y cargarlos en una base de datos. Luego escriba procedimientos almacenados o más paquetes SSIS para calcular las calificaciones de cada estudiante y cargar esos datos en un data mart \ warehouse

Luego, crea procedimientos almacenados en la parte superior de la tienda para generar resultados que utilizan las herramientas de informes (SSRS \ Excel \ etc.) para generar visualizaciones.

Estoy tratando de entender cómo realizar TDD y pruebas de unidad adecuadas en este escenario. Las pruebas para ETL son principalmente para garantizar que los datos cargados en las tablas de preparación coincidan con el subconjunto correcto de los datos de la fuente. Entonces, implementar una prueba para esto lleva a implementar una versión mini del ETL. La salida de los SP del informe depende de los datos en las tablas mismas, por lo que no se puede tener un conjunto estable de datos de salida sin una pesadilla de mantenimiento, incluso si se crea una base de datos que contenga datos de prueba depurados

Ejemplo:

Sprint 1: la tabla del estudiante contiene Nombre, Edad, Grado

Crea datos de prueba para esta tabla y pruebas unitarias basadas en eso

Sprint 2: se agrega un campo de género a la tabla.

Ahora, si actualiza los datos en el campo del alumno para llenar el atributo de género, los casos de prueba se invalidan ya que los datos cambiaron. Y si no lo hace, no puede crear casos de prueba que requieran la columna de género

Lo que he hecho en el pasado es utilizar el desarrollo impulsado por la prueba de aceptación . El código ETL a menudo se distribuye a través de diferentes etapas / lenguajes y tecnologías Y está estrechamente acoplado. La mayoría de los procesos ETL dependen de la secuencia de transformaciones en la tubería.

El riesgo de usar la prueba unitaria solo en ETL es que no cubrirá las integraciones. La secuenciación de las transformaciones es una parte igual a las transformaciones reales en muchos ETL. Si estoy gastando recursos en la creación de un conjunto de pruebas automatizadas, me aseguraría de que también cubriera la secuencia.

Me centraría en TDD para cada secuencia de transformación única o al menos incluiría estas pruebas en un conjunto de pruebas más grande. Si hay demasiadas combinaciones, es posible que deba elegir qué secuencias probar. La idea es validar la tubería ETL para los conjuntos de datos en los que se utilizará. Además de asegurarse de tener cobertura de prueba en todo su código.

ETL se puede hacer con TDD y las pruebas son bastante similares a la mayoría de los proyectos, es decir

escriba una prueba que falla (rojo) corrija la falla (verde) haga que el código funcione y se pueda mantener (refactorizar)

Entonces, para ETL eso podría ser:

• escribir un script para cargar 1 registro
• fallar (sin fuente de datos definida)
• definir fuente [verde]
• no es necesario refactorizar
• escriba una prueba para cargar 1 registro con solo 1 campo completado
• fallar (no hay código escrito para ese campo)
• definir detalles de código para ese campo
• refactor
• defina pruebas fallidas que busquen atributos con valores válidos [rojo]
• etc.