Utiliser Ant ou Jenkins sur des tests automatiques écrits dans n’importe quel langage (autre que Java & C++).

  • Sharebar

Bonjour,

Voici un modeste retour d’expérience chez un client (appelons le “S.”) qui peut vous intéresser si votre projet comporte des tests automatiques pour lesquels il n’existe aucun framework. Cela peut arriver lorsque les tests sont écrits avec des langages exotiques ou “faits maison” comme c’est le cas chez S. :
L’exploitation des résultats de tests se faisait jusqu’à maintenant par des rapports de sortie de test au format texte, dans lesquels il fallait faire une recherche manuelle sur le mot clef “error”, un bon vieux “grep” en quelque sorte… méthode rudimentaire et efficace mais qui peut commencer à poser des problèmes pratiques lorsque le nombre de tests devient important.

Pour bénéficier de la plus-value des outils existants comme Ant ou Jenkins, il suffit de rajouter en sortie de chaque test automatique un fichier XML qui respecte le format JUnit.
Si, de plus, vos tests sont classés dans une structure hiérarchique de type “arbre”, vous pouvez réutiliser les noms des niveaux de hiérarchie en lieu et place des packages Java utilisés par JUnit dans ces fichiers XML.
Par exemple :
Ma_campagne_de_tests\mon_domaine_fonctionnel_n1\mon_test_1
Ma_campagne_de_tests\mon_domaine_fonctionnel_n1\mon_test_2
Ma_campagne_de_tests\mon_domaine_fonctionnel_n2\mon_test_1
Ma_campagne_de_tests\mon_domaine_fonctionnel_n2\mon_test_2

Une fois que ces fichiers XML sont générés, il suffit d’appeler la tâche <junitreport> dans un script Ant pour générer à partir de ces fichiers un rapport synthétique au format HTML, avec navigation entre packages et sous-packages.
Ca marche bien, mais par défaut, la tâche <junitreport> génère un rapport orienté JUnit (on ne saurait lui en vouloir), avec des libellés tels que : “Designed for use with JUnit”.
Pour corriger ce genre de détails, on peut fournir en entrée de la tâche ant un fichier .xsl adapté au contexte, en utilisant le paramètre styledir de <junitreport>. Pour tout savoir sur junitreport et styledir : http://ant.apache.org/manual/Tasks/junitreport.html

Et pour ne pas tout réecrire, on peut prendre comme modèle le fichier .xsl de Ant qu’on peut trouver ici : ...\apache-ant-1.8.4\etc\junit-frames.xsl (ou ...\apache-ant-1.8.4\etc\junit-noframes.xsl selon le cas)

Et voilà : Arrivé à ce niveau, on dispose d’une tâche Ant capable de générer un rapport de tests HTML structuré, synthétique et personnalisable, lisible par un non-informaticien et qui nous permet d’oublier notre grep initial.

Et pour jenkins alors ? Il faut réussir à écrire un script qui passe les tests et qui place les fichiers XML de sortie de ces tests dans un Workspace Jenkins, et ça suffit : Jenkins appelle ce script régulièrement, et se débrouille tout seul pour analyser chaque série de résultats, pour la comparer avec les résultats précédents, et tracer les courbes qui vont bien, comme l’évolution du nombre de tests “OK” ou de tests  “KO” dans le temps.
On dispose alors d’un historique sur les résultats des tests automatiques, ce qui permet de cibler, par exemple, quelle modification du code a entraîné une régression, pour peu qu’on passe régulièrement tous les tests.

NOTE : Je n’ai pas trouvé de documentation sur le format exact utilisé par Ant pour les fichiers XML en sortie de tests Junit : cependant, il suffit d’écrire un test Junit trivial en Java, et de le passer via la tâche <junit> d’un script Ant, on dipose alors de fichiers qu’on peut facilement utiliser comme modèles.

This entry was posted in JUnit, Methodologies, Test. Bookmark the permalink.

Leave a Reply