Read this article in English 
Test-Driven Development (TDD)
pour Tableau
Qu’est que le Test-Driven Development pour Tableau ?
Le Test-Driven Development (TDD) est un concept très répandu dans le monde du développement de logiciels. Les développeurs de logiciels qui utilisent le TDD commencent par écrire des scénarios de test (basés sur ce que le logiciel ou le morceau de code est censé faire), puis écrivent le code, afin que le test réussisse, et continuent à répéter ces étapes régulièrement. Ce concept permet aux développeurs de trouver les problèmes le plus tôt possible lors du développement de nouvelles fonctionnalités, de sorte à repérer les erreurs avant de mettre en production les modifications dans la base de code existante. Un grand nombre d’études prouvent que les tests d’écriture sont cruciaux lors du développement de logiciels et qu’ils permettent de réduire les problèmes de production, sans parler de leur résolution…
Le TDD dans le monde de la BI
Finalement, pourquoi ne pas appliquer le concept de TDD à la BI ? Les développeurs de BI ne se contentent pas d’afficher des données dans des rapports et tableaux de bord, ils effectuent également de nombreuses transformations sur ces données, en mettant en œuvre diverses logiques métier dans la couche de visualisation, en mélangeant des données provenant de sources multiples, etc. Par conséquent, ce traitement supplémentaire est susceptible de causer des erreurs si le résultat n’est pas testé.
Les étapes d’un TDD dans des langages de programmation.
Dans le domaine de la BI, cependant, en raison de diverses causes telles que la forte dépendance à l’égard de solutions logicielles tierces comme Tableau, Power BI, etc., les différentes compétences des développeurs de BI et la nature des tableaux de bord de BI, l’utilisation de TDD est très compliquée. Même les cas de test les plus simples sont très difficiles à mettre en place avec les frameworks traditionnels.
Disons que vous voulez vérifier si un filtre particulier existe sur un tableau de bord. La vérification sera difficile une fois que vous aurez réalisé que Tableau insère dynamiquement de nombreux éléments HTML <canvas> où les sélecteurs CSS/XPath ne fonctionnent pas, et que vous ne pouvez donc pas interagir avec ces objets sur la page. Les tests deviendront rapidement encore plus compliqués une fois que vous aurez commencé à mettre en œuvre une logique métier dans les champs/dimensions calculés et que vous voudrez valider si ces chiffres sont calculés correctement. Cependant, si vous ne testez pas ces objets tôt ou tard, vous risquez de vous retrouver avec des problèmes de production sur un tableau de bord critique pour l’entreprise.
Prevailing test frameworks, comme Selenium ou xUnit, sont conçus pour des applications web ou des langages de programmation classiques et ne sont pas compatibles avec des solutions de BI comme Tableau. Alors, que peuvent faire les développeurs BI pour surmonter ce défi ? Je vais vous montrer un exemple détaillé de la manière de développer un dashboard Tableau en appliquant le concept de TDD avec Wiiisdom Ops. Tout professionnel Tableau qui développe des tableaux de bord devrait s’appuyer sur ce type de tests automatisés, pour assurer une qualité irréprochable.
TDD pour Tableau avec Wiiisdom Ops
Grâce à une variété de tests disponibles, Wiiisdom Ops vous permet de mettre en œuvre le principe de TDD pour Tableau. Wiiisdom Ops utilise les API de Tableau JS/REST et d’autres méthodes de communication interne pour interagir avec les visualisations lorsque les tests web ne suffisent plus. Par ailleurs, l’application propose des tâches intégrées de comparaison de données qui sont obligatoires pour valider les chiffres indiqués sur le tableau de bord.
En utilisant Wiiisdom Ops, un cycle de TDD sous Tableau se présenterait comme suit :
Étapes du TDD sous Tableau avec Wiiisdom Ops.
Ces étapes sont similaires à celles du TDD traditionnel, mais il y a quelques petites différences :
- Vous devrez utiliser deux outils à des étapes différentes : Tableau Desktop/Server comme d’habitude et Wiiisdom Ops comme outil supplémentaire pour concevoir et exécuter les tests pour Tableau.
- Développer la viz est équivalent à l’étape standard d’écriture de code.
- Pimper la viz est équivalent à l’étape standard Refactor.
Exemple concret de TDD pour un Dashboard Tableau
Si vous travaillez dans un environnement Agile, vous obtiendrez très probablement des besoins tels que celui décrit ci-dessous :
“En tant que directeur financier, je veux avoir un tableau de bord qui montre les ventes quotidiennes dans un graphique avec une comparaison des chiffres d’une année sur l’autre dans une période et un pays sélectionnés, afin d’avoir un aperçu rapide de la façon dont l’entreprise progresse au quotidien”.
Supposons que vous et un analyste commercial ayez discuté de ce point plus en détail et qu’ils aient fait une ébauche de la manière dont ils peuvent imaginer le tableau de bord en action :
Une ébauche du tableau de bord.
Vous pensiez à des tests et avez également défini quatre critères d’acceptation de base :
- Il doit y avoir une feuille portant le nom de “Ventes quotidiennes”.
- Il doit y avoir un filtre par pays avec trois valeurs : “États-Unis”, “Royaume-Uni”, “France”.
- Il doit y avoir deux paramètres de date pour la “Date de début” et la “Date de fin”.
- Deux chiffres doivent toujours figurer sur le graphique : “Total des ventes” et “Total des ventes de l’année précédente”. Ces deux chiffres doivent toujours être supérieurs ou égaux à zéro, car il est impossible de prévoir une journée avec des ventes négatives.
Il existe de nombreuses possibilités de commettre des erreurs lors de l’élaboration du tableau de bord. Par exemple, le filtre est manquant, il n’y a pas de chiffres YoY, le code couleur est incorrect ou les champs calculés fonctionnent mal. Pour éviter que ces erreurs ne se produisent, vous devez rédiger des scénarios de test qui vérifient si les critères d’acceptation sont respectés :
Étape 1 : Test d’échec
Traditionnellement, une fois le besoin spécifié, vous commencez à développer le tableau de bord, mais dans le cadre du TDD, vous devez d’abord définir les tests. Dans Wiiisdom Ops, pour ce qui concerne les tests fonctionnels, chaque cas de test est constitué d’une série de tâches qui sont exécutées les unes après les autres par le testeur automatisé pour simuler les actions d’un utilisateur. Dans cet exemple, nous allons créer des tests fonctionnels avec quelques étapes pour couvrir tous les critères d’acceptation : Login to Tableau, Open Viz, Assert Worksheets Exist, Assert Parameter Equals, Assert Filter Equals and Assert Data Rules.
Login to Tableau et Open Viz sont des tâches préparatoires pour simuler un utilisateur naviguant sur un tableau de bord spécifique. Les tâches Assert Parameter Equals et Assert Filter Equals vérifieront l’existence des paramètres de date de début/fin et du filtre de pays avec les valeurs requises : États-Unis, Royaume-Uni et France. La tâche Assert Data Rules vérifie si le “Total des ventes” et le “Total des ventes de l’année précédente” sont tous deux supérieurs ou égaux à zéro.
Série de tâches sélectionnées permettant de tester les critères d’acceptation fonctionnels.
À ce stade, vous enregistrez le test et poussez le projet Wiiisdom Ops dans votre dépôt git.
Étape 2 : Exécution et échec du test
Le fait d’effectuer le test la première fois permet de valider que le test lui-même fonctionne correctement. Il devrait échouer parce que le tableau de bord n’existe pas, car nous n’avons pas commencé à le construire.
Echec du premier test.
Étape 3 : Rédiger le code et passer le test (Make the Viz)
OK, il est maintenant temps d’ouvrir votre Tableau Desktop et de développer le tableau de bord. En fonction des besoins, vous obtiendrez quelque chose comme ceci :
La première version de l’application se concentre uniquement sur les besoins fonctionnels.
Dans cette étape, nous devons nous concentrer sur les besoins fonctionnels car nous devons nous assurer qu’ils répondent aux critères d’acceptation. Nous ne devrions pas passer trop de temps à ce stade sur les aspects visuels et les mises en page fantaisistes (nous pourrons le faire un peu plus tard). Idéalement, une fois le viz développé, tous les cas de tests ci-dessus devraient être réussis, en vérifiant que les critères d’utilisation requis sont respectés.
Étape 4 : S’assurer que tous les anciens cas tests sont réussis
Dans cette étape, nous devons exécuter tous les cas de test précédemment réalisés, en nous assurant que les nouvelles fonctionnalités ne cassent pas les fonctionnalités existantes. Pour l’instant, nous n’avons qu’un seul cas de test, ce qui n’ajoute pas trop de choses, mais cette étape sera cruciale pour l’avenir.
Réussir des tests sur un tableau de bord fonctionnel.
Notez que la tâche Assert Data Rules vous permet de créer des règles de validation de données avancées par des formules de type Excel qui font référence aux dimensions et mesures Tableau. Pour valider les chiffres de vente de cette année et de l’année dernière, nous avons ajouté deux formules. Les deux valeurs doivent être supérieures ou égales à zéro. Chaque formule renvoie des valeurs VRAIES ou FAUSSES et si elle est fausse, le test échouera également. Les données sous-jacentes sont exportées du classeur Tableau au moment de l’exécution du test et validées pour chaque ligne.
OR([SUM(In Scope – During – Amount)] > 0, ISBLANK([SUM(In Scope – During – Amount)])) — Formule pour valider le montant des ventes cette année
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 à la dernière étape.
Étape 5 : Refactoriser (Pimp the Viz)
À ce stade, vous pouvez ” personnaliser” et améliorer la mise en page pour obtenir un tableau de bord visuellement agréable, conforme aux exigences de formatage de votre organisation. À ce stade, chaque test doit également être vert et, si nécessaire, vous pouvez ajouter une tâche supplémentaire “Assert Image Equals” dans le cas de test Wiiisdom Ops pour valider la mise en page du tableau de bord.
Tableau de bord des ventes quotidiennes, testé sur les plans fonctionnel et visuel (Viz inspiré du blog Tri My Data d’Eva Murray).
La prochaine fois que vous aurez besoin de modifier quelque chose dans le tableau de bord, vous répéterez l’ensemble du flux afin de revenir au point 1 et de faire de nouveaux cas de test, en vous concentrant d’abord sur la nouvelle fonctionnalité demandée par l’entreprise, c’est-à-dire l’ajout de nouveaux filtres, feuilles de travail, actions de filtrage, mesures calculées, etc.
Et ensuite ?
Bien sûr, avec l’exemple de test fonctionnel TDD ci-dessus, nous n’avons pas couvert tous les concepts de test que les développeurs non-BI utilisent depuis longtemps, mais la bonne nouvelle est que la plupart d’entre eux sont maintenant disponibles pour Tableau via Wiiisdom Ops.
Si vous avez besoin d’aide pour tester Tableau, contactez-nous et l’un de nos experts vous aidera.
