Qu'est-ce que le refactoring des tests et pourquoi est-il nécessaire au référentiel de tests ?

Par :
Bruno Legeard

mar, 02/09/2014 - 15:33

Qu'est-que que le refactoring de tests ?

Le refactoring [1] est une pratique courante du développement logiciel, dont l'usage est devenu systématique avec les pratiques de développement agile. Le refactoring du code [2] consiste à améliorer la structure du programme pour en faciliter la lisibilité, en réduire la complexité et donc finalement pour en accroitre la maintenabilité. Par exemple, le code peut être amélioré en factorisant une partie qui était dupliquée inutilement, ou en définissant des opérations de mise à jour des données, plutôt que d'accéder directement à la base.

Le refactoring du code doit être effectué de façon régulière, par petites touches, comme une « hygiène de base » du développement logiciel. Il s'est impose pour devenir aujourd'hui un véritable standard des bonnes pratiques pour les développeurs.

Mais qu'en est-il du refactoring des tests, et s'agit-il également d'une bonne pratique pour les testeurs ?

des tests plus lisibles, mieux structurés et donc plus facilement maintenables

Les techniques de refactoring des tests ont les mêmes objectifs que dans le contexte du refactoring du code : lisibilité, simplification et amélioration de la maintenance. Il s'agit en particulier,

  • de nommer de façon identique des étapes correspondant aux mêmes actions dans les cas de test,
  • de factoriser sous forme d'un mot d'action plusieurs étapes, que l'on retrouve identique dans plusieurs tests,
  • d'éviter la répétition de séquences identiques, pour n'avoir qu'un point de maintenance,
  • d'introduire des paramètres dans ces mots d'action de façon à les rendre plus générique.

Considérons un référentiel de test pour une application donnée, qui contient de l'ordre de 350 cas de tests. Ces tests ont été développés depuis 2 à 3 ans, par plusieurs personnes.

Au fil du temps, la multiplication de nommages différents pour les mêmes actions (par exemple : pour l'action de se connecter à l'application, il est fréquent de trouver les nommages « connecter vous », « login », « s'identifier » pour désigner exactement la même action de test) et la multiplication des séquences d'étapes dupliquées, ont rendu très difficile toute mise à jour de la suite de test.

A chaque changement dans l'application cela devient de plus en plus compliqué. Une suite de test bien structurée évite ce « piège » et réduit nettement les coûts de maintenance des tests.

Le refactoring des tests doit être réalisé au fil de l'eau

Le refactoring des tests n'est surtout pas à envisager comme une activité « big-bang », car alors ce refactoring n'est jamais réalisé. Pour les équipes de test qui la mettent en œuvre, il s'agit d'une pratique au fil-de-l'eau, c'est-à-dire réalisée par petite touche lors de chaque évolution de la base de test.

Pour l'équipe de test, cette discipline devient rapidement une habitude acquise, comme attacher sa ceinture de sécurité ou se laver les dents matin et soir ; à l'instar du refactoring de code, on peut parler, pour les refactoring des tests, d'une hygiène de base du développement et de la maintenance d'une suite de tests.

Le mot d'action - un principe clé du refactoring des tests

Généralement, un cas de test est défini comme une séquence de pas de test. Chaque pas décrit une action de test à réaliser sur le système, les données du pas de test et les résultats attendus de ce pas de test.

Pour les tests manuels, les pas de tests sont décrits de façon informelle, avec un descriptif de l'étape, des données éventuelles à saisir et des résultats éventuels attendus.

La notion de mot d'action permet d'introduire la brique de base de la structuration des tests :

  • un pas de test peut être défini à partir d'un mot d'action ;
  • un mot d'action peut être utilisé dans autant de pas de test que nécessaire ;
  • un mot d'action peut lui-même être défini à partir d'autres mots d'actions ;
  • un mot d'action peut se situer à plusieurs niveaux allant :
  • de l'action métier de haut niveau (par exemple : "créer une commande")
  • à l'action de test de bas niveau (par exemple : "saisir le champ N° de commande").

-         un mot d'action peut être paramétré (par exemple : "créer une commande" par le paramètre "Type de commande") ce qui permet d'être plus générique.

Les paramètres des mots d'action possèdent une valeur par défaut pour faciliter leur usage.

Les mots d'action sont des briques de base sur lesquels sont construits les cas de test.

La bibliothèque des mots d'action avec leurs paramètres correspond à la bibliothèque des mots clés à automatiser:

Le refactoring des tests : facteur clé pour réussir l'automatisation des tests

Une bonne structuration des tests, et en particulier la factorisation par mots d'action, a été reconnue depuis longtemps comme une pratique essentielle de l'automatisation des tests. Les plateformes d'automatisation de type "keyword- & data-driven testing" s'appuint sur ce concept.

Plutôt que de réaliser des copier-coller dans le code d'automatisation des tests, il s'agit de le structurer par des modules élémentaires (des mots d'action) qui faciliteront la maintenance. Cela conduit à construire des mots d'action plus orientés métier, et permet de séparer la couche logique du test (ce que l'on veut tester) de la couche technique (son implémentation sur l'interface du système) de façon, là encore, à en faciliter la maintenance.

Pour conclure

Le refactoring des tests est une bonne pratique émergente dans l'écriture des suites de test, et doit se penser comme une pratique continue, et doit être appréhendée en quelque sorte une hygiène de base de l'écriture et de la maintenance des tests.

Les plateformes de test supportent parfois la notion de mot d'action (sous forme de mots clés par exemple ou de composants de test), mais on commence également à voir des fonctions de refactoring apparaitre avec des outils tels que Zest (www.zest-testing.com).

Cela facilite leur maintenance, et permet aussi d'accélérer le passage à l'automatisation, pour les tests de non régression par exemple.

 

[1] Nous préférons utiliser le terme anglais de « refactoring » car nous il n'y a pas de traduction établie pour l'instant. Le terme « réingénierie » évoque plutôt l'idée de retro-ingénierie, qui est autre chose.
[2] Voir la page Wikipedia - http://en.wikipedia.org/wiki/Code_refactoring

A propos de l'auteur

Bruno Legeard
Cofondateur et Conseiller Scientifique de Smartesting, Secrétaire du Comité Français des Tests Logiciels

Docteur en Informatique, INSA Lyon, Bruno Legeard anime depuis plus de 10 ans plusieurs projets de recherche dans le domaine du logiciel critique et du test. Il est membre des comités de programme de nombreuses conférences sur le test et intervient dans les principaux événements mondiaux sur le Model Based Testing.