Généralisons les tests dans nos projets B.I.!

MVP Data Platform - Fan inconditionnel de la coopérative INSIDERS.COOP,j'ai hâte de partager mes expériences avec vous !

2 Comments

  1. Cédric Charlier

    Tester les projets BI est un must (souvent sous-estimé) et peut s’avérer très complexe et rapidement chronophage. L’approche suggérée (écrire des tests unitaires en C#) ici fonctionne a plusieurs points faibles:

    1. Cela demande des connaissances en C#, ce que tout le monde ne dispose pas nécessairement (Ce n’est pas une core-knowledge pour un développeur BI).
    2. Mine de rien, cela demande un compilateur C# (ou un IDE tel que Visual Studio), pas toujours évident d’avoir accès à cela dans certaines entreprises.
    3. La partie utile du test est moyée dans la masse. Dans les tests décris ce qui est pertinent c’est la query et le résultat attendu, le reste n’est que de la plomberie.
    4. Quand le résultat attendu est plus complexe qu’un simple chiffre (quelques lignes et colonnes), le test s’allonge, rendant encore plus la partie importante du test noyée dans le code.
    5. En l’absence du sous-framework spécifique à la BI, il faut que chacun réinvente la plomberie (classe MicroMd dans ce cas-ci). Quand les tests se veulent plus complexes que ceux proposés ici en exemple, la plomberie peut devenir bien plus complexe à écrire et maintenir.
    6. En l’absence d’un outil spécifique, il est difficile de généraliser l’approche pour générer automatiquement de tels test-suites dans le cadre d’une non-regression entre deux versions par expl.

    L’utilisation d’un framework de tests unitaires spécifiques à la BI (NBi ou BI.Quality ou QueryUnit), tel que Florian Eiden, le décris permet de corriger ces faiblesses et donc d’être plus rapidement efficace en se concentrant directement sur l’essentiel (la query, la comparaison à mettre en oeuvre et le résultat attendu) plutôt que sur la plomberie.

    Notons aussi que les premiers tests d’un projet BI ne devraient pas êtres des tests aussi complexes que le résultat d’une query. Simplement vérifier que les dimensions, mesures ou que les membres adressés existent bien (et ne sont pas invisibles pour l’utilisateur ou mal orthographiés ou oubliés) est un travail qui permet d’éviter de nombreuses régressions et met en valeur votre release auprès de vos stakeholders car elle ne comporte pas les petits bugs « stupides » habituels qui agacent les personnes qui utiliseront votre release. Un framework tel que NBi (http://nbi.codeplex.com) va vous aider également à écrire rapidement ce genre de tests et augmentera la qualité de votre release.

Leave a Reply to Cédric Charlier Cancel Reply

Your email address will not be published. Required fields are marked *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.