Forem: Nicolas Gauthier

La collaboration : fondement de l'architecture logicielle

Nicolas Gauthier — Tue, 29 Jul 2025 07:26:56 +0000

La conception d'un système logiciel repose avant tout sur la compréhension fine des interactions entre ses différents éléments constitutifs. Qu'il s'agisse de systèmes distribués, de modules au sein d'une application ou d'objets dans un paradigme orienté objet, la collaboration représente le cœur même de l'architecture logicielle.

La collaboration comme pierre angulaire

Les systèmes logiciels sont constitués d'éléments plus ou moins complexes qui communiquent entre eux, échangent des données et coordonnent leurs actions pour accomplir des objectifs. Cette collaboration se manifeste à travers différents mécanismes :

appels de méthodes,
échanges de messages,
partage de ressources,
synchronisation d'états
ou encore notification d'événements.

La qualité de ces interactions détermine directement les propriétés émergentes du système final :

sa robustesse,
sa maintenabilité,
ses performances
et sa capacité d'évolution.

Une collaboration mal conçue peut transformer un ensemble de composants individuellement fonctionnels en un système fragile et imprévisible.

L'essence de la stabilité et de la volatilité

Avant d'aborder toute question architecturale, il est crucial de caractériser la nature des collaborations selon leur degré de stabilité. Cette analyse permet de distinguer deux catégories fondamentales d'interactions.

Collaborations stables

Les collaborations stables correspondent aux interactions dont le comportement est prévisible et déterministe. Un collaborateur stable est celui dont les réactions peuvent être anticipées et maîtrisées par le système qui l'utilise. Il répond de manière cohérente aux mêmes sollicitations et ses comportements restent dans le périmètre de contrôle du système.

⚙️ Cas d'usage

Prenons l'exemple suivant, permettant à un système de transférer une somme d'argent entre deux comptes :

public class TransferMoneyUseCase {

    public void transfer(Account issuer, Account receiver, BigDecimal amount) {
        issuer.withdraw(amount);
        receiver.deposit(amount);
    }

}

public class Account {
    private final UUID id;
    private BigDecimal balance;

    public Account(UUID id, BigDecimal balance) {
        this.id = id;
        this.balance = balance;
    }

    public void withdraw(BigDecimal amount) {
        if (amount.compareTo(BigDecimal.ZERO) < 0)
            throw new IllegalAmountException();

        if (balance.compareTo(amount) < 0)
            throw new InsufficientFundsException();

        balance = balance.subtract(amount);
    }

    public void deposit(BigDecimal amount) {
        if (amount.compareTo(BigDecimal.ZERO) < 0)
            throw new IllegalAmountException();

        balance = balance.add(amount);
    }

    public BigDecimal getBalance() {
        return balance;
    }

    public UUID getId() {
        return id;
    }
}

Cette opération de transfert est réalisée par la classe TransferMoneyUseCase, laquelle collabore (par l'intermédiaire de sa méthode transfer) avec les objets Account et BigDecimal pour effectuer la transaction.

Intéressons-nous particulièrement au collaborateur Account. Comment peut-on qualifier les intéractions initiées par TransferMoneyUseCase ?

➡️ Prévisibles et déterministes

L’exécution des méthodes withdraw et deposit sur les instances d'Account donne toujours le même résultat pour un même contexte d'appel. Les cas limites sont clairement prévisibles et gérés par des exceptions métier explicites (IllegalAmountException, InsufficientFundsException).

➡️ Contrôlable par le système

La méthode transfer interagit directement avec une API publique maîtrisée (withdraw, deposit), sur des objets Account contrôlables à travers de :

leur état initial (le solde avant toute transaction),
leurs mécanismes d'interaction (les méthodes exposées),
leur état observable (le solde courant).

➡️ Sans interférence

Aucun effet secondaire non maîtrisé ne vient interférer lors de l'exécution : pas d'accès réseau, pas de base de données, pas d'élément asynchrone ou aléatoire. La classe Account encapsule les règles métier et reste indépendante de tout composant externe incontrôlable et imprévisible.

Collaborations volatiles

À l'opposé, les collaborations volatiles se caractérisent par leur imprévisibilité et échappent au contrôle du système. Elles concernent généralement les aspects périphériques, les intégrations avec des services externes, la gestion de l'aléatoire, la temporalité, etc. Leur comportement ne peut être ni anticipé ni maîtrisé par le système qui les utilise. Ces zones d'intéraction nécessitent alors une approche architecturale différente.

⚙️ Cas d'usage

Poursuivons avec notre cas d'usage précédent. Les opérations effectuées par le système lors du transfert nécessitent maintenant d'être sauvegardées dans un système externe (une base de données par exemple). Ce système, par sa nature, échappe au contrôle du système appelant. La collaboration devient alors non maitrisée.

public class TransferMoneyUseCase {
    private final AccountRepository accountRepository;

    public TransferMoneyUseCase() {
        this.accountRepository = new AccountRepository();
    }

    public void transfer(Account issuer, Account receiver, BigDecimal amount) {
        issuer.withdraw(amount);
        receiver.deposit(amount);

        accountRepository.save(issuer);
        accountRepository.save(receiver);
    }

}

Dans cet exemple, TransferMoneyUseCase dépend désormais d’un composant externe, AccountRepository, en charge de la persistence des comptes. Or, la base de données utilisée par ce repository n’est pas contrôlée par le système, ce qui introduit des effets de bord potentiels (état initial incohérent, erreur réseau, latence, indisponibilité, etc.).

Comment peut-on qualifier ces nouvelles intéractions ?

➡️ Imprévisibles par nature

La persistance dépend d’un système tiers, dont le comportement peut varier indépendamment du code métier (pannes, délais, erreurs de connexion...).

➡️ Non déterministes

Avec les mêmes entrées, le résultat de l'opération peut différer d'un appel à l'autre :

Rien ne garantie de l'existence préalable des comptes sur le système externe, celui-ci peut alors lever une exception.
La concurrence d'accès aux données modifiées peut produire des erreurs (dans le cas d'un verrouillage optimiste ou pessimiste par exemple).

➡️ Difficiles à tester directement

Tester cette collaboration nécessite soit d’accéder à un système réel (ce qui introduit de la lenteur et de la fragilité), soit de substituer le collaborateur (par exemple via un test double).

Complexité de l'identification des collaborations volatiles

L'exemple de collaboration volatile présenté précédemment constitue un cas typique, relativement facile à repérer. Cependant, d'autres situations s'avèrent plus délicates à identifier (aléatoire, temporalité, états partagés, etc.).

En amont de toute conception architecturale, il sera essentiel d'examiner ces collaborations volatiles et d'évaluer leur criticité en fonction de la capacité du système à les maîtriser.

Nous évoquerons plus en détail ces cas et leurs répercussions sur le système lorsque nous aborderons le chapître sur la répercussion sur la stratégie de tests.

Implications architecturales

Cette distinction entre contrôlabilité et imprévisibilité guide directement les choix architecturaux. Pour les collaborateurs volatils, l'architecture peut bénéficier de points de substitution permettant de remplacer ces éléments imprévisibles par des équivalents contrôlables (lors des tests par exemple). Cette approche s'avère particulièrement pertinente lorsque la volatilité compromet significativement la testabilité ou la robustesse du système.

C'est dans ce contexte qu'intervient l'inversion de dépendances : plutôt que de dépendre directement d'un collaborateur volatil, le système dépend d'une abstraction qu'il contrôle. Cette inversion transforme une dépendance subie (vers quelque chose d'imprévisible) en une dépendance maîtrisée (vers une interface sous contrôle). Le collaborateur volatil devient alors un détail d'implémentation injecté de l'extérieur, substituable selon les besoins.

La décision d'introduire cette abstraction doit néanmoins être équilibrée : elle apporte de la flexibilité et de la testabilité au prix d'une complexité architecturale supplémentaire. Dans certains cas, accepter une volatilité limitée peut s'avérer plus pragmatique que multiplier les couches d'abstraction.

Les zones stables adoptent en général des couplages plus directs, car leur comportement déterministe ne compromet pas la robustesse du système.

⚙️ Cas d'usage

Reprenons avec notre exemple. Le collaborateur chargé de persister l'état des comptes étant volatile, notre architecture subit quelques modifications :

public interface AccountRepository {
    void save(Account account);
}

AccountRepository est ici une interface contractualisant une intension : Sauvegarder un compte.

public class JpaAccountRepository {

    @PersistenceContext
    private EntityManager entityManager;

    @Transactional
    public void save(Account account) {
        AccountEntity accountEntity = this.entityManager.find(AccountEntity.class, account.getId());
        accountEntity.setBalance(account.getBalance());
    }

}

JpaAccountRepository est une implémentation concrète de l'interface AccountRepository. Elle aura en charge de persister les données de comptes dans le système externe.

public class TransferMoneyUseCase {
    private final AccountRepository accountRepository;

    public TransferMoneyUseCase(AccountRepository accountRepository) {
        this.accountRepository = accountRepository;
    }

    // ...

}

La classe TransferMoneyUseCase requiert désormais l'injection d'un collaborateur implémentant l'interface AccountRepository. Elle ne dépend plus de son implémentation réelle, mais impose par un contrat la façon dont elle interagira avec le système externe pour sauvegarder les comptes.

AccountRepository accountRepository = new JpaAccountrepository();
TransferMoneyUseCase transferMoneyUseCase = new TransferMoneyUseCase(accountRepository);

L'implémentation concrète JpaAccountRepository est injectée à l'instanciation de notre classe TransferMoneyUseCase, mais ceci devient désormais un détail pour notre cas d'usage.

Répercussions sur la stratégie de tests

La nature des collaborations influence directement la stratégie de test à adopter.

Les collaborateurs stables, étant déterministes et contrôlables, peuvent être conservés dans les tests unitaires, car ils n'introduisent pas d'aléa. Leur présence renforce même la confiance en ces tests puisqu'ils valident les interactions réelles.

Les collaborateurs volatils quant-à-eux doivent être substitués, car leur imprévisibilité compromettrait la fiabilité des tests. Un test unitaire qui dépend d'un service externe imprévisible n'est plus vraiment unitaire puisqu'il n'en respecte pas une des caractéristiques fondamentales : sa reproductibilité.

⚙️ Cas d'usage

Reprenons notre cas d'usage encore une fois. Comment tester désormais de manière prévisible et contrôlée notre système ? C'est là qu'interviennent les tests doubles. Il en existe différents types, mais ce n'est pas le sujet de cet article.

Commençons tout d'abord par vérifier les collaborations stables de notre cas d'usage.

public class AccountRepositoryStub implements AccountRepository {
    public void save(Account account) {
        // do nothing
    }
}

@Test
void shouldTransferMoneyBetweenAccounts() {
    // Arrange
    Account issuer = new Account(UUID.randomUUID(), new BigDecimal("100.00"));
    Account receiver = new Account(UUID.randomUUID(), new BigDecimal("50.00"));
    AccountRepository accountRepository = new AccountRepositoryStub();
    TransferMoneyUseCase useCase = new TransferMoneyUseCase(accountRepository);

    // Act
    useCase.transfer(issuer, receiver, new BigDecimal("30.00"));

    // Assert
    assertEquals(new BigDecimal("70.00"), issuer.getBalance());
    assertEquals(new BigDecimal("80.00"), receiver.getBalance());
}

Dans cet exemple, nous ne vérifions que les collaborations stables, par l'intermédiaire des changements d'états de nos objets Account après la transaction. Utiliser le collaborateur réel pour gérer la persistence nuirait au bon fonctionnement de notre test, c'est pourquoi nous le substituons par un Stub (AccountRepositoryStub) respectant le contrat.

Comment maintenant vérifier que les changements d'état de nos comptes ont bien été sauvegardés dans notre système externe ?

La responsabilité de la sauvegarde physique des données n'est pas à la charge de notre classe TransferMoneyUseCase. Par contre, il est de sa responsabilité d'interagir avec AccountRepository pour effectuer cette sauvegarde. Nous pourrions alors substituer le collaborateur AccountRepository par un Fake, afin de vérifier que le système cible a pris en charge la modification.

Ceci pourrait donner :

public class InMemoryAccountRepository implements AccountRepository {
    private Map<UUID, Account> store;

    public InMemoryAccountRepository(Map<UUID, Account> store) {
        this.store = store;
    }

    public void save(Account account) {
        this.store.put(account.getId(), account);
    }
}

@Test
void shouldSaveAccountsAfterTransfer() {
    // Arrange
    Account issuer = new Account(UUID.randomUUID(), new BigDecimal("100.00"));
    Account receiver = new Account(UUID.randomUUID(), new BigDecimal("50.00"));
    Map<UUID, Account> store = new HashMap<>();
    AccountRepository accountRepository = new InMemoryAccountRepository(store);
    TransferMoneyUseCase useCase = new TransferMoneyUseCase(accountRepository);

    // Act
    useCase.transfer(issuer, receiver, new BigDecimal("30.00"));

    // Assert
    assertTrue(store.contains(issuer.getId()));
    assertEquals(new BigDecimal("70.00"), store.get(issuer.getId()).getBalance());
    assertTrue(store.contains(receiver.getId()));
    assertEquals(new BigDecimal("80.00"), store.get(receiver.getId()).getBalance());
}

Le système externe est désormais simulé par l'implémentation mémoire InMemoryAccountRepository et reproduit de façon minimale le comportement du collaborateur réel JpaAccountRepository. Ce collaborateur est totalement contrôlé et son fonctionnement devient prévisible. Notre test devient alors fiable et robuste, et découplé de l'implémentation réelle.

Conserver le contrôle du système lors des tests

Nous l'avons largement évoqué, l'imprévisibilité conduit forcément à une perte de contrôle du système.

Bien que les collaborations avec des systèmes externes constituent une grande majorité de cas prévus pour être substituables facilement, d'autres sont plus difficilement identifiables et ont un impact direct sur la testabilité.

La testabilité est importante, mais elle ne justifie pas systématiquement l’introduction de complexité : chaque décision de substitution doit s’inscrire dans une logique de compromis éclairé.

En effet, des alternatives à la substitution existent : environnements de test contrôlés (containers), isolation des effets de bord dans des couches dédiées, ou encore outils spécialisés pour gérer certains types de volatilité (environnement, date/zone, etc...). Ces approches peuvent parfois offrir un meilleur équilibre entre simplicité architecturale et contrôle de la testabilité, mais ne seront pas abordées en détail dans cet article.

L'aléatoire

Toute génération de données aléatoires introduit de l'imprévisibilité dans le système. Qu’il s’agisse de la création d’un identifiant unique (UUID), d’une chaîne de caractères, d’un entier pseudo-aléatoire ou d’une opération mathématique incluant une part de hasard, chaque appel peut produire un résultat différent. Cette variabilité fragilise le raisonnement autour du comportement attendu et rend les tests non reproductibles.

Pour restaurer la prédictibilité dans les tests, il pourrait être judicieux d’introduire une dépendance injectable.

Par exemple :

// Inversion de la dépendance entre le système et le collaborateur réel
public interface UUIDProvider {
    UUID get();
}

// Implémentation réelle injectée par défaut dans le système
public class RandomUUIDProvider implements UUIDProvider {
    @Override
    public UUID get() {
        return UUID.randomUUID();
    }
}

// Implémentation contrôlable, injecté depuis les tests.
public class FixedUUIDProvider implements UUIDProvider {
    private final UUID fixedUUID;

    public FixedUUIDProvider(UUID fixedUUID) {
        this.fixedUUID = fixedUUID;
    }

    @Override
    public UUID get() {
        return fixedUUID;
    }
}

La temporalité

Les dépendances temporelles constituent une autre source majeure de volatilité. Lorsqu’un système s’appuie sur la date ou l’heure (date courante, date fixée, jour de la semaine, heure du jour, etc.), son comportement devient dépendant du moment d’exécution. Ce type de dépendance rend les tests non déterministes (ils peuvent échouer ou réussir selon le moment), et empêche toute validation fiable sans contrôle du temps.

Comme précédemment, il conviendra éventuellement de prévoir un mécanisme de substitution.

Par exemple :

// Inversion de la dépendance entre le système et le collaborateur réel
public interface ClockProvider {
    Instant now();
}

// Implémentation réelle injectée par défaut dans le système
public class SystemClockProvider implements ClockProvider {
    @Override
    public Instant now() {
        return Instant.now();
    }
}

// Implémentation contrôlable, injecté depuis les tests.
public class FixedClockProvider implements ClockProvider {
    private final Instant fixedNow;

    public FixedClockProvider(Instant fixedNow) {
        this.fixedNow = fixedNow;
    }

    @Override
    public Instant now() {
        return fixedNow;
    }
}

L'environnement

L’environnement d’exécution peut influencer le comportement d’un composant de manière invisible, mais significative. Cela inclut :

les variables d’environnement,
les fichiers de configuration,
les paramètres système (fuseau horaire, langue, encoding),
etc.

Tout accès implicite à ces éléments introduit de la variabilité externe, difficile à anticiper dans un test unitaire. Pour rester prévisible, un test doit fonctionner indépendamment de l’environnement.

Imaginons un cas d'activation / désactivation de fonctionnalité basé sur la valeur d'une variable dans l'environnement. Comment rendre le contrôle et la maitrise au système et permettre sa testabilité ?

// Inversion de la dépendance entre le système et le collaborateur réel
public interface EnvironmentProvider {
    String get(String name);
}

// Implémentation réelle injectée par défaut dans le système qui récupère une variable d'environnement
public class SystemEnvironmentProvider implements EnvironmentProvider {
    @Override
    public String get(String name) {
        return System.getenv(name);
    }
}

// Implémentation contrôlable, injecté depuis les tests. 
public class StubEnvironmentProvider implements EnvironmentProvider {
    private final Map<String, String> values;

    public StubEnvironmentProvider(Map<String, String> values) {
        this.values = values;
    }

    @Override
    public String get(String name) {
        return values.get(name);
    }
}

L’état partagé mutable

Un système devient instable lorsqu’il s’appuie sur un état partagé global et mutable, tel que :

des variables static,
un cache en mémoire commun à plusieurs tests,
ou des ressources singleton accessibles globalement.

Cette approche rend les tests vulnérables aux effets de bord et aux interférences croisées. Un test peut influencer l’état d’un autre sans lien apparent, introduisant des pannes sporadiques difficiles à diagnostiquer.

Une démarche méthodologique

L'analyse de la collaboration doit précéder toute décision architecturale. Elle implique d'identifier les acteurs du système, de cartographier leurs interactions, puis d'évaluer pour chaque collaboration : "Est-ce que je contrôle ce comportement ?", "Est-il nécessaire de garder le contrôle ?" Ces questions simples permettent de catégoriser chaque collaboration selon son degré de contrôlabilité.

Cette démarche permet d'éviter les écueils classiques : sur-ingénierie des zones volatiles par excès d'abstraction, ou sous-estimation de leur complexité. Elle conduit à une architecture adaptant les solutions techniques à la nature réelle des problèmes rencontrés.

La maîtrise des collaborations, centrée sur la notion de contrôlabilité, constitue ainsi le préalable indispensable à toute réflexion architecturale cohérente et à une stratégie de test efficace.

L'attaque des clones mutants : améliorez la fiabilité de vos tests à l'aide des tests de mutation

Nicolas Gauthier — Tue, 26 Nov 2024 08:01:47 +0000

Il y a bien longtemps, dans une galaxie lointaine, très lointaine…

Une sombre menace plane sur la planète Quality. Des clones mutants, silencieux et perfides, se répandent dans le code, menaçant d’infiltrer chaque système pour semer le chaos et la destruction.

Mais l’espoir n’est pas perdu. La courageuse princesse Leia rassemble ses troupes de développeurs et, armée de puissants tests, prépare une contre-attaque acharnée pour éradiquer ces mutants et sauver Quality de l’effondrement.

Développeurs, soyez prêts. La planète Quality a besoin de vous ! Ensemble, nous apprendrons à nous défendre contre ces mutants et repousser l'obscurité qui menace notre code.

Un peu de contexte...

En tant que développeurs, on aime quand tout se passe comme prévu. Une pratique aujourd'hui indispensable de notre quotidien consiste à écrire des tests automatisés en amont ou en aval des développements. On peut justifier ces tests pour :

Détecter les bugs au plus tôt en cas d'évolution, et vérifier la non-régression,
Spécifier de nouvelles exigences et vérifier que le code fonctionne comme attendu,
Gagner du temps lors de la phase de tests manuels,
Gagner du temps lors des phases de développement futures et faciliter le refactoring,
Documenter le code,
Ou encore, guider le développeur explorateur dans le design de son code.

Les tests, c'est bien. Encore faut-il qu'ils soient pertinents, robustes et suffisamment exhaustifs.

Modifier le code en toute confiance, tester te permettra ; et en production le vendredi, sereinement déployer, tu pourras.

— Yoda (Grand maître développeur)

Les tests de mutation, qu'est-ce que c'est ?

Revenons au sujet de cet article : Les tests de mutation.

Les tests de mutation, c'est un peu comme un jeu d'attrape-moi-si-tu-peux dans le code. L'idée est d'y introduire volontairement de petits changements affectant le comportement du code, qu'on appelle mutants, et de vérifier si les tests existants sont capables de les détecter.

Comment sont générés ces mutants ? Généralement, les outils permettant de les générer travaillent directement au niveau du bytecode pour appliquer des modifications, par exemple :

Changer des opérateurs arithmétiques,
Altérer des opérateurs de comparaison,
Modifier des constantes,
Retirer des blocs de code,
Modifier des valeurs de retour,
etc.

Ensuite, l'objectif est simple : les tests doivent tuer les mutants.
Pour tuer un mutant, au moins un des tests doit échouer.

La Force est avec moi ! Mais n'est-ce pas créer un déséquilibre que de pousser nos tests à l'échec ?

— Luke Skywalker (Développeur innocent)

Luke, je sens la peur t'envahir, laisse-toi aller vers le côté obscur et ensemble nous...

— Darth Vader (Développeur malveillant)

Voooous ne passereeeez paaaaaaaaaas ! kof kof ... kof...

— Gandalf (Développeur itinérant)

Les limites de la couverture de code

Quand on évoque la notion de couverture de code, on pense généralement qu'il s'agit de la part de code traversé par l'exécution des tests automatisés. Cette métrique est très souvent mise en œuvre pour justifier d'une certaine qualité du code.

Souvent, elle est imposée au niveau d'une entreprise sans en considérer les objectifs sous-jacents.
Il n'est pas rare d'exiger un taux de couverture de 80%, 90%... Objectif qui peut être, selon le contexte, facilement atteignable. On parle alors d'Assertion Free Testing.

Chewie, tu entends ? Nous n'avons qu'à traverser, alors traversons !

— Han Solo (Développeur fougueux)

Rawrgwawgrr !

— Chewbacca (Développeur d'accord)

En changeant notre point de vue sur la couverture de code, on parvient à rendre nos tests plus pertinents. Les tests de mutations sont un outil supplémentaire pour parvenir à cet objectif, qui vont nous permettre de révéler les défaillances de la couverture de code et donc de nos tests. En plus de la couverture induite par l'exécution, ils se concentrent sur la vérification des assertions.

La couverture doit être une conséquence et non un objectif, concentre ta force là où elle te permettra d'aller plus loin.

— Obi-Wan Kenobi (Développeur sage)

Les tests de mutation par l'exemple

La théorie, c'est nécessaire, mais la pratique, c'est indispensable pour se forger un avis.

Dans la suite de cet article, nous allons mettre en place ce type de tests dans un projet Java qui me sert de base à moultes expérimentations.

Je suis prête à tous les affronter. Vitesse lumière !

— Rey (Développeuse curieuse... et fougueuse aussi)

PITest : des mutants au sein de mes tests Java

De nombreux outils de mutation testing existent selon les langages : Stryker pour JavaScript / TypeScript, mutmut pour le langage python... Il en est un dans l'écosystème Java (et JVMs associées) très populaire : PITest.

Sa configuration avec un plugin maven est relativement simple.

ℹ
Pour plus d'informations sur les possibilités de configuration du plugin, je vous recommande d'aller voir la documentation existante : PITest : Maven Quick Start

<plugins>
  ...
  <plugin>
    <groupId>org.pitest</groupId>
    <artifactId>pitest-maven</artifactId>                       #1
    <version>${pitest-maven.version}</version>
    <dependencies>
      <dependency>
        <groupId>org.pitest</groupId>
        <artifactId>pitest-junit5-plugin</artifactId>           #2
        <version>${pitest-junit5-plugin.version}</version>
      </dependency>
    </dependencies>
    <configuration>
      <outputFormats>
        <outputFormat>HTML</outputFormat>                       #3
      </outputFormats>
      <targetClasses>
        <targetClass>n.g.a.games.playhaa.games.**.domain.**.*</targetClass>   #4
      </targetClasses>
      <targetTests>
        <targetTest>n.g.a.games.playhaa.games.**.domain.**.*Test</targetTest> #5
      </targetTests>
    </configuration>
  </plugin>
  ...
</plugins>

#1 - Le plugin maven pour PITest
#2 - Le plugin de support pour les tests écrits avec JUnit 5
#3 - Le format de sortie : Par défaut, c'est HTML (mais c'est pour vous dire que ça existe...)
#4 - Le filtre de sélection des classes à muter
#5 - Le filtre de sélection des tests à exécuter avec les mutations

Maintenant que vous avez intégré PITest à votre projet, il ne vous reste plus qu'à lancer votre premier test de mutation à l'aide de la commande suivante :

mvn clean test-compile org.pitest:pitest-maven:mutationCoverage

Les mutants ont-ils survécu ? Analyse des résultats de l'exécution de PITest

À la suite de l'exécution des tests, un rapport HTML a été généré dans le répertoire target/pit-reports.
Ouvrons le fichier index.html et analysons un peu les résultats.

Tout d'abord, on a un résumé des résultats globaux :

Number of classes : C'est le nombre total de classes qui ont muté dans le projet (correspondant au filtre targetClasses),
Line Coverage : C'est le taux de couverture du code par les tests (exécution),
Mutation Coverage : C'est le ratio entre le nombre de mutants tués par les tests et le nombre de mutants générés,
Test Strength : C'est le ratio entre le nombre de mutants tués parmi tous les mutants couverts par les tests.

Ces résultats globaux sont suivis d'une synthèse des résultats par package. Pour chaque package, il est possible d'aller consulter un rapport plus détaillé :

Si l'on souhaite obtenir le détail sur les mutations qui ont été réalisées, il est également possible d'accéder au rapport de chacune des classes qui ont été mutées :

On voit que ce n'est pas fait en TDD, maître...

— C3PO (Développeur rabat-joie)

Que constate-t-on ?

Dans le package n.g.a.games.playhaa.games.join.domain, le taux de couverture de code est de 100%.
... Par conséquent, la couverture pour la classe JoinGameService est également de 100%.
Toutefois, dans cette classe, 3 mutants ont survécu, car non détectés par les tests :
- À la ligne 43, l'addition a été remplacée par une soustraction
- À la ligne 44, la condition a été inversée
- À la ligne 45, la condition a également été inversée

Pourquoi de telles mutations qui semblent absolument non pertinentes ? Parce que le code évolue, les développeurs changent, le code devient de plus en plus riche et parfois complexe. L'introduction d'un changement sans en mesurer la portée peut avoir des effets de bords non désirés et provoquer des bugs.

Ces mutations représentent la réalité de ce qui peut arriver dans la vie d'un logiciel.

Si ces mutants ont survécu aux tests, c'est qu'aucun test n'a échoué suite à leur introduction. En résumé, il manque au moins une assertion.

L'explication du taux de couverture de 100% se trouve dans un test écrit pour le cas nominal.

@DisplayName("Should join an existing game")
@Test
void shouldJoinAnExistingGame() {
    // Arrange
    GameId joinedGameId = new GameId("2a8fb592-876f-4f38-a014-3df9e810b1b0");

    // ... prepare existing joinable game
    int maxPlayers = 2;
    DeckId creatorDeckId = new DeckId("3a8fb592-876f-4f38-a014-3df9e810b1b0");
    Deck creatorDeck = TestDeckBuilder.defaultBuilder().id(creatorDeckId).build();
    GamePlayer currentCreatorPlayer = TestGamePlayerBuilder.defaultBuilder().deck(creatorDeck).build();

    Game existingGame = new Game(joinedGameId,
            "L'attaque des clones", Difficulty.STANDARD, GameStatus.WAITING,
            List.of(currentCreatorPlayer), maxPlayers); // #1

    // ... prepare command
    DeckId joinerDeckId = new DeckId("73fa2619-5838-40e6-9aa9-8a341db3c418");
    JoinGameCommand joinGameCommand = new JoinGameCommand(joinedGameId, joinerDeckId); // #2

    // ... prepare use case
    JoinGameRepository joinGameRepository = new InMemoryJoinGameRepository(existingGame);
    JoinGameUseCase useCase = new JoinGameService(joinGameRepository);

    // Act
    Game gameUpdated = useCase.join(joinGameCommand); // #3

    // Assert
    assertEquals(joinedGameId, gameUpdated.id());
    assertTrue(gameUpdated.hasPlayerDeck(joinerDeckId)); // #4
}

#1 - On simule une partie existante avec un seul joueur (le créateur) et un nombre de joueurs maximum de 2.
#2 - On initie une commande avec l'id de la partie à rejoindre et l'id du deck du nouveau joueur
#3 - On appelle la méthode join du service lié à notre cas d'utilisation
#4 - On vérifie que le deck du nouveau joueur est bien présent dans la partie

L'objectif de ce test est de vérifier qu'un nouveau joueur qui rejoint une partie s'y retrouve bien. En aucun cas, on ne vérifie l'état de la partie, ce n'est pas l'objectif ici.

En analysant davantage les tests existants de cette classe, on constate qu'aucun d'entre eux ne vient vérifier un changement sur l'état d'une partie suite à l'arrivée du dernier joueur et c'est la cause de la survie de nos chers mutants !

Ajoutons donc un nouveau test avec l'assertion sur l'état du jeu :

@DisplayName("Should mark game as READY when max players is reached")
@Test
void shouldMarkGameAsReadyWhenMaxPlayersIsReached() {

    // ... les conditions d'entrée sont identiques au test du cas nominal précédent

    // Assert
    assertEquals(GameStatus.READY, gameUpdated.status());
}

Maintenant que nous avons ajouté ce nouveau test, relançons nos tests de mutation et vérifions les résultats obtenus :

Les mutants introduits dans notre classe ont tous été éliminés !

Un peu d'explications :

Lors de l'exécution du test du cas nominal vu précédemment - sans mutation -, la partie passe bien à l'état READY. Cependant, aucune assertion ne permettait de s'en assurer. Nos 3 mutants ont alors saisi cette occasion pour s'introduire discrètement dans notre classe et passer inaperçus.

Nos efforts pour consolider les tests ont porté leurs fruits. Grâce à votre détermination, nous avons renforcé nos défenses et remporté une première bataille.

Que la force soit avec nous !

— Princesse Leia Organa (Lead Développeuse motivante)

Les limites des tests de mutation

Parlons maintenant des limites de ces tests, car il y en a bien sûr ! On peut citer principalement :

Le temps d'exécution,
La consommation en ressources machine.

L’un des coûts principaux de la MT est les ressources computationnelles nécessaires pour exécuter les tests. Cette technique implique la génération d’un grand nombre de mutants, chacun représentant une version légèrement modifiée du logiciel original, et l’exécution de la suite de test contre chacun de ces mutants. À mesure que le nombre de mutants augmente, la quantité de puissance de calcul et le temps d’exécution requis pour le processus de test augmentent de manière exponentielle.

— Moez Krichen (Une enquête sur le test de mutation)

Concentrons-nous sur la limite de temps d'exécution. Dans le cas des tests de mutation, ce temps est fonction de plusieurs paramètres, par exemple :

Les caractéristiques de la machine qui exécute les tests (processeur, mémoire, etc.),
Le nombre de classes à muter et donc le nombre de mutants générés,
Le nombre de tests sélectionnés et leur temps d'exécution dans un contexte normal (sans mutations),
Les optimisations apportées telles que la parallélisation, les types de mutants générés,
etc.

Essayons de faire quelques tests dans le projet qui nous sert en exemple dans cet article.

Les résultats suivants sont obtenus sur un environnement de développement local. Ils sont exécutés sur un laptop possédant un processeur Core i7 (1.80Ghz / 4 cœurs) et 16Go de RAM.
Le terme domaine, employé par la suite, correspond au cœur de l'application. Il est préservé de toute dépendance extérieure au projet (librairies, frameworks, etc.) et ne dépend pas de ce qui l'entoure (controllers HTTP, repositories JPA, etc.). On y retrouve uniquement des tests unitaires (qui doivent-être rapides à s'exécuter). À l'extérieur du domaine, on retrouvera des tests unitaires, mais aussi des tests d'intégration (qui sont plus longs à s'exécuter).
Le nombre de threads utilisés pour paralléliser l'exécution des tests de mutation avec PITest est de 4,
Enfin, aucune optimisation supplémentaire n'a été réalisée lors de ces tests. L'objectif est ici, d'obtenir de premiers résultats et d'en sortir quelques hypothèses.

Contexte	Le domaine "games"	Tous les domaines	Tout le projet
Nombre de classes sélectionnées	9	20	66
Nombre de mutants générés	84	167	499
Nombre de tests sélectionnés	24	62	131 #1
Nombre d'exécutions de tests	111	218	855
Temps d'exécution des tests de mutation #2	26 sec	54 sec	11 min 11 sec
Temps d'exécution de référence des tests sélectionnés #3	982 ms	1 sec 673 ms	14 sec 72 ms #4

#1 - Le périmètre projet ici inclut des tests d'intégration qui sont plus longs à s'exécuter
#2 - Temps nécessaire à l'exécution parallèle des tests de mutation,
#3 - Temps nécessaire à l'exécution des tests sélectionnés, sans mutations et sans parallélisation,
#4 - Dont 11 secondes pour les tests d'intégration nécessitant le démarrage de l'application context.

On peut d'ores et déjà constater que ces paramètres ont eu un impact significatif sur les temps d'exécution :

Le nombre de classes en entrée (et donc le nombre de mutants générés)
Le temps d'exécution trop long de certains tests (ici les tests d'intégration)

Que peut-on en conclure ?

Les avantages d'intégrer les tests de mutation dans notre processus de développement logiciel sont réels, nous avons pu le voir. Ils nous permettent d'identifier les lacunes et les faiblesses dans nos tests dans l'optique de les consolider.

Les projets vivent, les développeurs changent, ainsi que les pratiques de test. Ces mutants seront alors de précieux alliés qui permettront de maintenir un niveau de qualité et de fiabilité dans le temps.

Toutefois, il faut également considérer leurs limites, dont les principales : le temps d'exécution global pour l'ensemble des mutants générés, et la consommation en ressources de calcul. Pour contourner ces limites, il conviendra alors de faire les meilleurs choix possibles en fonction de votre contexte.

Tout ceci est bien joli maître, mais si cela avait été fait en TDD, sans doute que...

Maître, que faites-vous ... non ne touchez (...)

— C3PO (Développeur rabat-joie une fois de trop)

Et maintenant... c'est à vous de jouer ;)

💡 En complément, on peut aussi reconsidérer un peu sa manière de concevoir et de tester. Il est une pratique qui, si elle est maitrisée, permet de grandement limiter ces défaillances : le TDD (Test Driven Development), mais ça, c'est une autre histoire...