5) "Approve Everything"
Il y a quelques tests pour lesquels nous avons énormément de lignes d'assertions. Nous allons les retravailler afin de les transformer en Approval Tests.
Prendre du temps pour comprendre ce qui se cache derrière cette notion d'Approval Testing
Identifier des tests sur lesquels on pourrait utiliser cette technique
Refactorer un test existant en utilisant la librairie Verify

Identification des tests
On pourrait utiliser cette technique pour les tests suivants :
DemarrerUnePartieDeChasse.AvecPlusieursChasseursLimitera les asserts à une seule ligne
Moins de maintenance et assertions plus lisibles
ConsulterStatus:QuandLaPartieVientDeDémarrer/QuandLaPartieEstTerminéeScenarioTests.DéroulerUnePartieOn valide le contenu d'un
stringCela évitera de stocker ce string dans le code (sera stocké sous forme de ressource)
Refactorer ScenarioTests.DéroulerUnePartie
ScenarioTests.DéroulerUnePartieOn commence par ajouter la dépendance sur notre librairie d'Approval Testing
On peut ensuite extraire le contenu de l'assertion dans un fichier "Approved" ici "verified"
On crée un fichier appelé :
ScenarioTests.DéroulerUnePartie.verified.txt([Nom de la classe de tests].[Nom du test].verified.txt)C'est sur base de ce fichier que l'assertion se fera via
Verify

On transforme le test en
Approval TestenAjoutant l'annotation
UsesVerifysur la classe de testChangeant la méthode de test pour que celle-ci renvoie une
Task
Le test passe du premier coup 👌
On va faire en sorte de le faire passer au rouge : ne jamais croire un test qu'on a pas vu échouer...
Pour cela le plus simple est de changer le fichier verified.
Notre Approval Test échoue, notre outil de comparaison de fichier va s'ouvrir :

Dès lors nous avons une arborescence de fichiers ressemblant à celà :

Un élément important quand on utilise une librairie de ce genre, ajouter les fichiers received dans le fichier .gitignore :
Félicitations, notre premier test passe et on peut se fier à lui.
En revanche, le test n'est pas très lisible / maintenable :
Beaucoup de duplication
try / catchvideMéthode de plus de
80 loc
On va y appliquer la fameuse règle du boyscout.

Boy Scout Rule
On commence par extraire des champs à partir du test via notre
IDE

Puis on configure l'extraction

Le résultat est :
On va utiliser le
CommandBuilderégalementAfin de supprimer les
stringhardcodés
On va ensuite supprimer la duplication en faisant une extraction des constantes :
Bernard,Robert,Dédé,ChasseurInconnuPour pouvoir les utiliser dans cette classe de test également
On les place dans un fichier
Data

Notre test ressemble désormais à cela
On va extraire une méthode à partir de cela en identifiant les similitudes et différences
On prépare notre
extractionen décomposant le code ci-dessus en :
Extraction de la méthode

Puis on configure l'extraction

On l'utilise partout en s'assurant que notre test reste vert
En rendant également
safel'appelle à la méthodeact
Refactorer DemarrerUnePartieDeChasse.AvecPlusieursChasseurs
DemarrerUnePartieDeChasse.AvecPlusieursChasseursOn commence par changer le test
Ici on va "approuver" la représentation textuelle de la
PartieDeChasse
Voici le résultat
Par défaut,
Verifyva scrubber les donées non déterministes (DateTimeetGuidici)

Concernant la date, on perd 1 assertion faites dans le test avant refactoring
On change la configuration pour ce test
On peut maintenant approver le résultat du test qui ressemble à cela

Impact du refactoring des tests
Codescene
Après les refactorings des tests, on peut lancer une analyse codescene pour vérifier leur impact sur l'état de notre code base :

Nous sommes passé d'une Code Health de 8,4 à 9,8 👌
Les hotspots ont changé de taille (rouges car les commits sont très récents)

Il reste 1 refactoring target : PartieDeChasseService

SonarCloud
Rapport disponible ici.
Reflect
Que pensez vous de cette technique ?
Quels autres cas d'utilisation pouvez-vous identifier ?
Qu'est-ce que le
scrubbing?

Last updated
Was this helpful?