4) Améliorer la lisibilité des tests
Les tests sont, pour l'instant, assez difficiles à comprendre :
1 classe de tests avec
948 locIl y a de la duplication partout
Ce qui influe le résultat du test n'est pas mis en évidence

Prenons un exemple pour illustrer cela :
On va essayer d'améliorer la situation en suivant les étapes proposées ci-dessous.
Splitter la classe de tests
On commence par déplacer les classes de test à l'extérieur de
PartieDeChasseServiceTestsChaque classe de test va maintenant hériter de
PartieDeChasseServiceTestsOn change l'accessibilité (
protected) deTimeProvideretAssertLastEvent
On peut ensuite sortir chaque classe de tests dans son propre fichier de manière
safe

On se retrouve alors avec une hiérarchie de tests comme suit

On en profite pour séparer les tests unitaires et le test d'acceptation

On peut aller plus loin en séparant dans chaque fichier les cas passants et non-passants :
Utiliser des Test Data Builders
Test Data BuildersPrenez le temps de découvrir le pattern expliqué ici.
On va commencer à modifier un premier test en utilisant le pattern et en faisant ressortir ce qui influe sur le résultat du test.
Pour cela on identifie les pré-requis ci-dessous:
Centraliser l'instantiation du Service / Repository
On commence par extraire des
Fieldsà partir du test

Ensuite on remonte les champs dans la class de base

On peut dès lors refactorer l'ensemble des tests et réduire la duplication.
Écrire son premier Test Data Builder
Test Data BuilderOn commence par écrire de manière textuelle ce qu'on souhaite pour instantier la
PartieDeChasse

Ensuite on peut générer le code à partie de notre
IDE

On dévéloppe les méthodes du
Builder
On écrit également le
ChasseurBuilderOn peut mélanger
BuilderetObject Mother
Notre test ressemble alors à cela :
Comment aller plus loin ?
Simplifier l'utilisation du repository
On crée une méthode nous permettant de faire le setup du repository
Alternativement on pourrait écrire une version plus orientée fonctionnelle (Higher Order Functions)
Améliorer les Assertions
De la même manière que pour la partie Arrange, on va améliorer la lisibilité de nos tests en créant des extensions pour nos Assert.
En utilisant FluentAssertions, on peut utiliser le modèle d'extensions décrit ici.
Cela va permettre de se focaliser sur la mutation entrainée sur la PartieDeChasse lors de l'appel à un comportement métier. On commence alors par identifier ce qu'il faut mettre en avant pour ce test :
On écrit une première version de ce qu'on voudrait en terme d'assertions

On crée une classe d'extensions permettant de renvoyer une instance de
PartieDeChasseAssertions
On en profite pour ajouter les namespaces
AssertetBuildersdans le fichierUsings.cs
On écrit le code d'assertion
On lance notre test : il passe ✅
On va maintenant s'assurer du bon fonctionnement de nos
assertionsen introduisant des mutants à la main dans la classePartieDeChasseServiceC'est vital de le faire : les builders et assertions vont être la base de tous nos tests
On doit être confiant au maximum vis-à-vis d'eux
Le mutant est détecté par notre
assertOn répète le processus avec d'autres mutants afin de se rassurer
On peut maintenant adapter tous les tests pour utiliser les nouvelles classes créées et étendre les Builders et Assertions.
Nouveau rapport SonarCloud disponible ici.
Reflect
Comparez les tests avant et après cette étape, qu'en pensez-vous ?
On en a profité pour se construire un petit DSL permettant de spécifier nos tests à la gherkin avec la syntaxe Given / When / Then

Last updated
Was this helpful?