Une des constantes de notre travail de développeur est de voir sans cesse grossir nos applications lorsque le métier nous demande de rajouter de nouvelles fonctionnalités. Une autre de ces constantes lorsque nous sommes consultants et que nous arrivons sur une nouvelle mission est de voir des applications assez volumineuses qui n’ont pas un niveau de couverture de tests à l’égal de leur « démesure » et de devoir modifier certaines de leurs fonctionnalités. Ces deux constantes (qui ne sont pas les seules) résument assez bien notre lot quotidien. Si dans le premier cas, il nous est assez facile de commencer le développement en partant sur des bonnes pratiques telle que le TDD, dans le second cas sans une bonne couverture de tests, la chose se corse un peu.
J’ai lu il y a peu cet article. Il présentait un framework Ruby de Github utilisé dans le cadre de refactoring de code. Il permet de comparer le résultat de l’exécution directement en production d’un code legacy avec sa version refactorée. En comparant les différentes et nombreuses exécutions du code « ancien » et « nouveau », les développeurs pouvaient combler les différences constatées et relivrer une version du soft dont le nouveau code est encore plus proche de l’ancien. Après plusieurs itérations et une fois le nombre de différences entre les deux codes devenu nul, il est possible de supprimer l’appel de l’ancien code et de le remplacer par le nouveau.
A la fin de la lecture de cet article, j’étais impressionné. Jamais je n’aurai eu l’idée d’insérer dans du code à mettre en production une double exécution (trop intrusif à mon goût). Je trouvais cela génial et je voyais déjà d’autres éléments à rajouter à ce framework. Par ailleurs ce dernier a semble-t-il déjà un pendant java: experiment4j
Et si l’ensemble des tests nous manquant provenait de l’ensemble des exécutions faites sur la production par les utilisateurs. Si nous n’avions qu’à enregistrer les paramètres d’entrée de nos méthodes ainsi que le résultat, de les filtrer pour ensuite générer nos tests unitaires afin d’augmenter notre couverture de tests. Ces derniers ne coûteraient pas très cher en principe (si ce n’est la mise en place des outils adéquats pour les générer) et permettrait de mettre en place un filet de sécurité pour pouvoir refactorer le legacy. Voici comment pourrait naître un nouveau concept, celui de TPP: Tests Provided by Production.
Au delà de leur coût assez faible, ces tests auraient le mérite de correspondre à ce qui est attendu par le métier. En règle général rares sont les documentations fonctionnelles qui soient à jour. De plus, intéresser les fonctionnels sur ce qui a déjà été produit n’est pas forcément chose aisée surtout quand aucune plus-value n’est rajoutée; et quand le métier est riche et complexe, cela est encore plus dur. Par contre, si ce qui tourne en production fonctionne « bien » (c’est à dire correspond parfaitement à ce qui est attendu du métier) alors cette méthodologie aurait le mérite de fournir une couverture de tests convenable.
Maintenant et comme dit plus haut, si l’approche des frameworks cités plus haut est ingénieuse, ils ont aussi un gros défaut à savoir celui d’être très intrusifs. C’est en discutant de ces frameworks et cette idée de TU générés par la production avec un collègue, David CARAMELO, que ce dernier me dit avec de lueurs étoilées dans le regard, qu’il pensait être possible d’être moins intrusif en mettant en place un agent java. Au lieu d’avoir du code déployé en production chargé de récupérer les paramètres d’entrée et le résultat de l’exécution du code legacy, il suffirait d’espionner via l’agent les méthodes dont on souhaite générer les TU. Et comme dit l’expression « Roule ma poule ». En même temps, dire cela est facile, mais la conception de cet outil peut être un peu plus complexe que ce proverbe de trois mots.
L’intérêt d’un tel outil est facilement perceptible, notamment pour ceux qui travaillent sur un code peu documenté fonctionnellement parlant mais qui possède le comportement attendu par le métier. Il est tout à fait possible que prochainement un framework de ce type puisse arriver pour nous simplifier la vie. En tout cas, le concept de TPP est maintenant présent et avec lui peut être un peu l’espoir qu’il permettra d’améliorer petit à petit le code legacy rencontré (une fois un outil présent pour mettre en place ce concept).