-
Notifications
You must be signed in to change notification settings - Fork 0
Rapports de tests
Afin de garantir la qualité de l'application, nous avons décidé de mettre en place une batterie de tests unitaires et end-to-end. Nous avons ensuite utilisé JaCoCo et Pitest, qui sont tous les deux des outils de Code Coverage, afin de générer des rapports de tests. Bien que les deux génèrent des rapports de coverage, nous avons décidé de les utiliser tous les deux car nous les considérons comme étant complémentaires.
Notre premier objectif était d'assurer une couverture de test du code de minimum 80% afin de nous assurer d'avoir une application stable, et nous avons pour cela installé JaCoCo. JaCoCo est un outil de mesure de la couverture de code pour les applications Java permettant de suivre la quantité de code source qui a été testée par des tests unitaires, ainsi que de générer des rapports détaillant la couverture de code. Il peut également être intégré à des outils de build tels que Maven ou Gradle, ce qui nous permis ici de créer une GitHub Action afin de l'exécuter avec Maven lors de l'intégration continue. Une fois l'action exécutée, une autre GitHub Action génère ensuite une GitHub Page déployée à cette adresse.
Notre deuxième objectif était d'effectuer des tests de mutation afin de garantir la qualité de nos tests, en nous fixant un objectif de 80% de mutations éliminées sur les contrôleurs et les services. Pour rappel, le test de mutation est une technique qui consiste à introduire délibérément des défauts (ou mutations) dans le code source, puis à exécuter les tests unitaires, et dont l'objectif est de vérifier si les tests détectent les mutations. Nous avons donc pour cela installé Pitest, qui est un outil de test de mutation pour les applications Java. Cet outil analyse le code source, introduit des mutations, puis exécute les tests unitaires pour voir si les mutations sont détectées. Il génère ensuite des rapports indiquant quelles mutations ont été tuées par les tests et lesquelles ont survécu. Comme JaCoCo, il peut être intégré à Maven, ce qui nous a permis de créer une autre GitHub Action afin de l'exécuter lors de l'intégration continue. Une fois cette action exécutée, l'action de génération de GitHub Page en déploie une seconde à cette adresse.
Afin de mettre en place nos tests unitaires, nous avons utilisé JUnit et Mockito. Il sont inclus dans notre projet grâce à l'usage du starter POM spring-boot-starter-test, qui inclus également Hamcrest dont nous ne nous sommes pas servis. Pour programmer nos tests, nous avons utilisé la méthodologie suivante : nous avons créé une multitude de tests de précision très fine afin de tester chaque possible pour chaque méthode de nos services et contrôleurs, et nous avons nommés ces tests en suivant la syntaxe Gherkin. Nous avons ainsi recréé une arborescence de fichiers de tests calquées sur l'arborescence de notre projet, en créant ainsi un fichier de tests par service et par contrôleur. Dans chacun de ces fichiers de tests, nous utilisons Mockito afin de mocker les dépendances du service ou du contrôleur testé. Ainsi, à chaque début de test, nous utilisons Mockito afin de simuler le comportement attendu par nos dépendances, puis nous testons la méthode souhaitée et nous vérifions ensuite si le résultat de celle-ci est bien le résultat attendu, qu'il soit une valeur ou un comportement particulier (comme le lancement d'exception). Enfin, nous vérifions si le nombre d'appels aux méthodes de nos dépendances utilisées par notre méthode est le bon. Comme précisé précédemment, nos tests sont ensuite exécutés par Maven grâce notre pipeline d'intégration, et nous nous sommes fixé des objectifs de 80% de couverture de code et de mutations éliminées (pour les contrôleurs et les services) en définissant des thresholds sur JaCoCo et Pitest.