rTest

C’est un lieu commun de dire qu’il faut tester les développements avant de les mettre en production. D’ailleurs les principaux langages de développement proposent tous des outils ou des librairies dédiés à la définition et à l’automatisation des tests.

Dans le monde des ETL, cette problématique existe également : « Comment être certain qu’un traitement produit bien le bon résultat avant de le mettre en production ? ».

Divers outils indépendants tentent de répondre à cette question et quelques ETL proposent leur propre extension sur la thématique de la qualité  (1).

En fait, ces outils s’intéressent plus à la qualité de la donnée qu’au bon fonctionnement du traitement : ils détecteront qu’un attribut a une valeur nulle mais pas qu’il manque des fichiers dans le résultat. Et bien sûr ils sont incapables de contrôler un résultat de type CAO, image ou nuage de points…

Et pour FME ?

Ce sujet est assez peu abordé au sein de la communauté FME en dehors de Kevin Weller qui a consacré plusieurs articles (2, 3) à ce sujet et proposé une méthode de travail et quelques Transformers sur FME Hub.

Le sujet est pourtant d’importance car la qualité, ou plutôt la non qualité, représente un coût significatif pour les utilisateurs d’outils numériques (4). Dans la pratique, les tests se résument souvent à une consultation visuelle du résultat dans FME Data Inspector ou dans la base de données cible. Si cette méthode peut être envisageable pour des traitements ponctuels exécutés une fois, elle est difficilement acceptable dès lors que la pérennité du traitement doit être assurée.

Confrontée à ce problème, la société Veremes a développé en 2016 pour ses propres besoins un outil de test dédié aux scripts FME et baptisé rTest. Bien que publié sous licence libre et disponible sur GitHub, ce produit est resté confidentiel car non documenté et souffrant de nombreuses imperfections.

La version 2 de rTest qui vient d’être publiée sur vStore est destinée à un plus large public. Le produit est toujours libre, Open Source et bénéficie d’une documentation complète en anglais et français et d’un support technique de la part de Veremes. Le code a été entièrement réécrit et complété par une application web pour la consultation des rapports.

Cet article décrit les principes de rTest ainsi que la méthode de développement qui lui est associée.

rTest est un environnement de test qui permet d’automatiser l’exécution de traitements FME et de vérifier si le résultat observé est conforme au résultat attendu. L’exécution d’un scénario de test génère un rapport HTML qui fournit des informations sur la bonne exécution des traitements (statut, durée, RAM, log) et sur la conformité des résultats.

rTest est non intrusif, il ne nécessite pas d’utiliser des Transformers ou des connecteurs spécifiques dans le cœur du traitement. Il ne présente donc aucun risque de dégradation des performances ou de comportement.

rTest est constitué de trois composants :

• Un schéma de définition qui détermine une syntaxe, ou plutôt une grammaire qui permet d’écrire des scénarios de test sous forme de document XML : rtest.xsd
• Un traitement FME qui permet d’exécuter les scénarios de test : scenarioPlayer.fmw
• Une application web (application HTML+JS) qui permet de visualiser le résultat d’un contrôle sous forme d’application HTML dynamique : reportTemplate.html

Le schéma rtest.xsd et les ressources de l’application web (.js, .css…) sont disponibles en ligne de manière transparente. Pour les utilisateurs ayant accès à internet rTest se résume donc à scenarioPlayer.fmw et au modèle de rapport reportTemplate.html.

Les scénarios de test

Un scénario de test est un document XML décrivant une liste de tests devant être exécutés séquentiellement. Chaque test est lui-même composé d’un ou plusieurs traitements FME avec ses paramètres et des vérifications à appliquer pour considérer que le test est validé.

L’édition d’un document XML n’est jamais amusante mais avec l’aide d’un bon éditeur XML et en s’appuyant sur le schéma d’application rtest.xsd c’est un exercice facile à mettre en œuvre.

scenarioPlayer.fmw est le traitement FME qui est chargé de lire les scénarios et d’exécuter les différents tests les uns après les autres, d’abord en lançant les traitements FME avec les bons paramètres, puis en vérifiant si les résultats produits sont conformes aux valeurs attendues.

Les rapports produits par scenarioPlayer sont horodatés et stockés dans des répertoires spécifiques pour faciliter la conservation des résultats et la persistance des liens entre les rapports HTML et les fichiers de log même en cas de déplacement vers un serveur de stockage.

Le rapport HTML

Il s’agit d’une application HTML dynamique qui permet de filtrer directement les tests en échec et d’obtenir le statut de chaque vérification.

Dans les faits, l’exécution de scenarioPlayer.fmw produit un rapport HTML qui présente l’ensemble des informations relatives à un contrôle : statut des tests, durée d’exécution, contenu des logs…

On distingue habituellement deux grandes familles de tests permettant de déterminer la conformité d’un logiciel : les tests fonctionnels dont l’objectif est de vérifier que le traitement produit bien les résultats attendus et les tests non fonctionnels qui vont se concentrer sur les performances, la montée en charge, la sécurité…

Avec rTest on se range clairement dans la catégorie des tests fonctionnels et l’on cherche à vérifier si les données produites par l’exécution d’un script FME sont conformes aux attentes en toutes circonstances.

En fait, c’est presque une mission impossible : il suffit d’un test négatif pour prouver qu’un traitement ne fonctionne pas alors qu’il faudrait vérifier une infinité de cas de figure pour prouver qu’il fonctionne à tous les coups. On en est donc réduit à valider un « bon fonctionnement probable » avec un certain niveau d’incertitude.

Dans la pratique, on peut distinguer quatre niveaux de vérification. Ceux-ci ne sont pas exclusifs, un scénario de test pouvant combiner différents contrôles.

1. Le statut du traitement

On vérifie juste si le traitement se termine avec le statut « SUCCESSFUL » ou « FAILED ».

2. Le dénombrement des entités

On compte les entités produites et on compare le résultat au nombre attendu.

Le dénombrement peut être global ou par type d’entités.

3. La valeur des entités

C’est le niveau de vérification le plus détaillé. Il doit permettre de s’assurer que les entités produites sont conformes aux attentes. La vérification peut porter sur un ou plusieurs attributs et sur la géométrie et concerner quelques entités ou être exhaustive.

4. La gestion des non conformités

Quel doit être le comportement du traitement lorsqu’il doit réaliser une opération impossible ?

Par exemple si un paramètre est incohérent, si le traitement ne dispose pas des droits d’écriture sur un fichier ou s’il doit simplement calculer la racine de -1 ?

Il est de la responsabilité du développeur d’identifier ces cas d’erreur et de définir le comportement à adopter : sortie en erreur, écriture dans un fichier de log, suppression préalable des résultats intermédiaires…

Ce comportement doit pouvoir être vérifié lors du test de conformité.

Pour des développements assistés par les tests

Pour en tirer le plus grand bénéfice, l’outil de test ne doit pas être un simple instrument supplémentaire au service des développeurs mais doit être au cœur du projet de développement.

Dans un projet traditionnel, avec des tests manuels, le temps nécessaire à la vérification est important et représente une charge non négligeable en termes de durée et de coût.

Au cours de la vie du projet, l’équipe de développement n’a donc généralement pas la capacité de réaliser des tests qui soient à la fois approfondis et exécutés de manière régulière. Elle doit sacrifier la complétude ou la fréquence et souvent les deux.

Au final, c’est souvent à l’utilisateur que revient la tâche de valider le livrable avant sa mise en production en essayant d’identifier les cas de non-conformité.

Avec un outil de test, la bonne méthode consiste à identifier les cas de test très tôt au cours du projet en associant les utilisateurs à ce travail. Cela permet de produire les jeux de données de test avant ou pendant le développement et de rédiger les scénarios de test dès les premières versions du traitement.

Le développeur va pouvoir s’appuyer sur ces scénarios pour vérifier le bon fonctionnement en continu et consacrer du temps à des tâches parfois négligées : optimisation des performances, nettoyage de code, industrialisation, sans avoir peur d’introduire des régressions dans son travail.

Le développement assisté par les tests permet ainsi d’inverser la charge de la preuve au moment de la recette : ce n’est plus à l’utilisateur de prouver que le traitement ne fonctionne pas mais au développeur de prouver que son projet fonctionne.

Pour cela il peut s’appuyer sur les cas des tests identifiés au début du projet et qui doivent servir de preuve.

Des bénéfices mais pour quels projets ?

C’est vrai, l’exploitation d’un outil de test augmente la charge de travail si on la compare à l’utilisation de tests manuels sommaires. Mais dès que le projet devient un peu complexe ou critique, ce surcoût est très rapidement compensé par une diminution de la charge nécessaire à la maintenance et par les bénéfices annexes de cette pratique :

Au final nous conseillons rTest pour tous les projets devant répondre à des impératifs de robustesse et de qualité, surtout s’ils ont vocation à être maintenus pendant plusieurs années. Plus que la taille et la complexité, c’est la criticité et le coût de la défaillance qu’il faut évaluer.

Chacun appréciera facilement qu’une erreur sur des données aéronautiques, routières ou militaires peut avoir de lourdes conséquences mais à l’inverse il n’existe aucun domaine qui échapperait sans dommage à l’utilisation de données erronées.

rTest a donc vocation à être exploité largement par la communauté FME dans tous les domaines d’activité. Veremes continue à maintenir le produit pour ses propres besoins mais nous serons heureux de bénéficier des retours et attentes des développeurs, distributeurs et intégrateurs engagés dans des projets d’amélioration de la qualité de leur production.

---