Bonjour,
Voici un article initialement posté sur le blog talentagile.com en 2016.
Un projet de Business Intelligence se caractérise par plusieurs activités de développement :
- Le modèle de données (storage, publication)
- L’ETL (acquisition, transformation, publication)
- La restitution (publication, consumption)
- La donnée
Le TDD (Test-driven development) consiste à faire des tests tôt et réguliers de manière à augmenter la qualité du logiciel. En pratique, il s’agit de créer des tests avant le développement de chaque fonctionnalité et de pouvoir les exécuter avant le développement puis après. Le test est conçu ré-exécutable et automatisable.
Le TDD est assez peu répandu dans les projets de Business Intelligence. Voici une situation classique rencontrée par un développeur sur un projet BI.
Un utilisateur métier signale des incohérences de données dans les restitutions. Le développeur constate qu’il manque des données. Pour identifier la source du problème :
- Il ouvre le développement de la restitution (Est-ce que le cube a bien été traité ? Est-ce que le rapport ne filtre pas certaine valeur de la dimension ?). L’analyse ne donne rien.
- Il vérifie dans le modèle de donnée que le contenu est bien présent (Est-ce que le modèle permet l’ajout de la donnée manquante ?). L’analyse montre que des lignes de fait sont manquantes.
- Il ouvre les traitements d’ETL et vérifie qu’aucune règle de gestion ne filtre cette donnée. L’analyse montre qu’un croisement avec un référentiel peut en être la raison.
- Il regarde le fichier source du référentiel. Le fichier ne contient pas la ligne de référentiel attendue.
Conclusion : Ce dernier n’est pas à jour.
En BI, l’utilisation des TDD est liée à l’activité de développement. Voici quelques propositions de TDD qui auraient permis d’analyser automatiquement la situation décrite au-dessus.
- Le modèle de donnée
- Tester la connexion
- Tester l’existence des objets avant de créer les objets (table, vue, procédure stockée, fonction, table type, variable, job…)
- Exécuter un cas de test dans une SP avant de développer le cas
- La donnée
- Tester l’existence d’un cas fixe avant d’insérer (valeur dans le référentiel, valeur par défaut)
- Tester les volumes dans les systèmes sources
- Tester la fraicheur des données dans les système source
- L’ETL
- Tester la disponibilité de la connexion/d’un fichier
- S’assurer que les circuits ne créent pas de perte de donnée. Tester que le volume de ligne en sortie correspond au volume de ligne en entrée.
- S’assurer que les circuits ne créent pas d’altération de donnée. Tester que les totaux en sortie correspondent aux totaux en entrée.
- La restitution (selon le type de restitution)
- Exemple un cube SSAS
- Tester l’existence d’une dimension avant de la créer
- Tester l’existence de données dans une dimension avant de développer sa génération
- Tester l’existence d’une mesure ou d’un membre calculé avant de la créer
- Exemple un cube SSAS
- Exemple un rapport SSRS
- Tester l’existence du rapport avant de le déployer
- Tester l’ouverture d’un filtre avant de le créer
Pratiquez-vous les TDD sur vos projets BI ? N’hésitez pas à partager vos expériences ou vos questions.