Comment testez-vous les unités \ utilisez-vous les méthodes TDD pour les projets ETL et les rapports?

Les projets ETL sont des projets créés à l'aide d'un outil ETL (Extraire - Transformer - Charger) tel que SSIS, PowerCenter, etc.

Il s'agit généralement de lire les données d'une source externe, de les charger dans une base de données intermédiaire, d'effectuer certaines transformations et de les charger dans une base de données finale

Un exemple simple serait d'utiliser SSIS pour lire les fichiers Excel fournis par les enseignants utilisant SSIS et les charger dans une base de données. Ensuite, écrivez des procédures stockées ou plusieurs packages SSIS pour calculer les notes de chaque étudiant et charger ces données dans un magasin de données \ entrepôt

Vous créez ensuite des procédures stockées au-dessus du magasin pour générer une sortie qui est utilisée par les outils de génération de rapports (SSRS \ Excel \ etc) pour générer des visualisations.

J'essaie de comprendre comment effectuer TDD et les tests unitaires appropriés dans ce scénario. Les tests pour les ETL consistent principalement à s'assurer que les données chargées dans les correspondances des tables de transfert sont le bon sous-ensemble des données de la source. Donc, l'implémentation d'un test pour cela conduit à l'implémentation d'une mini version de l'ETL. La sortie des rapports SP dépend des données dans les tables elles-mêmes, donc on ne peut pas avoir un ensemble stable de données de sortie sans un cauchemar de maintenance même si vous créez une base de données contenant des données de test nettoyées

Exemple:

Sprint 1: le tableau des étudiants contient le nom, l'âge, la classe

Vous créez des données de test pour ce tableau et des tests unitaires basés sur ce

Sprint 2: un champ de genre est ajouté au tableau.

Maintenant, si vous actualisez les données dans le champ étudiant pour remplir l'attribut de genre, les cas de test sont invalidés depuis la modification des données. Et si vous ne le faites pas, vous ne pouvez pas créer de cas de test qui nécessitent la colonne de sexe

Ce que j'ai fait dans le passé, c'est utiliser le développement piloté par les tests d'acceptation . Le code ETL est souvent réparti sur différentes étapes / langages et technologies ET étroitement couplé. La plupart des processus ETL dépendent de la séquence de transformations dans le pipeline.

Le risque d'utiliser le test unitaire uniquement dans ETL est qu'il ne couvrira pas les intégrations. Le séquençage des transformations est une partie égale aux transformations réelles dans de nombreux ETL. Si je dépense des ressources pour créer une suite de tests automatisée, je m'assurerais qu'elle couvre également le séquençage.

Je me concentrerais sur TDD pour chaque séquence de transformation unique ou au moins inclurais ces tests dans une suite de tests plus grande. S'il y a trop de combinaisons, vous devrez peut-être choisir les séquences à tester. L'idée est de valider le pipeline ETL pour le ou les jeux de données sur lesquels il sera utilisé. En plus de vous assurer d'avoir une couverture de test sur tout votre code.

ETL peut être fait avec TDD et des tests assez similaires à la plupart des projets, à savoir

écrire un test qui échoue (rouge) corriger l'échec (vert) rendre le code perforé et maintenable (refactor)

Donc, pour ETL, cela pourrait être:

• écrire un script pour charger 1 enregistrement
• échec (aucune source de données définie)
• définir la source [vert]
• pas besoin de refactor
• écrire un test pour charger 1 enregistrement avec seulement 1 champ rempli
• échec (aucun code écrit pour ce champ)
• définir les détails du code pour ce champ
• refactor
• définir des tests qui échouent et recherchent des attributs ayant des valeurs valides [rouge]
• etc