Comment mettre en œuvre le Test-Driven Development (TDD) pour Tableau avec Wiiisdom
Qu’est-ce que le Test-Driven Development ?
Le Test-Driven Development (TDD / Développement piloté par les tests) est un concept clé du DevOps, largement répandu dans le développement logiciel. Cette approche consiste pour les développeurs à commencer par écrire des cas de test qui définissent précisément ce que le logiciel ou le code doit accomplir. Ensuite, ils développent le code afin que celui-ci réussisse les tests, puis répètent ces étapes régulièrement. Grâce à cette méthode, les problèmes sont détectés dès les premières phases du développement de nouvelles fonctionnalités, ce qui permet d’identifier rapidement toute anomalie avant que les changements n’intègrent la base de code existante. De nombreuses études montrent que la rédaction de tests joue un rôle clé dans le développement logiciel, car elle réduit significativement les incidents en production et limite les complications liées à la correction de bugs.
Pourquoi le Test-Driven Development est essentiel ?
Dans le domaine de la BI, l’idéal serait que cette pratique soit également généralisée, notamment à travers des approches telles que DevOps for BI ou AnalyticsOps. En effet, les développeurs BI ne se contentent pas de visualiser les données : ils effectuent aussi de nombreuses transformations, intègrent des logiques métiers complexes dans la couche de visualisation et combinent des informations provenant de diverses sources. Ces opérations, qui relèvent souvent d’initiatives DevOps for BI et AnalyticsOps, augmentent fortement le risque de présenter des données incorrectes.
Étapes du Test-Driven Development dans les langages de programmation généralistes.
Dans le domaine de la BI, la mise en œuvre du Test-Driven Development représente un véritable défi, notamment en raison de la forte dépendance à des solutions logicielles tierces telles que Tableau, Power BI, et autres. Le profil technique spécifique des développeurs BI, allié à la nature particulière des dashboards, rend la démarche d’autant plus complexe. Même les scénarios de test les plus simples s’avèrent difficiles à appliquer avec les frameworks web traditionnels.
Par exemple, si vous souhaitez vérifier la présence d’un filtre précis sur un dashboard Tableau, vous vous heurtez rapidement à une complexité technique : Tableau génère le contenu de la page dynamiquement via des éléments HTML, ce qui invalide l’utilisation des sélecteurs CSS/XPath et rend impossible toute interaction directe avec ces objets à l’écran. La situation se complique encore lorsque vous implémentez des logiques métiers dans des champs calculés ou des dimensions, et que vous cherchez à valider la pertinence des résultats obtenus.
Pourtant, ignorer ces objets ou négliger leur test finit toujours par générer des problèmes et accroître le risque d’incidents en production sur des dashboards critiques pour l’entreprise. Les frameworks de test classiques comme Selenium ou xUnit sont conçus pour les applications web ou les langages de programmation généralistes, mais ils ne sont pas adaptés aux spécificités de la BI. Les développeurs BI disposent donc de peu d’outils réellement adaptés à leurs besoins.
Face à ce constat, comment surmonter ce défi ? Je vais vous présenter un exemple concret de développement d’un dashboard Tableau selon le concept TDD avec Wiiisdom for Tableau. Tout professionnel Tableau qui conçoit des dashboards à destination des décideurs devrait s’appuyer sur des tests automatisés pour garantir leur fiabilité et veiller à ce que les fonctionnalités existantes soient préservées lors de l’ajout de nouvelles évolutions.
Développement piloté par les tests pour Tableau avec Wiiisdom
Grâce à une large gamme de cas de test flexibles, notre solution facilite la mise en œuvre du Test-Driven Development pour Tableau. Wiiisdom for Tableau s’appuie sur les APIs JS/REST de Tableau ainsi que sur des méthodes de communication internes pour interagir avec les visualisations, là où les frameworks de test web traditionnels montrent leurs limites.
Par ailleurs, la solution propose des tâches de comparaison de données essentielles pour garantir l’exactitude des chiffres affichés sur un dashboard.
Avec Wiiisdom for Tableau, le cycle du Test-Driven Development appliqué à Tableau s’organise de la manière suivante :
Étapes du Test-Driven Development dans Tableau avec Wiiisdom for Tableau.
Le processus suit le cycle traditionnel du TDD, tout en intégrant quelques spécificités propres à l’environnement Tableau :
- À chaque étape, vous utiliserez deux outils complémentaires : Tableau Desktop/Server pour construire votre dashboard comme à l’accoutumée, et Wiiisdom for Tableau pour concevoir et exécuter les cas de test automatisés dédiés à Tableau.
- L’étape Make the Viz correspond à la phase de développement du code (« Write Code ») dans le cycle classique.
- L’étape Pimp to Viz s’apparente à la phase de refactoring (« Refactor ») du TDD standard.
Exemple concret de TDD pour un dashboard Tableau
Si vous travaillez dans un environnement agile, il est fort probable que l’on vous soumette une demande similaire à celle-ci :
« En tant que Directeur Financier, je souhaite disposer d’un dashboard Tableau affichant les ventes quotidiennes sous forme de graphique, avec les chiffres d’une année sur l’autre pour une période et un pays sélectionnés, afin d’obtenir rapidement une vue d’ensemble de la progression de l’activité au jour le jour. »
Supposons que vous ou un business analyst ayez approfondi cette demande et préparé une première ébauche illustrant le fonctionnement attendu du dashboard :
Première version du dashboard.
En anticipant la phase de test, vous avez défini quatre critères d’acceptation essentiels :
- La présence d’une feuille intitulée « Daily Sales ».
- L’existence d’un filtre pays proposant trois valeurs : « The United States of America », « United Kingdom » et « Australia ».
- La disponibilité de deux paramètres de date, « Start Date » et « End Date ».
- L’affichage systématique de deux indicateurs sur le graphique : « Total Sales » et « Total Sales Previous Year ».
Tous deux doivent impérativement être supérieurs à zéro, car il n’aurait pas de sens d’avoir des ventes négatives pour une journée donnée.
Lors du développement d’un dashboard Tableau, de nombreux écueils peuvent survenir : absence d’un filtre, oubli des chiffres YoY, erreurs dans le code couleur ou encore champs calculés incorrects. Pour prévenir ces problèmes, il est indispensable de rédiger des cas de test permettant de s’assurer que l’ensemble des critères d’acceptation sont bien remplis.
Étape 1 : Écrire un test qui échoue
Traditionnellement, après avoir recueilli les besoins, la première étape consiste à développer le dashboard. Avec la démarche Test-Driven Development, on commence d’abord par définir les tests. Dans Wiiisdom for Tableau, dans le cadre du functional testing, chaque cas de test s’articule autour d’une succession de tâches exécutées automatiquement par le test runner, simulant les actions d’un utilisateur dans un scénario précis.
Dans cet exemple, nous allons construire des tests fonctionnels en plusieurs étapes, chacun visant à valider un critère d’acceptation spécifique : Open Viz, Assert Worksheets Exist, Assert Parameter Equals, Assert Filter Equals et Assert Data Rules.
La tâche Open Viz démarre le processus en simulant la navigation vers le dashboard Tableau concerné. Ensuite, Assert Parameter Equals et Assert Filter Equals permettent de s’assurer de la présence des paramètres de dates de début et de fin, ainsi que du filtre pays, lequel doit proposer les trois valeurs attendues : United States of America, United Kingdom et Australia. Enfin, la tâche Assert Data Rules vérifie que les indicateurs « Total Sales » et « Total Sales Previous Year » sont bien tous deux strictement supérieurs à zéro.
Une série de tâches sélectionnées permettra de tester les critères d’acceptation fonctionnels.
À cette étape, vous allez enregistrer le test et pousser le projet Wiiisdom for Tableau dans votre repository git.
Étape 2 : Exécuter le test et constater l’échec
Lancer le test pour la première fois permet de valider que le test lui-même fonctionne correctement. Il doit échouer, car le dashboard n’existe pas encore : nous n’avons pas commencé à le construire.
Première exécution du test – échec attendu.
Étape 3 : Développer et faire passer le test (Créer la Viz)
Ça y est, il est temps d’ouvrir Tableau Desktop et de construire le dashboard. En suivant les exigences, vous obtiendrez quelque chose comme ceci :
Cette première version de la viz met l’accent exclusivement sur les exigences fonctionnelles.
À ce stade, il est important de se concentrer sur les attentes fonctionnelles afin de s’assurer que tous les critères d’acceptation sont bien respectés. Il n’est pas nécessaire de consacrer trop de temps à l’aspect esthétique ou à un layout sophistiqué, qui pourront être améliorés par la suite. L’essentiel, une fois la viz développée, est que l’ensemble des cas de test définis en amont soient validés, garantissant ainsi la couverture complète des critères métier requis.
Étape 4 : S’assurer que tous les anciens cas de test passent
À cette étape, il est nécessaire d’exécuter chaque cas de test précédemment défini, afin de garantir que les nouvelles fonctionnalités n’impactent pas les existantes. Pour le moment, il n’y a qu’un seul cas de test, ce qui ne représente pas une charge supplémentaire significative, mais cette étape deviendra essentielle au fur et à mesure que le projet évoluera.
Cas de test validés sur un dashboard fonctionnel.
À noter que la tâche Assert Data Rules permet de créer des règles de validation avancées sur les données, via des formules de type Excel qui font référence aux dimensions et mesures Tableau. Pour valider les chiffres de ventes de cette année et de l’année précédente, nous avons ajouté deux formules. Les deux valeurs doivent être supérieures à zéro, mais les valeurs nulles sont acceptées.
Chaque formule retourne TRUE ou FALSE, et si le résultat est FALSE, le test échoue également.
OR([SUM(In Scope – During – Amount)] > 0, ISBLANK([SUM(In Scope – During – Amount)])) — Formule pour valider le montant des ventes de l’année en cours
OR([SUM(In Scope – LY – Amount)] > 0, ISBLANK([SUM(In Scope – LY – Amount)])) — Formule pour valider le montant des ventes de l’année précédente
Les tests sont au vert, nous pouvons donc passer à l’étape suivante.
Étape 5 : Refactorisation (Pimper la Viz)
À cette étape, vous pouvez « pimper votre viz » et améliorer le layout pour obtenir un dashboard Tableau visuellement attractif, conforme à toutes les exigences de formatage de votre organisation. Tous les tests doivent être au vert à ce stade, et si besoin, il est possible d’ajouter une tâche supplémentaire Assert Image Equals dans le cas de test Wiiisdom for Tableau afin de valider la mise en page du dashboard.
Dashboard Tableau des ventes quotidiennes, testé fonctionnellement et visuellement attractif.
La prochaine fois que vous devrez modifier le dashboard, vous reprendrez l’ensemble du workflow : retour au point 1 pour rédiger de nouveaux cas de test, en vous concentrant d’abord sur la nouvelle fonctionnalité demandée par le business (ajout de nouveaux filtres, worksheets, filter actions, mesures calculées, etc.).
Et maintenant ?
Évidemment, l’exemple de test fonctionnel TDD présenté ci-dessus n’illustre pas l’ensemble des concepts de testing que les développeurs hors BI appliquent depuis longtemps, et pour de bonnes raisons. La bonne nouvelle, c’est que la plupart de ces pratiques sont désormais accessibles dans Tableau. Vous pouvez ainsi garantir non seulement un dashboard irréprochable sur le plan visuel, mais aussi avoir la certitude que la logique métier reste constamment fiable.
Si vous souhaitez être accompagné dans votre démarche Test-Driven Development sur Tableau, n’hésitez pas à nous contacter : un expert se fera un plaisir de vous guider.
Foire aux questions
1. Qu’est-ce que le Test-Driven Development pour Tableau ?
Le Test-Driven Development pour Tableau consiste à écrire des tests automatisés sur les exigences du dashboard avant même de le construire, afin de garantir que chaque fonctionnalité est validée et fiable. Cette approche est directement inspirée des pratiques DevOps, qui privilégient l’automatisation, la validation continue et la collaboration entre équipes de développement et d’exploitation. Elle s’intègre parfaitement dans des méthodologies AnalyticsOps, permettant d’assurer la qualité, la gouvernance et la fiabilité des solutions analytiques tout au long du cycle de vie du dashboard.
2. Comment Wiiisdom for Tableau automatise-t-il les tests de dashboard ?
Wiiisdom for Tableau permet aux utilisateurs de concevoir, d’exécuter et de gérer des cas de test qui interagissent directement avec les dashboards Tableau, en validant à la fois la fonctionnalité et la précision des données.
3. Wiiisdom for Tableau peut-il s’intégrer à des pipelines CI/CD ?
Oui, Wiiisdom for Tableau prend en charge l’intégration avec les systèmes de gestion de version et les pipelines CI/CD, permettant ainsi une validation continue et une gouvernance automatisée.
