El testing es un punto clave en cualquier proceso de ingeniería de datos. Nos permite validar que los datos que estamos generando o transformando cumplen con las expectativas definidas en cada etapa. Además, contribuye a garantizar la robustez del sistema, pues facilita la detección de incoherencias, errores o anomalías que podrían hacer que el resto del modelo no se ejecute correctamente.
Ahora bien, más allá de ejecutar pruebas puntuales sobre nuestros modelos, es importante comprender que existen distintas metodologías de testing. Cada una de ellas posee su propio enfoque, profundidad y momento de aplicación. Por eso, elegir la estrategia adecuada es vital para obtener un sistema confiable.
Aunque esto se puede aplicar a casi cualquier proceso y tecnología, en este post nos centraremos en su implementación con DBT, una de las herramientas más populares para la transformación de datos mediante SQL.
Tipos de test en DBT
Si nos fijamos en la documentación oficial, vemos que en DBT existen principalmente dos tipos de pruebas, los test de datos y los test unitarios.
Test unitarios en DBT
Los test unitarios son pruebas pensadas para validar la lógica de transformación de un modelo de forma aislada. En este sentido, no dependen de los datos reales del data warehouse. Esto hace que esta clase de pruebas sean especialmente útiles para validar escenarios poco frecuentes y para asegurarse de que cambios en la lógica no rompen el comportamiento previo que teníamos en el código.
Este tipo de test, aunque muy útiles, suelen ser mucho más personalizados y específicos para cada caso de uso. Por esa razón, en este artículo, que pretende dar una información general de las diferentes metodologías de test, no profundizaremos en ellos.
Aún así, es importante mencionarlos porque representan un cambio relevante en la forma de validar modelos. Y, en una buena proporción, son algo imprescindible de aplicar en los modelos de DBT.
Test de datos en DBT
Los test de datos son validaciones que se ejecutan directamente sobre los resultados de tus modelos en el data warehouse. De esta manera, se verifica que los datos cumplen ciertas condiciones o reglas de negocio. El objetivo principal de este tipo de pruebas es garantizar la calidad y coherencia de la información. Se pueden categorizar en dos tipos:
- Test genéricos (también conocidos como built-in).
- Test personalizados (definidos mediante SQL a medida).
Cada uno de ellos tiene sus ventajas y limitaciones. Por eso, su elección dependerá del tipo de dato que estemos validando y del contexto del sistema. Así pues, comprender cuándo utilizar cada uno es clave para diseñar una estrategia de testing eficiente y mantenible.
Dicho esto, en el siguiente punto analizaremos las características de cada tipo de test y en qué escenario es más conveniente optar uno u otro.
Test genéricos en DBT
Los test genéricos en DBT se caracterizan por ser reutilizables y no estar ligados a una consulta SQL específica. Esta cualidad los hace especialmente relevantes para validar reglas comunes de calidad de datos.
A la hora de implementar este tipo de pruebas en DBT, existen dos aproximaciones.
Test integrados (built-in)
Estas pruebas son proporcionados de forma nativa por DBT y cubren los siguientes 4 usos:
- unique: valida que los valores de una columna no se repitan.
- not_null: comprueba que no haya valores nulos en una columna.
- accepted_values: revisa que los valores de una columna pertenezcan a una lista permitida.
- relationships: verifica la integridad referencial entre dos modelos (clave externa).
Test genéricos personalizados reutilizables con Jinja
Los test genéricos están generados con macros de Jinja y SQL, utilizadas como plantillas que pueden aplicarse en cualquier momento a cualquier modelo.
Sin embargo, hay un requisito mínimo que estas macros deben cumplir: aceptar al menos los argumentos models y column_name. Esto permite que la lógica de validación pueda ejecutarse en distintas tablas y columnas sin duplicar código.
Test personalizados en DBT
Los test personalizados son aquellos que se definen explícitamente mediante consultas SQL para cubrir una validación específica de una regla de negocio o para testear que se cumplen unos criterios de calidad determinados.
Estas pruebas, debido a su naturaleza, se han de construir siguiendo una serie de reglas.
- Estructura de consulta. El archivo SQL del test debe contener una consulta que seleccione únicamente las filas que no son capaces de pasar las reglas o condiciones definidas.
- Criterio de éxito. Para que la prueba se considere pasada, la consulta no debe devolver ninguna fila al ejecutarse.
- Criterio de fallo. Si la consulta devuelve una o más filas, el test se marcará como fallido y se mostrará el conjunto de registros que no han pasado la prueba. Esto es especialmente útil para poder depurar el código y ver qué registros no cumplen con las condiciones establecidas.
Como se puede observar, los test personalizados son muy útiles si se quiere validar que los datos obtenidos cumplen con todos los requisitos especificados. Además, sirven como consultas de control automático, aportando robustez a nuestro código.
Ubicación de los test de DBT en el flujo de trabajo
Una vez revisados los diferentes tipos de test que existen en DBT, el siguiente punto a considerar es el momento en el que se ejecutarán dentro de nuestro proceso. La ubicación de nuestros test puede modificar por completo la integración, la detección de errores y la forma en que gestionamos la calidad de los datos.
Teniendo esto en cuenta, se pueden establecer dos puntos en los que podemos introducir nuestras pruebas.
Test al final de la transformación
Siguiendo este enfoque, las pruebas se ejecutan una vez que el modelo haya finalizado todas las transformaciones y se encuentre materializado dentro del data warehouse.
No obstante, esta metodología también posee una serie de ventajas y de inconvenientes.
Ventajas
- Permite validar los procesos que dependen de datos completamente procesados para tener una visión global y coherente del resultado final.
- Facilita la detección de errores acumulados que pueden haberse introducido en pasos intermedios y que solo se manifiestan en la versión final del modelo.
Inconvenientes
- Uno de los principales problemas de ejecutar los test al final de las transformaciones es que si un error se origina en una etapa temprana, su detección tardía puede dificultar la depuración, obligando a revisar múltiples pasos del flujo para encontrar la causa.
- Además, esta búsqueda del fallo puede convertirse en un proceso costoso e ineficiente. Especialmente, en queries complejas que hacen agregaciones o dependen de diferentes tablas.
Test intermedios
Por otro lado, como su propio nombre indica, los test intermedios se ejecutan en etapas parciales de la transformación. Normalmente, sobre modelos temporales o tablas efímeras ubicadas en las capas de staging o intermediate.
Esto, al igual que en el caso anterior, presenta ventajas e inconvenientes.
Ventajas
- Aplicar los test en puntos intermedios permite una detección mucho más temprana de errores. Además, evita que los datos erróneos avancen a través de las transformaciones. Así pues, esta metodología puede llegar a ser mucho más eficiente en la depuración del código.
- Hace posible la aplicación de controles de calidad sobre los datos originales o poco transformados. Esta característica es especialmente relevante si el modelo tiene diferentes transformaciones a lo largo de todo el proceso.
Inconvenientes
- Sin embargo, aplicar las pruebas en puntos intermedios hace que el tiempo total de la ejecución se incremente sustancialmente. Esto se debe a que si tras cada transformación se ha de ejecutar la validación, prácticamente se están duplicando el número de consultas a realizar y, por tanto, aumenta significativamente el tiempo de ejecución.
- Por otro lado, se requiere una planificación mucho más detallada y una coordinación sustancialmente mayor. La consecuencia es que el proceso resulta algo más complejo.
- El tiempo de desarrollo también aumenta, pues se han de crear muchas más queries que evalúen los diferentes puntos críticos del modelo.
En definitiva, ambos enfoques presentan ventajas e inconvenientes que conviene valorar cuidadosamente. La elección entre uno u otro dependerá del contexto, lo crítico que sea mantener la veracidad de los datos y los objetivos del proyecto.
Aplicar el enfoque adecuado en cada caso aporta un nivel de robustez y control sobre la calidad de los datos que difícilmente se lograría sin estas validaciones.
Frecuencia y momento de ejecución
Otro punto importante respecto a las metodologías de testing en DBT es establecer con qué frecuencia y en qué momento se deben ejecutar. Esto afecta significativamente a la estrategia de ejecución, pues impacta directamente tanto en la velocidad de la pipeline como en la detección temprana de errores y en el coste computacional del mismo.
Dicho esto, vamos a ver tres momentos clave donde se pueden aplicar test con DBT.
Test automáticos en CI/CD
Los test automáticos CI/CD son uno de los enfoques más extendidos dentro de los test en general y de los de DBT en particular. En este contexto, las pruebas se ejecutan de manera automática cada vez que se propone un cambio en el código. O bien al realizar un pull request, o al hacer el mergeo a una rama específica (normalmente, main).
Este tipo de test tiene sus ventajas e inconvenientes, los cuales analizaremos a continuación.
Ventajas
- Sirven de firewall para que solo el código que haya pasado las validaciones pueda desplegarse y pasar a producción. Esto reduce el riesgo de generar bugs y pasarlos de un entorno a otro.
- Permiten detectar los fallos de forma temprana, antes de que se integren dentro de producción. Si los test no se pasan, el proceso de mergeo se detendrá, imposibilitando la incompatibilidad de código.
- Por último, tener integrado estrategias de testeo en el CI/CD permite que los desarrolladores pongan más atención en la calidad del código y de los datos que se obtienen, pues un error en los test no permitirá integrar el código desarrollado.
Inconvenientes
- El principal inconveniente es que implementar esta metodología requiere diseñar, configurar y mantener una infraestructura de CI/CD. Además, en caso de no estar alineada con el flujo de trabajo del equipo, puede incrementar el coste tanto tiempo como en recursos. Esto hace que se puedan perder parte de las ventajas que aporta la automatización de los test.
- En determinados proyectos o esquemas, no es viable introducir test unitarios en el pipeline de CI/CD, ya que su desarrollo e implementación puede incrementar considerablemente el esfuerzo de programación, haciendo que todo el proceso sea menos ágil.
Como se puede ver, la integración de test de CI/CD no solo aporta confianza en que los resultados obtenidos van a tener una serie de características esperadas, sino que también añade una capa adicional de seguridad. De esta manera, permiten que todo lo que se lleva a entornos productivos cumpla con unos estándares de calidad mínimos y claramente definidos. Por lo tanto, siempre que la infraestructura y el flujo de trabajo lo permitan, resulta altamente recomendable incorporar este tipo de validaciones extras.
Test manuales o exploratorios
Este tipo de enfoque es el más sencillo de todos y está pensado para ejecutarse durante el desarrollo del código. Está concebido para que los desarrolladores revisen de forma directa los resultados de un modelo, ejecutando consultas ad hoc, contrastando con fuentes externas o aplicando su conocimiento de negocio para detectar anomalías que difícilmente podrían capturarse con un test automatizado.
Las ventajas e inconvenientes de este enfoque de testeo son las siguientes:
Ventajas
- Permiten descubrir patrones inesperados o errores imprevistos en los test que han sido ya definidos.
- Proporcionan al desarrollador la capacidad de ir testeando diferentes modificaciones realizadas en el código sin la necesidad de tener que modificar las pruebas finales y con la flexibilidad de poder cambiarlo rápidamente según las necesidades.
Inconvenientes
- Por la naturaleza de estos test, no son fácilmente reproducibles ni aplicables a otras partes del código. Es el desarrollador el que los ejecuta, teniendo en cuenta su conocimiento del negocio y de la lógica implementada.
- Si el número de pruebas manuales escala en número, pueden acabar suponiendo una carga para el desarrollador. Esto sucede porque deberá de invertir mucho tiempo en realizar su ejecución y posterior validación, lo que reduce la escalabilidad del proceso.
En resumen, se podría decir que los test manuales cumplen un papel complementario, ya que permiten al desarrollador realizar un mejor trabajo y asegurarse de que el código no genera problemas inesperados y cumple las reglas de negocio. Sin embargo, estas pruebas no deberían de sustituir a los test automatizados puesto que ambos cumplen funciones claramente diferenciadas y complementarias.
Test programados en orquestación
Por último, en cuanto al momento de ejecución de los test, hay que tener en cuenta los que se programan para ser lanzados durante la orquestación (como por ejemplo, en Airflow). En este enfoque, los test no dependen directamente del flujo de desarrollo (como en CI/CD), sino que se lanzan como parte de los pipelines de datos en producción, siguiendo la misma planificación que las cargas y transformaciones.
Veamos las ventajas e inconvenientes que presenta esta metodología.
Ventajas
- Al estar configurados para ejecutarse en el flujo de orquestación, permiten asegurar que los datos son validados cada vez que se ejecuta el proceso. Así, el desarrollo del proceso es validado constantemente, impidiendo que un posible error se vaya propagando y solo sea visto a la hora de realizar el despliegue en producción. De esta manera, se pueden reducir los costes y los tiempos de desarrollo.
- Por otro lado, también permiten detectar errores provenientes de fuentes externas (por ejemplo, de tablas externas) o la ingesta de datos de tablas en otros formatos sobre los que se realiza una ingesta directa. Así, se obtiene una seguridad en los datos que no se podría conseguir solo con testeo en CI/CD.
Inconvenientes
- En cuanto a los inconvenientes, el más evidente es el aumento del tiempo de ejecución de los DAGs. Si se han de realizar varias comprobaciones, éstas pueden sumar un tiempo valioso y significativo al tiempo total de ejecución. Por lo tanto, siempre será necesario tener en cuenta este aspecto para así poder poner en una balanza hasta qué punto profundizar en los test frente a la seguridad que aportan.
- Otro aspecto crítico a tener en cuenta es que dependiendo de la configuración establecida, los test pueden bloquear toda la ejecución del proceso de orquestación. Esto tiene la ventaja de que no introduces datos corruptos en tus tablas, pero el contra de que si los datos no son de un peso relevante en el proceso, pueden paralizar todo el conjunto causando problemas mayores que los que se busca solucionar.
- Finalmente, será necesario establecer una estrategia de notificaciones o alertas. En caso de no hacerlo, estos test pueden ser ignorados, perdiendo así su utilidad y comprometiendo la fiabilidad del proceso.
En definitiva, los test programados en orquestación constituyen un pilar fundamental dentro de cualquier estrategia de validación de datos. Gracias a ellos se pueden detectar errores de manera prematura. Además, evitan que datos corruptos avancen por el sistema, haciéndolo en su conjunto mucho más confiable, robusto y a prueba de fallos.
Enfoque estratégico de testing
En este punto, conviene destacar que los test en DBT pueden aplicarse con enfoques distintos según el objetivo que se persigue. No siempre tiene sentido validar lo mismo ni con igual intensidad, ya que las prioridades cambian en función del contexto.
Por ejemplo, no tendremos que aplicar el mismo enfoque si nuestro objetivo es garantizar la estabilidad del pipeline que si es mantener y asegurar una coherencia del negocio u optimizar la calidad de los datos. Por esa razón, el enfoque estratégico es tan importante de tener en cuenta a la hora de planificar los test en DBT.
Teniendo esto en cuenta, vamos a diferenciar tres tipos de estrategias.
Metodología Test as a documentation
Este enfoque parte de la idea de que los test no solo permiten validar los datos que se obtienen en el proceso. Además, son la mejor forma de comprender cuáles son las reglas de negocio que se aplican.
En la práctica, se pretenden utilizar los test como una parte fundamental de la documentación. De base, han de mostrar qué está soportado por las normas de negocio y qué no lo está, debiendo fallar el test en consecuencia.
La principal ventaja de este enfoque es la facilidad que aporta de entender el modelo de negocio por nuevos miembros del equipo o personas ajenas al proyecto. Esta información no solo estará plasmada en un documento de texto, sino que también se podrá conocer mediante el seguimiento de las pruebas.
Sin embargo, no son todo ventajas. La generación de test buscando ser usados como parte de la documentación del proceso es algo que requiere una disciplina férrea. Esto se debe a que, en caso de quedar desfasados o de no incluirse correctamente los test adecuados a nuevos desarrollos, todo el esquema pensado para documentar el proceso podría venirse abajo con suma facilidad.
Metodología Test Driven Development
El enfoque de Test Driven Development (TDD), ampliamente utilizado en el desarrollo de software, también puede aplicarse al mundo de la ingeniería de datos con DBT. La idea central de esta metodología es definir primero los test y después implementar la transformación. Gracias a ello, el desarrollo se hace con una base mucho más sólida. Como ya se conoce el resultado esperado de las transformaciones, es mucho más rápido y eficiente encontrar la manera de llegar a ellos. De esta forma, además se evitan errores en la calidad de los datos obtenidos.
Una vez comprendido en qué consiste este enfoque, lo más importante es comprender el flujo de trabajo que se debería de seguir.
- El primer paso es comprender las normas de negocio para, posteriormente, definirlas como test que hay que validar.
- Después, hay que ejecutar estos test permitiendo que fallen, pues por el momento no hay datos que validar.
- Seguidamente, se implementa el modelo siguiendo las reglas establecidas.
- A continuación, se ejecutan de nuevo las pruebas para comprobar que ahora los datos obtenidos sí que cumplen con las normas de negocio establecidas en los mismos.
- En caso de que volvieran a fallar, sería necesario refactorizar el código para solventar el problema, pero de una manera mucho más localizada y requiriendo un menor esfuerzo.
Implicaciones de esta metodología
Como se puede observar, implementar esta metodología de testing es una práctica recomendable que además es ampliamente utilizada en entornos de desarrollo de software. No solo permite validar las reglas de negocio desde un principio, sino que facilita la refactorización del código en caso de que los resultados no sean los esperados.
Sin embargo, esta metodología también tiene algunas limitaciones. Por ejemplo, que requiere un mayor esfuerzo a la hora de iniciar el proyecto, ya que será necesario definir perfectamente las normas de negocio. Por otro lado, no todos los escenarios se pueden cubrir con test. Siempre puede darse la circunstancia de que haya parte del código para la que esta metodología no sea la más apropiada, habiendo otras que se ajusten mejor a las circunstancias.
En definitiva, añadir esta metodología suele ser una buena idea siempre y cuando se cumplan tres factores fundamentales. El primero es que se tengan bien claras las normas de negocio, el segundo es que se esté dispuesto a hacer el esfuerzo inicial de desarrollar los test en primer lugar. Y, por último, es necesario que el tipo de proyecto se pueda adaptar a esta metodología.
Test coverage por capa de modelo
Por último, otra estrategia clave de un enfoque de testing en DBT es definir el nivel de cobertura de las pruebas en función de la capa del proyecto. Es decir, según staging, intermediate, marts, etc.
Esto es un punto clave porque no todas las tablas requieren el mismo grado de validación. Como es obvio, cuanto más cerca de la capa final se encuentran, mayor es la criticidad de garantizar su calidad.
Por esa razón, aunque está considerado una metodología de testeo, en mi opinión resulta más preciso entenderlo como una estrategia de validación en la que se ajusta el nivel de exigencia según la importancia de cada modelo. Esto permite evitar la sobrecarga de testeo en las capas iniciales del modelo. Además, maximiza la exigencia en las partes más críticas en las que de verdad se aporta el valor.
En resumen, lo que se busca con el test coverage por capa de modelo es más la eficiencia y la relevancia que la aplicación de estrategias de test específicas. Por otra parte, permite aplicar la prueba adecuada con la intensidad adecuada en función de la criticidad del dato que se está validando.
Conclusión
El testing en DBT es algo amplio y profundo que no debe entenderse como un conjunto aislado de técnicas. Ha de considerarse como una estrategia integral de validación que atraviesa todas las fases del ciclo de vida del dato y que debe adaptarse en función de lo que se pretenda validar.
Por esa razón, un buen sistema de testing no solo asegura la calidad del dato. Además, permite optimizar el proceso y reflejar el modelo de negocio que hay detrás de todos los modelos, facilitando la escalabilidad de los mismos y permitiendo que escale de manera mucho más confiable y estable que de no tenerlos.
En definitiva, aplicar test es algo completamente necesario (especialmente en DBT) y usar una metodología u otra estará marcado por tus necesidades y las del negocio.
Si te ha parecido interesante este artículo, visita la categoría Data Engineering de nuestro blog para ver post similares a este y compártelo en redes con todos tus contactos. No olvides mencionarnos para poder conocer tu opinión @Damavisstudio. ¡Hasta pronto!
