Mon premier dojo sur le Test Driven Development

J'ai lu récemment dans cet article d'Arsene Newman que l’ "une des conséquences de la mauvaise interprétation/application des concepts agiles est la désignation de chefs de projet non sensibles à l’aspect technique du développement logiciel". J’en suis bien consciente, et moi qui n’ai jamais écrit une seule ligne de code, j’essaye de comprendre tout ce que je peux de la logique et des contraintes de travail de mes collègues. Voilà pourquoi je me suis invitée à un dojo sur le test driven development. Je souhaite vous livrer ce que j’ai appris :

QU’EST-CE QUE LE DOJO ?

Premier apprentissage de la séance : qu’est-ce qu’un dojo ?
En arts martiaux c’est le lieu d’enseignements. En japonnais ça veut dire “le lieu où l’on étudie/ cherche la voie”..
Sur notre plateau, il s’agit d’une séance de 3 heures le vendredi après-midi pendant laquelle tous les développeurs peuvent participer et s’améliorer ensemble sur un sujet donné. Dans notre cas, le développement piloté par les tests.

Notre animateur démarre par un sondage reprenant plusieurs questions de type “qui écrit des tests automatisés, qui fait du TDD…”. Cela permet de créer le dialogue. Puis il continue avec un peu de théorie sur le TDD pour que chacun ait le même vocabulaire et les mêmes concepts en tête.

Très rapidement, l’animateur énonce l’exercice : développer une application pour calculer le score d’une partie de bowling. Il y a un ordinateur portable à disposition. Par paire, une personne développe et une personne la guide. Et suivant un timing donné on fait tourner les équipes.

Bien sûr, il n’y a pas que les personnes devant le poste qui s’expriment. Tout le monde a le droit de donner son avis, d’aider ou de redemander des précisions sur la méthode.
A la fin, on fait une rétrospective où chacun s’exprime sur ce qu’il a pensé de l’atelier et sur les pistes d’amélioration. Notre animateur en tient compte pour la prochaine séance qui reprendra le même format.

LES 4 ÉTAPES DU TDD

Le TDD est une pratique que l’on systématise sur notre plateau de développement en méthode agile.
Pour plein de raisons. Dans cette présentation de l'agile tour Marseille 2012, l'auteur Thierry Vallée explique simplement que les tests permettent de s'assurer que le produit fonctionne et d'éviter les régressions lors de ses évolutions.

Le mode de travail est le suivant :
1. J’identifie la fonctionnalité
2. J’écris un premier test ou code de test (on commence par le test le plus simple possible) puis je lance le test pour qu’il échoue.
3. J’écris le code de production. Je lance le test. Je réajuste le code de production jusqu’à ce que le test passe (un test peut être en erreur ou remonter un résultat faux)
4. Je refactorise (pour résumer très brièvement, j’améliore) le code de production si besoin. Je relance le test.

Puis j’écris d’autres tests selon les mêmes 4 étapes jusqu’au moment où je couvre les cas des plus simples aux plus complexes.

LES BONS MOMENTS POUR FAIRE UN COMMIT

Il est important de sauvegarder son travail pour éviter des retours en arrière douloureux. Pour cela, l’équipe utilise un logiciel de gestion de versions et fait des commit. Il s’agit d’une façon de valider son code, soit d’'envoyer ses modifications locales vers le référentiel central utilisé par l’ensemble de l’équipe projet.
Pendant les différentes étapes du TDD, il est pertinent d’effectuer un commit entre les étapes 2 et 3 et 3 et 4. Si le refactoring du code fait passer les tests en échec, une des solutions peut être de revenir en arrière.

UN CODE COMMENTÉ N’EST PAS FORCÉMENT UN CODE DE QUALITÉ

J’ai souvent entendu ou lu qu’un des critères qui permet de mesurer la qualité d’un code est la présence de commentaires. Et bien ce dojo m’a permis de comprendre le contraire. Le code devrait être suffisamment clair pour ne pas avoir besoin d’être commenté. “Comments are always failures” d’après Robert C Martin dans son ouvrage “Clean Code: A Handbook of Agile Software Craftsmanship.”

NE JETEZ PAS VOS TESTS !

Si jamais l’équipe juge qu’il est nécessaire de refaire entièrement la fonctionnalité, il est pertinent de conserver le code de test. Il permettra toujours de valider les attendus métier si ceux-là n’ont pas changé.
J’ai donc retenu cette expression : “il y a plus de valeur dans les tests que dans la fonctionnalité”.

J’ai adoré ce format de travail. Toute l’équipe était détendue, motivée, participative.
Cela m’a permis d’intégrer les étapes par lesquelles doivent passer les développeurs lorsqu’il faut retoucher une fonction et le besoin de sensibiliser les Product Owner à cette démarche. Car la progression de l’équipe ne doit pas se faire au détriment de la qualité du produit développé.
Le prochain dojo est dans deux semaines. Mon équipe compte bien me faire coder… Attention les yeux ! Je vous promets un article pour vous raconter.