Les tests d'acceptation automatisés jouent un rôle important dans de nombreux projets agiles, à la fois pour la vérification et pour la communication. Comme outil de vérification, les tests d'acceptation jouent un rôle similaire aux tests d'intégration, et visent à démontrer que l'application fait effectivement ce qui est attendu d'elle. Mais ce n'est qu'un aspect secondaire des tests d'acceptation automatisés. L'objectif principal est en fait la communication — montrer aux non développeurs (experts métier, analystes métiers, testeurs, et ainsi de suite) précisement où en est le projet.

Les tests d'acceptation ne doivent pas être mélangés avec des tests orientés développeurs, parce qu'à la fois leur finalité et leur audience sont très différentes. Les tests d'acceptation doivent être des exemples montrant comment le système fonctionne, avec un accent sur la démonstration plutôt que sur une preuve exhaustive. Les tests exhaustifs doivent être faits au niveau des tests unitaires.

Les tests d'acceptation peuvent être automatisés en utilisant des outils conventionnels tels que JUnit, mais il y a une tendance croissante à utiliser des frameworks Behavior-Driven Development (BDD) à cet effet, parce qu'ils correspondent mieux à l'audience non technique des tests d'acceptation. Les outils Behavior-driven development utilisés pour les tests d'acceptation automatisés génèrent généralement des rapports HTML avec une mise en page bien adaptée aux non développeurs. Ils produisent aussi souvent des rapports compatibles JUnit qui peuvent être traités directement par Jenkins.

Les frameworks Behavior-Driven Development ont aussi la notion de “tests en attente”, tests qui sont automatisés, mais qui n'ont pas encore été implémentés par l'équipe de développement. Cette distinction joue un rôle important dans la communication avec les autres acteurs non développeurs : si vous pouvez automatiser ces tests tôt dans le processus, ils vous donneront un excellent indicateur des fonctionnalités qui ont été implémentées, qui fonctionnent, ou qui n'ont pas encore été démarrées.

En règle générale, vos tests d'acceptation doivent être affichés séparément des autres tests automatisés plus conventionnels. S'ils utilisent le même framework de test que vos tests classiques (e.g., JUnit), assurez-vous qu'ils sont exécutés dans une tâche de build séparée, de telle façon que les non-développeurs peuvent les visualiser et se concentrer sur les tests orientés métier sans être distraits par ceux de plus bas niveau ou techniques. Il peut être aussi utile d'adopter des conventions de nommage orientées métier et fonctionnelles pour vos tests et classes de test, afin de les rendre plus accessible aux non-développeurs (voir Figure 6.19, “Utilisation de conventions de nommage orientées métier pour des tests JUnit”). La façon dont vous nommez vos tests et classes de test peut faire une réelle différence quant à la lecture des rapports de test et la compréhension des fonctionnalités et comportements métier qui sont testés.

Si vous utilisez un outil qui génère des rapports HTML, vous pouvez les afficher dans le même build que vos tests classiques, tant qu'ils apparaissent dans un rapport séparé. Jenkins fournit un plugin très pratique pour ce genre de rapport HTML, appelé le plugin HTML Publisher (voir Figure 6.20, “Installer le plugin HTML Publisher”). Bien que ce soit à vous de vous assurer que votre build produise les bons rapports, Jenkins peut les afficher sur la page de votre tâche de build, les rendant facilement accessible à tous les membres de l'équipe.

Ce plugin est facile à configurer. Allez jusqu'à la section “Actions à la suite du build” et cochez la case “Publish HTML reports” (voir Figure 6.21, “Publier les rapports HTML”). Ensuite, indiquez à Jenkins le répertoire où ont été générés vos rapports HTML, une page d'index, et un titre pour votre rapport. Vous pouvez aussi demander à Jenkins de stocker les rapports générés pour chaque build, ou de ne conserver que le dernier.

Une fois que cela est fait, Jenkins affichera une icône spéciale sur votre page d'accueil de votre tâche de build, avec un lien vers votre rapport HTML. Sur Figure 6.22, “Jenkins affiche un lien spécial sur la page d'accueil de la tâche de build pour votre rapport”, vous pouvez voir les rapports easyb que nous avions configuré précédemment en action.

Le plugin HTML Publisher fonctionne parfaitement pour les rapports HTML. Si, d'autre part, vous voulez (aussi) publier des documents non-HTML, tels que des fichiers texte, PDFs, et ainsi de suite, alors le plugin DocLinks est fait pour vous. Ce plugin est semblable au plugin HTML Publisher, mais il vous permet d'archiver à la fois des rapports HTML aussi bien que des documents dans d'autres formats. Par exemple, dans Figure 6.23, “Le plugin DocLinks vous permet d'archiver des documents HTML et non-HTML”, nous avons configuré une tâche de build qui archive à la fois un document PDF et un rapport HTML. Ces deux documents seront maintenant listés sur la page d'accueil de la tache de build.