Automatisation des tests en BI (SQL Server, SSAS, SSIS) avec NBi

Chez Cellenza on aime l’Agilité et les technos Microsoft

Et pour vous parler franchement, je peux vous dire que côté BI, ça veut dire que ce n’est pas tous les jours la fête. Il ne faut pas oublier que livrer des fonctionnalités métier toutes les 2 semaines (SCRUM), ça veut dire faire évoluer et livrer la solution entière toutes les 2 semaines (soit des tables, des procédures stockées, des packages SSIS, des morceaux de SSAS, voir des rdl si on manque de chance, etc.). Evidemment, ça veut dire des opportunités régulières de se prendre les pieds dans le tapis et crouler sous les anomalies de régression. Mais si, vous savez, ces bugs qu’on pensait corrigés mais qui reviennent nous hanter en permanence parce qu’on travaille toujours sur le même périmètre !

Parce que oui, si la stack SQL Server pour la BI est simple à prendre en main, efficace et performante, c’est aussi grâce à des choix d’implémentation faits par Microsoft au niveau de SSIS et SSAS, qui les éloignent grandement des bonnes pratiques du développement logiciel. Les artefacts produits sont, en effet, monolithiques, ils s’inscrivent douloureusement dans des cycles ALM modernes, que ce soit pour la gestion des versions, l’automatisation des tâches ou encore le travail à plusieurs.

Si jusqu’à présent nous souffrions plus ou moins en silence, désormais il existe des solutions pour palier à certaines de ces déconvenues. Je pense évidemment à BIML pour l’automatisation des développements SSIS (BIML qui par ailleurs produit des artefacts qui eux sont faciles à diff/merge, mais c’est un sujet pour autre jour) et NBi pour l’automatisation des tests sur les données.

C’est pas beau ça?

NBi est un projet open-source pour le moment sur le CodePlex, dont le contributeur n’est autre que Cédric Charlier (twitter|blog), qu’on avait déjà entendu speaker au SQLSat Paris 2014. A noter que Microsoft reconnait et encourage ce type d’effort publiquement, la preuve en étant la nomination récente de Cédric en tant que MVP SQL Server. La classe 😉

Pour faire court, NBi est un framework complémentaire à NUnit, la suite open source d’automatisation des tests unitaires dans le monde .NET, qui lui ajoute des fonctionnalités BI. Pour ça, il s’appuie, entre autres, sur le client ADOMD.NET qui, si on remet les lettres dans le bon sens, n’est autre qu’un client ADO.NET “MD” (avec MD pour MultiDimensionnal, soit SSAS) qui va permettre à NBi de parler DAX et MDX en plus du SQL. Tout ça je vous le dis pour votre culture, parce qu’une fois installé, on s’en moque de qui fait quoi, mais ce qui est sûr c’est qu’on va pouvoir automatiser nos tests!

Pour se lancer, direction CodePlex. La documentation est bien fournie. De notre côté nous vous proposons un petit guide de prise en main, c’est juste en dessous!

Installer et configurer NBi

Etape 1 : télécharger et installer les prérequis

Dans le désordre :

• Le Framework .NET 4.5 (ou plus), si vous ne l’avez pas déjà – MSDN download page
• NUnit 2.5 (ou plus) – NUnit.org download page
• Microsoft Analysis Services Adomd Client (ADOMD.NET) 10 (ou plus) – MSDN download page. A noter que si vous êtes en Windows 64bit il vous faut SQLSERVER2008_ASADOMD10_amd64.msi, et pour Windows 32bit ce sera SQLSERVER2008_ASADOMD10_x86.msi, à cocher dans la liste.

Enfin, il vous faudra la dernière version de NBI. Si vous êtes un voyageur du futur (et que la version en cours de NBi n’est plus la 1.9), vérifiez quand même que les versions des prérequis n’ont pas trop changé par rapport aux liens indiqués au dessus.

Etape 2 : construire son environnement de test

Un environnement de test est structuré autour de plusieurs répertoires :

• Le répertoire de base, dans mon exemple …\MyTests\ qui va inclure :
  • Un répertoire pour le framework NBi, ici …\MyTests\Framework
  • Un répertoire pour chacun de mes projets de test, ici …\MyTests\MyTestProject
  • Des répertoires pour les autres objets de NBi présents dans le ZIP d’installation (facultatifs mais bien pratiques, comme Genbi et les samples)

De façon graphique, ça doit donner quelque chose comme ça :

La deuxième étape après l’installation des prérequis, c’est donc bien de récupérer les répertoires contenus dans le ZIP de NBi, et d’organiser la structure décrite au dessus.

Ensuite, le setup minimal pour commencer à utiliser NBi se compose de 3 fichiers qu’on va créer soi-même. Il s’agit de fichiers TXT contenant du XML, chacun ayant une extension spécifique. Pour créer ce type de fichier, on utilisera NotePad, NotePad++ ou autre, et on “enregistra sous” en respectant la convention de nommage attendue:

Et pour bien comprendre comment ça fonctionne, voici le contenu de chacun de ces fichiers :

Soit dans le détail :

• Le fichier .nunit, utilisé par NUnit pour exécuter les tests. Il peut être généré par NUnit Project Editor, qui s’installe en même temps que NUnit  (voir le milieu de la page pour plus de détails), ou renseigné à la main (recommandé vu comment le Project Editor plante)
• Le fichier .nbits, qui contient effectivement la suite de tests, et qui sera le cœur de votre projet de test. Voir la doc sur comment le construire vous même
• Le fichier .config, que vous devrez également construire vous-même, et qui lie le tout ensemble (voir le haut de la page)

Pas de panique, on ne vous abandonne pas, voici un sample de ces 3 fichiers qui devraient fonctionner sans intervention, il vous suffit d’ajouter le répertoire Framework de NBi. La suite de tests comprend 2 tests qui pointent vers une base Adventureworks hébergée sur Azure, un grand merci à Red Gate pour ça.

Etape 3 : tester !

Une fois toute l’affaire mise en place, il suffit de double-cliquer sur le .nunit pour lancer une exécution du test. Vert tout va bien, rouge c’est ko!

Evidemment vous vous en doutez, les exécutions se scriptent, je vous laisse farfouiller dans la documentation de NUnit pour ce faire.

Avec ça, au revoir les régressions 😉

Si ça vous plait, n’hésitez pas à faire un coucou à Cédric directement sur la page de NBi!