Une fois que Jenkins sait où se trouvent les rapports de test, il fournit un excellent travail de rapport sur ces derniers. En effet, une des tâches principales de Jenkins est de détecter et de fournir des rapports sur des échecs de build. Et un test unitaire échoué est un des symptômes les plus évidents.

Comme nous le mentionnions plus tôt, Jenkins fait la distinction entre les builds échoués et les builds instables. Un build échoué (indiqué par une balle rouge) signale des tests échoués, ou une tâche de build qui est cassée d'une façon brutale, telle qu'une erreur de compilation. Un build instable, en revanche, est un build qui n'est pas considéré de qualité suffisante. C'est intentionnellement vague : ce qui définit la “qualité” est généralement donné par vous, mais c'est typiquement lié aux métriques de code comme la couverture de code ou les standards de codage, ce que nous discuterons plus tard dans le livre. Pour l'instant, concentrons-nous sur les builds échoués.

Dans Figure 6.5, “Jenkins affiche la tendance des résultats de test sur la page d'accueil du projet” nous pouvons voir comment Jenkins affiche une tâche de build Maven contenant des échecs de tests. Ceci est la page d'accueil de la tâche de build, qui devrait être votre premier point d'entrée quand un build échoue. Quand un build contient des tests en échec, le lien Dernier résultats des tests indique le nombre courant d'échecs de test dans cette tâche de build (“5 échecs” dans l'illustration), et aussi la différence dans le nombre d'échecs de test depuis le dernier build (“+5” dans l'illustration — cinq nouveaux échecs de test). Vous pouvez aussi voir comment les tests ont réussi dans le temps — les échecs de test des builds précédents apparaîtront en rouge dans le graphique Tendance des résultats des tests.

Si vous cliquez sur le lien Derniers résultats des tests, Jenkins vous donnera un aperçu des résultats des derniers tests (voir Figure 6.6, “Jenkins affiche une vue synthétique des résultats de test”). Jenkins supporte les structures de projets multi-modules Maven, et pour une tâche de build Maven, Jenkins va afficher une vue synthétique des résultats de test par module. Pour voir plus de détails sur les tests en échec dans un module particulier, cliquez simplement sur le module qui vous intéresse.

Pour les tâches de build free-style, Jenkins vous donnera directement un aperçu de vos résultats de test, mais organisé par packages de haut niveau plutôt que par modules.

Dans les deux cas, Jenkins commence par présenter un aperçu des résultats de test pour chaque package. A partir d'ici, vous pouvez affiner, voir les résultats de test pour chaque classe de test pour finir par les tests dans les classes de test. Et s'il y a des tests en échec, ils seront surlignés en haut de la page.

Cette vue complète vous donne à la fois un bon aperçu de l'état courant de vos tests, et une indication sur leur historique. La colonne Age indique depuis combien de temps un test a été cassé, avec un hyperlien qui vous ramène vers le premier build dans lequel le test a échoué.

Vous pouvez aussi rajouter une description aux résultats de test, en utilisant le lien ajouter une description dans le coin en haut à droite de l'écran. C'est une bonne manière d'annoter un échec de build avec des détails additionnels, afin de rajouter une information supplémentaire sur l'origine du problème des échecs de test ou des notes sur la façon de les corriger.

Lorsqu'un test échoue, vous voulez généralement savoir pourquoi. Pour voir les détails d'un échec d'un test donné, cliquez sur le lien correspondant sur cet écran. Cela va afficher l'ensemble des détails, y compris le message d'erreur et la pile, ainsi qu'un rappel du temps depuis lequel le test est en échec (voir Figure 6.7, “Les détails d'un échec de test”). Vous devriez vous méfier des tests qui sont en échec depuis plus de deux builds — cela signale soit un problème technique pointu qui doit être investigué, soit une attitude complaisante envers les tests en échec (les développeurs ignorent peut-être les échecs de build), ce qui est plus sérieux et doit sûrement être étudié.

Assurez-vous que vous gardez un oeil sur le temps que prennent vos tests pour s'exécuter, et pas uniquement s'ils passent ou échouent. Les tests unitaires doivent être conçus pour s'exécuter rapidement, et des tests trop longs peuvent être le signe d'un problème de performance. Des tests unitaires lents retardent aussi le retour, et en IC, un retour rapide est la clé. Par exemple, exécuter un millier de tests unitaires en cinq minutes est bon — prendre une heure ne l'est pas. Donc c'est une bonne idée de vérifier régulièrement combien de temps vos tests unitaires prennent pour s'exécuter, et si nécessaire investiguer pourquoi ils prennent autant de temps.

Heureusement, Jenkins peut facilement vous dire la durée que prennent vos tests pour s'exécuter dans le temps. Sur la page d'accueil de la tâche de build, cliquez sur le lien “tendance” dans la boite Historique des builds sur la gauche de l'écran. Cela vous donnera un graphique à l'instar de celui dans Figure 6.8, “Les tendances de temps de build peuvent vous donner un bon indicateur de la rapidité de vos tests”, vous montrant combien de temps chacun de vos builds a pris pour s'exécuter. Cependant, les tests ne sont pas la seule chose qui apparaît dans une tâche de build, mais si vous avez suffisamment de tests à regarder de près, ils vont probablement prendre une grande partie du temps. Ainsi, ce graphique est aussi un excellent moyen de voir comment vos tests se comportent.

Quand vous êtes sur la page Résultats des tests (voir Figure 6.6, “Jenkins affiche une vue synthétique des résultats de test”), vous pouvez aussi affiner et voir le temps que prennent les tests dans un module, package ou classe donnée. Cliquez sur la durée du test dans la page Résultats des tests (“A duré 31 ms” dans Figure 6.6, “Jenkins affiche une vue synthétique des résultats de test”) pour voir l'historique du test pour un package, une classe, ou un test individuel (voir Figure 6.9, “Jenkins vous permet de voir combien de temps les tests ont mis pour s'exécuter”). Cela rend facile l'isolation d'un test qui prend plus de temps qu'il ne le devrait, ou même décider quand une optimisation générale de vos tests unitaires est requise.