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

Step 5 : "Approve Everything"

Identification des tests

On pourrait utiliser cette technique pour les tests suivants :

  • DemarrerUnePartieDeChasse.AvecPlusieursChasseurs

    • Limitera les asserts à une seule ligne

    • Moins de maintenance et assertions plus lisibles

  • ConsulterStatus : QuandLaPartieVientDeDémarrer / QuandLaPartieEstTerminée

  • ScenarioTests.DéroulerUnePartie

    • On valide le contenu d'un string

    • Cela évitera de stocker ce string dans le code (sera stocké sous forme de ressource)

Refactorer ScenarioTests.DéroulerUnePartie

  • On 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

Approved Content
  • On transforme le test en Approval Test en

    • Ajoutant l'annotation UsesVerify sur la classe de test

    • Changeant 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 :

Comparaison de fichiers

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

Files

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 / catch vide

  • Mé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

Introduce field
  • Puis on configure l'extraction

Configurer "Introduce Field"
  • Le résultat est :

  • On va utiliser le CommandBuilder également

    • Afin de supprimer les string hardcodés

  • On va ensuite supprimer la duplication en faisant une extraction des constantes : Bernard, Robert, Dédé, ChasseurInconnu

    • Pour pouvoir les utiliser dans cette classe de test également

    • On les place dans un fichier Data

Move to <type>
  • 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 extraction en décomposant le code ci-dessus en :

  • Extraction de la méthode

Extract method
  • Puis on configure l'extraction

Configure "Extract Method"
  • On l'utilise partout en s'assurant que notre test reste vert

    • En rendant également safe l'appelle à la méthode act

Refactorer DemarrerUnePartieDeChasse.AvecPlusieursChasseurs

  • On commence par changer le test

    • Ici on va "approuver" la représentation textuelle de la PartieDeChasse

  • Voici le résultat

    • Par défaut, Verify va scrubber les donées non déterministes (DateTime et Guid ici)

Scrubbed data
  • 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

Verify démarrer

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 :

Code health

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)

Hotspots

Il reste 1 refactoring target : PartieDeChasseService

Refactoring target

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?