[BreizhCamp 2015] Refactoring avec 1,22% de code couvert par les tests ... Golden Master testing à la rescousse !

Lors de ce quickie du BreizhCamp 2015, Sébastien Prunier nous a présenté la technique du Golden Master Testing pour mettre en place des tests de non-régression efficaces de façon rapide dans un contexte difficile. Cette astuce peut sauver bien des développeurs, c’est pourquoi je la partage ici. C’est facile, rapide et relativement puissant (pour un morceau de sparadrap).
Plus facile, plus rapide, mais moins puissant que le côté lumineux du test

Contexte

Le projet qui a poussé Sébastien Prunier à utiliser cette technique était du refactoring sur un batch générant des fichiers à partir de la base de données. Il n’existait qu’un seul test unitaire, et plus de 98% du code n’était pas couvert. De plus, l’aspect fonctionnel n’était pas évident à comprendre en l’absence de test unitaire ! Sébastien ne voulait pas se passer de tests de non-régression, mais écrire tous les tests unitaires aurait repoussé la livraison à des délais inacceptables. La technique du Golden Master Testing lui avait été présentée lors d’une conférence de David Gageot, et celle-ci cadrait parfaitement avec sa problématique.

Mise en place

L’idée à la base du Golden Master Testing est d’exécuter son programme sur un large jeu de données. Les résultats sont ensuite stockés, et une fois les modifications de code effectuées, on va refaire l’exécution et vérifier que les données obtenues en sortie sont les mêmes. Voici les étapes à suivre :

  1. Jouer le batch sur la base de test et stocker les résultats. Les fichiers en sortie constituent ce qu’on appelle le Golden Master, ce sera la référence à laquelle on comparera les fichiers produits par le code refactoré.
  2. Copier le code, l’original pourra servir de référence au besoin.
  3. Jouer la copie sur la même base qu’au début et vérifier que les fichiers obtenus sont identiques au Golden Master.
  4. Écrire le test en utilisant un outil d’assertion qui comparera les contenus de fichiers.
  5. Faire ses modifications de code en utilisant le test automatique de comparaison.

Pour l’assertion, vous pouvez utiliser AssertJ :

assertThat(refactoredFile).hasContentEqualTo(masterFile)

Conclusion

Le Golden Master Testing permet de se sortir rapidement de situations problématiques, et cette technique peut aider bien des développeurs dans des cas similaires au contexte évoqué en début d’article. Cependant, on peut remarquer qu’elle ne pourra pas être mise en place (ou bien beaucoup plus difficilement) dans de nombreux cas : si le code ne produit pas une sortie aisément comparable avec une sortie précédente, et si nous avons à effectuer les modifications fonctionnelles qui doivent produire une sortie différente de notre Golden Master.

Tes tests unitaires toujours écrire tu dois

Attention, le Golden Master Testing n’est qu’une astuce pour mettre en place rapidement des tests de non-régression sur du code legacy. Il ne nous dispense en rien de créer des tests unitaires en plus sur les morceaux de code que l’on modifie, pour améliorer au fil de l’eau notre couverture de tests par du code propre.

Crédits images

http://memegenerator.net


Vous avez trouvé cette publication utile? Cliquer sur
Ippon
Ippon est un cabinet de conseil en technologies, créé en 2002 par un sportif de Haut Niveau et un polytechnicien, avec pour ambition de devenir leader sur les solutions Digitales, Cloud et BigData.

Ippon accompagne les entreprises dans le développement et la transformation de leur système d’information avec des applications performantes et des solutions robustes.

Ippon propose une offre de services à 360° pour répondre à l’ensemble des besoins en innovation technologique : Conseil, Design, Développement, Hébergement et Formation.

Nous avons réalisé, en 2017, un chiffre d’affaires de 31 M€ en croissance organique de 30%. Nous sommes aujourd’hui un groupe international riche de plus de 320 consultants répartis en France, aux USA, en Australie et au Maroc.
FRANCE Website LinkedIn