Qu’est ce que le code legacy?

m1i5zevLe code « Legacy » peut être défini comme l’ensemble du code qui n’est pas testé unitairement. Ce code est difficilement réutilisable car non couvert par des tests automatisés, couvrant la non-régression. Comment en venir à bout? Et d’ailleurs, doit on en venir à bout?

Dans mon cas, celui d’un éditeur logiciel dont les produits ont des bases de code plus ou moins âgées, il sera plutôt aisé de trancher.

Et la réponse est: pas forcément! Il ne faut pas forcément couvrir tout le code legacy. Le code qui ne bouge pas, pas de raison d’y toucher, à moins d’avoir des jours hommes à brûler… A l’inverse, le code sur lequel on revient, ou qui est impacté par une modification/ajout de code, devra être testé au préalable. Pas de modification, ou d’impact d’un bout de code legacy, sans avoir implémenté les tests, avec la couverture suffisante. C’est une règle d’or pour quiconque souhaite se prémunir contre une régression fonctionnelle… ou technique.

Dès lors, comment être certain d’avoir une certaine exhaustivité dans la couverture du legacy? Mettons de côté les cas faciles (exemple, il y a une « spéc » qui décrit ce que ça doit faire). Dans les cas pourris difficiles, donc, il va falloir comprendre ce que fait le code avant de pouvoir écrire le moindre de test…

Mon conseil est de d’abord établir le périmètre le plus précis possible des méthodes appelant le code à tester (garder en tête que des appelants ne seront sans doute pas connus…).  L’idée est de comprendre les différents contextes d’appels, d’identifier les paramètres d’appels afin de dresser une liste des cas d’utilisation du code à tester. Ensuite, j’aime imaginer les cas limites (cette étape peut être faite en premier, si vous pensez être influencé par l’établissement du périmètre). il va falloir imaginer les cas limites, fonctionnels des appelants que vous avez listésMais aussi les cas limites techniques… et peut être découvrir que l’implémentation ne les gère pas encore (Soit! Nous le ferons alors en TDD).

Une fois cette liste assez exhaustive réalisée:

  1. je teste mon périmètre établi => je couvre la non-régression
  2. je teste mes cas limites => je couvre la non-régression, et l’évolution à venir
  3. pour l’évolution à venir,  et donc les tests la couvrant, je conseille le TDD si possible 😉

Oui mais! le legacy est tellement mal écrit qu’il n’est pas testable (référence interne à des statiques par exemple). Aïe, cas vraiment… difficile, mais somme toute, plutôt commun. Dans ce cas, une solution peut être de créer des fakes (stubs or mocks). L’article en lien évoquait la possibilité de le faire avec le framework Moles, projet de recherche. Visual Studio 2012, il me semble que c’est avec cette version, a apporté un nouveau framework, Microsoft Fakes, à cet effet.

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s