Objectif : Premier aperçu du projet codelab mutation testing
- Importez le projet se trouvant dans le répertoire challenges/application-hexa dans votre IDE préféré IntelliJ / VSCode / Eclipse...
- Configurez le projet pour utiliser JDK 21
- Construisez le projet avec
mvn clean install
Si vous rencontrez des erreurs, demandez immédiatement de l'aide à votre formateur !
Parcourez le projet pour comprendre son organisation.
Dans le répertoire target/site ouvrez le rapport de test de Jaccoco 
Ajoutez la dépendance PIT dans le pom.xml du projet 'application-hexa:
<project>
<!-- ... -->
<build>
<!-- ... -->
<plugins>
<!-- ... -->
<plugin>
<groupId>org.pitest</groupId>
<artifactId>pitest-maven</artifactId>
<version>1.16.1</version>
<dependencies>
<dependency>
<groupId>org.pitest</groupId>
<artifactId>pitest-junit5-plugin</artifactId>
<version>1.2.1</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</build>
</project>Lancez PIT avec la commande suivante :
mvn pitest:mutationCoverageLe résultat doit lancer des mutations pour vérifier la fiabilité de nos tests
================================================================================
- Statistics
================================================================================
>> Line Coverage (for mutated classes only): 79/86 (92%)
>> Generated 254 mutations Killed 212 (83%)
>> Mutations with no coverage 9. Test strength 87%
>> Ran 305 tests (1.2 tests per mutation)
Enhanced functionality available at https://www.arcmutate.com/
Le package adaptator, service, exception, handler ne semble pas avoir une couverture suffisamment forte pour PI. Ces packages sont importants car elles portent soit la logique métier du domaine, soit la logique de transformation d'une entité fournit par un provider et objet métier, et soit le message que l'on peut retourner à l'utilisateur.
Ces classes d'Exception portent des messages qui seront affichés à l'utilisateur final. De plus en fonction de l'erreur, cela devra déclencher un handler qui fabriquera une réponse Http custom.
Pour faciliter l'analyse de l'erreur, il est donc nécessaire de s'assurer que toutes les informations sont présentes.
Les mutations qui continuent à exister sont des mutations de substitutions et des mutations d'appel de méthodes
Les tests suivants 'TicketControllerTest.bad_data_quality_not_expected' et dans 'ControllerExceptionHandlerTest.test_handler_exception_error_50x' ne sont pas suffisant qu'est ce qui manque pour qu'il soit complet.
Il y a deux services:
- TicketService.java (3 mutations)
- CalculCAPortService.java (1 mutation)
Les deux classes sont importantes, car elles portent de la logique métier:
- filtrage
- règle de calcul
Par exemple, pour calculer le chiffre d'affaire nous devons filtrer la source de sorte à garder que les données éligibles.
private static boolean filtreTicketStatus(TicketVO ticketVO){
var status=ticketVO.ticketStatus();
return TicketStatus.FACTURE.getCode().equals(status.getCode())
||TicketStatus.AVOIR.getCode().equals(status.getCode());
}
Deux choses doivent nous alerter, les mutations continuent à exister car :
- deux méthodes ne sont pas testés
- un test une partie n'est pas couverte.
La méthode signum de BigDecimal retourne 3 possibilités soit -1, 0, ou 1. Dans les tests présents on test que -1 ou 1, il nous manque donc 1 cas.
De plus pour exécuter ce contrôl, nous avons besoin d'avoir accès à un attribut d'un objet il nous manque un control à ce niveau.
La partie qui pose problème est assez intéressante car il s'agit d'un moteur de calcul. De plus le résultat est exposé directement à l'utilisateur final.
La ligne qui pose problèmes a pour objectif de construire une liste de tuple et chaque tuple est objet qui nous donne le CA par caisse.
Alors que le rapport Jacocco nous affirme qu'on a 100% de couverture.
Deux problèmes existent:
- à partir d'une lambda on construit une map à partir d'une liste. L'input de la map est le problème
- dans la méthode compute, la méthode filter semble poser un problème et la sortie de la méthode n'est pas aussi testée Aller dans le test 'CalculCAPortServiceTest' pour corriger les problèmes.
Remarque:
Il est toujours intéressant de tester les valeurs par défaut qui peuvent être retournées (car on pourrait avoir un service qui utilise uun fallback si la source de données est indisponible).
La classe ControllerExceptionHandler gère les exceptions et les messages customs qui vont être retournées à l'utilisateur
Ce que l'on voit dans le rapport Pit dans le body du message http qui n'est pas testé en particulier le code http.
La classe adaptor est une classe qui va transformer la donnée fournit par notre provider (ici une BDD) en un objet du domaine métier.
En général, ce qui manque se sont des tests de contrôle sur la sortie.
PIT a permis de mettre en évidence:
- des tests qui n'étaient pas complets
- une règle de calcul qui aurait pû être simplifié
- complète les tests unitaires ne remplace pas les tests d'intégration