Atelier 11

Dans cette session de laboratoire, vous pratiquerez deux aspects avancés du développement logiciel : les tests de mutation et les mock tests. Pour les exercices de cette dernière session de laboratoire, vous travaillerez avec le projet PrimeChecker et le project MockServerExercise disponibles sur GitLab.

Tests de mutation

Les tests de mutation sont un test de stress automatisé pour les tests unitaires et d'intégration existants.
L'idée principale est d'injecter des erreurs dans un programme supposé correct et de vérifier si au moins un test échoue pour chaque erreur injectée.
Chaque variante du logiciel original injectée d'une erreur est appelée un mutant.
Si aucun test n'est capable de détecter la modification artificielle du programme, les tests associés sont considérés comme contenant des zombies, c'est-à-dire des tests inutiles ou insuffisants.

Pitest

Le plugin pitest est une extension pratique au processus de construction Maven.
L'installation est aussi simple que d'ajouter le plugin suivant dans la configuration pom.xml :

<!-- Mutation test report-->
<!-- HTML report available at:  target/pit-reports/index.html  -->
<plugin>
    <groupId>org.pitest</groupId>
    <artifactId>pitest-maven</artifactId>
    <version>1.17.1</version>
    <executions>
        <execution>
            <id>pit-report</id>
            <!-- optional, this example attached the goal into mvn test phase -->
            <phase>test</phase>
            <goals>
                <goal>mutationCoverage</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Ensuite, la création d'un rapport de test de mutation est déclenchée par la phase test, c'est-à-dire mvn clean test
Le rapport est disponible dans target/pit-reports/index.html et peut être consulté avec n'importe quel navigateur web.

À vous de jouer

Exemple de configuration du code :

Clonez le projet de vérification des nombres premiers :

git clone https://gitlab.info.uqam.ca/inf2050/PrimeChecker.git

Ouvrez le projet dans IntelliJ
Exécutez les tests fournis, en utilisant mvn clean test

Tous les tests réussiront, mais cela signifie-t-il que vos tests sont bons ? Voyons cela :

Activez le plugin de test de mutation.
Exécutez à nouveau les tests et générez un rapport de test de mutation : mvn clean test
Consultez le rapport de test de mutation dans votre navigateur.

Le rapport vous indiquera une mutation de négation qui peut être ajoutée à votre code sans que les tests ne le remarquent.

Identifiez quelle mutation il s'agit, c'est-à-dire quelle ligne, quel changement.
Vérifiez la mutation, en modifiant effectivement le code de la même manière (votre code comptera désormais les nombres non-premiers au lieu des nombres premiers).
Exécutez à nouveau les tests.

Que devrait-il se passer ?

Les résultats des tests devraient encore être tous réussis. Les résultats du test de mutation indiquent que vos tests ne sont pas capables d'identifier la modification de votre code source.

Enfin, il est temps de corriger le problème et d'améliorer vos tests !

Revoyez vos tests. Identifiez le problème avec vos tests existants.
Modifiez les tests existants ou ajoutez-en de nouveaux.
Exécutez à nouveau les tests de mutation et vérifiez que la couverture des mutations est désormais de 100%.

Moquer

Dans le dernier cours, vous avez vu un exemple de dépendance d'un SUT (base de données), qui devait être remplacée par un Mock pour faciliter les tests.
Dans ce qui suit, vous allez appliquer les mêmes concepts à une application différente, le TagCounter.
Le cas d'utilisation est identique : nous avons un SUT (classe à tester), qui fait une seule chose : compter les balises HTML.

Exemple

Cet échantillon HTML :

<html>
<h1> Hello, World! </h1>
</html>

possède 4 tags:

<html>
<h1>
</h1>
</html>

Dependency illustration

Malheureusement, nous ne pouvons pas tester notre TagCounter de manière isolée. Pour l'instancier, nous avons également besoin d'un objet ServerFileDownloader,
qui fournit le code HTML en le téléchargeant depuis un vrai serveur : Wikipédia

---
title: SUT needs a ServerFileDownloader object
---
classDiagram
    TagCounter *--> ServerFileDownloader: has a

    class ServerFileDownloader {
        <<Class>>
        +getWebpageContent() void
    }

    class TagCounter {
        <<Class>>
        +TagCounter(ServerFileDownloader) TagCounter
        +countTags() int
    }

À vous de jouer

Téléchargez le projet ServerMockExercise préparé.
Exécutez l'application et familiarisez-vous avec le code existant.
Modifiez uniquement le code de test pour permettre le test avec mock
- Ajoutez Mockito comme dépendance de test
  dans le fichier pom.xml.
- Ouvrez la classe de test préparée : TagCounterTest et utilisez les annotations vues en cours pour remplacer la
  dépendance du serveur par une dépendance mock.
- Ajoutez une instruction when-thenReturns pour préparer une classe de test. Retournez une page web minimale,
  par exemple celle listée ci-dessus.
- Ajoutez une instruction assert à votre test pour vérifier que le TagCounter fonctionne correctement.
- Utilisez un Captor pour vérifier que l'objet mock ServerFileDownloader est correctement invoqué.