VIII. Le reporting▲
Le framework TestNG propose encore une fois un système de reporting assez intéressant du fait qu'il est ouvert. En effet,
TestNG propose un reporting de base, mais propose en même temps de pouvoir faire soit même son propre outil de reporting.
Il permet aussi d'utiliser des plugins déjà tout faits tels que JUnitReports dont nous parlerons ici.
VIII-A. Le reporting de TestNG▲
Le reporting de TestNG est relativement fourni en informations concernant les tests. Il permet notamment de récupérer les résultats classés par groupes, ou encore l'ordre d'exécution des tests… Il permet bien entendu de récupérer les erreurs des tests échoués et d'avoir un récapitulatif du test exécuté.
Afin de demander la création des rapports, il suffit de rajouter un attribut dans la balise <testng>. L'attribut outputDir permet de spécifier où seront stocker les rapports.
Le seul point négatif au reporting de TestNG est son aspect visuel. Il n'est pas très agréable à regarder et semble un peu brouillon.
C'est à ce moment qu'entrent en jeu les systèmes de création de nos propres journaux d'exécution ou encore des plugins externes.
VIII-B. Le plugin JUnitReports▲
Pour utiliser JUnitReports, peu de configuration 0 effectuer. Il suffit de créer une nouvelle tâche Ant qui exécutera la transformation du fichier de résultats du test en une page web complète, agréable et sobre.
Exemple de tâche Ant pour JUnitReports :
<target name="reports-base" depends="base">
<mkdir dir="reportsJunit/base"/>
<junitreport todir="reportsJunit/base">
<fileset dir="reports/testng/base">
<include name="*.xml"/>
<exclude name="testng-failures.xml"/>
</fileset>
<report format="noframes" todir="reportsJunit/base"/>
</junitreport>
</target>Nous voyons bien qu'il faut utiliser une balise particulière <junitreport> et spécifier le chemin de sortie. Cette balise contient aussi un chemin vers le fichier xml de sortie de TestNG.
Exemple de rapport JUnitReports :
Nous voyons que le design est vraiment mieux, mais nous ne pouvons pas voir les groupes des tests… C'est sûrement dû au fait que le plugin était fait pour JUnit 3.8.
VIII-C. La dernière possibilité, nos plugins▲
Il est important de noter que chacun peut définir son propre rapport de sortie en développement ses propres Listener et le Reporter.
Cette phase ayant été très peu documentée, je ne l'ai pas testée. Malgré tout la documentation venant d'arriver sur le site officiel est de bonne qualité et peut-être d'un grand secours si on veut mettre en place notre reporting personnel.