La montée en compétence dans les équipes qu’on accompagne est essentielle!
Le manifeste agile nous enseigne que :
“Une attention continue à l’excellence technique et à une bonne conception renforce l’Agilité.”
“La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.”
“Les meilleures architectures, spécifications et conceptions émergent d’équipes autoorganisées.”
Animer un Kata TDD en entreprise est une excellente occasion d’illustrer ces 3 principes. J’ai donc préparé le Kata String Calculator que je n’ai encore jamais animé. Pour corser l’exercice les équipes sont réparties sur 3 sites : Toulouse, Bordeaux et Nantes et certains seront évidement en télétravail, j’ai donc prévu une salle équipée de Visio et prévu quelques points de resynchro pendant l’atelier tous les 15 minutes.
D’autre part, j’essaie toujours de profiter de l’occasion d’un Kata de code pour le faire en pair programming et en associant un développeur à non développeur (par exemple un PO, un Chef de Projet, un intégrateur ou même un Managers). Peu importe, le binôme en fait, ce qui importe c’est aussi de développer la collaboration, de créer du lien et de croiser les expériences.
Aux Origine du TDD (Test Driven Development)
Le TDD est inventé par Kent Back et formalisé dans son livre « eXtreme Programing Explained» paru en 1999.
Dans son livre il explique toute la démarche d’ingénierie de développement et les pratiques associées. C’est une démarche de conception (design) du code plutôt qu’un moyen d’écrire des tests unitaires. Le TDD est un mini cycle de développement constitué de 3 phases permettant un développement par toutes petites itérations.
Le TDD apporte plusieurs avantages à la pratique du développement :
•Le code est souvent plus simple que lorsqu’il est réalisé par une autre démarche car il répond strictement aux exigences, ni plus, ni moins
•Le code est fortement couverts par les tests de par sa construction. Il est donc plus robuste.
Ce n’est pas une recette magique, le TDD est facile à comprendre en 5 minutes, mais nécessite un déclic de la personne pour passer à la mise en pratique. Il faut donc s’entrainer régulièrement avant de passer la mise en œuvre quotidienne sur du code de production. C’est un peu comme si votre cerveau se mettait à raisonner à l’envers (ou plutôt à l’endroit!)
Le TDD ne coûte pas plus cher, même si on pourrait croire qu’écrire plus de code (de test) est un processus nécessitant plus de temps. En réalité, on écrit moins de code de production et les tests écrits en TDD nous prémunissent de beaucoup de régressions et de moins d’activité de debug du code lorsque l’on trouve une erreur/anomalie. Le code écrit en TDD est aussi plus maintenable, et les régressions sont identifiées très rapidement (quelques millisecondes).
Les lois de l’écriture du code en TDD
| Loi no 1 | Écrivez un test qui échoue avant d’écrire le code de production correspondant. |
| Loi no 2 | Écrivez une seule assertion à la fois, qui fait échouer le test ou qui échoue à la compilation. |
| Loi no 3 | Écrivez le minimum de code de production pour que l’assertion du test actuellement en échec soit satisfaite. |
Déroulé et animation du Kata String Calculator :
•Kata incrémental pour simuler une situation métier réelle.
•Suivez les étapes dans l’ordre mais ne lisez pas les étapes suivantes avant d’avoir passé étape en cours!
•On fait un petit point tous les ¼ d’heure sur l’audio Teams
Step 1 :
Créez un « calculateur de String » à partir d’une méthode ayant la signature suivantes :
int add (String numbers)
Cette méthode peut prendre jusqu’à 2 nombres, séparés par une virgule, et renverra leur somme.
Step 2 :
Permettre à la méthode “add(String )” d’ajouter une quantité inconnu de nombres
Step 3 :
Permettre à la méthode Add de gérer les nouvelles lignes entre les nombre au lieu des virgules :
•Cette entrée est OK : « 1\n2,3 » résultat attendu : 6
•Cette entrée est KO : « 1,\n2»
Step 4 :
Permettre l’usage de différents délimiteurs : //[delimiter]\n[numbers]
Ex : « //;\n3;1;2 » résultat attendu : 6
«//|\n1|3|2 » résultat attendu : 6
La première ligne est optionnelle. Les scénarios précédents doivent toujours fonctionner.
Step 5 :
L’appel à la méthode Add avec des nombres négatifs doit renvoyer une exception « négatifs non supportés » ainsi que le nombre négatif qui a été passé.
Si plusieurs valeurs sont négatifs , ils doivent tous être renvoyés
Step 6 :
Les nombres supérieurs à 1000 doivent être ignorés.
Ajouter 1001 + 2 = 2
Step 7 :
Les délimiteurs peuvent contenir plusieurs caractères avec le format suivant : //[delimiteur]\n par exemple :
«//[sep]\n2sep3sep1 » résultat attendu : 6
Step 8 :
Permettre l’usage de plusieurs délimiteurs : //[delimiteur1] [delimiteur2]\n par exemple :
« //[%][*]\n2%3*1 » résultat attendu : 6
Step 9 :
Assurez vous de pouvoir gérer plusieurs délimiteurs avec des longueurs de plus de 1 caractère
Les retours sur l’atelier :
Le temps était un peu court, il vaudrait mieux prévoir 1h30 plutôt qu’1h.
Il est important de prendre du temps pour le débriefe en fin de session pour partager les différentes solutions, chacun ayant produit une implémentation différente des autres.
Le nommage des tests est important, il permet de bien cibler quelle exigence fonctionnelle a subit une régression.
Insister sur la partie “refactoring” du code pour s’assurer du bon nommage des variables, des classes, des méthodes.
La prochaine fois, j’insisterai en amont sur le besoin de disposer d’un projet “prêt” avec les tests unitaires qui fonctionnent. Un groupe a passé la moitié du temps à modifier le pom.xml pour un problème de dépendance vers la librairie des tests unitaires.
Il est important de rester disponible pour chaque groupe afin de clarifier les exigences, qui même si elles sont claires nécessitent toujours des explications orales afin d’éviter de mauvaises interprétations.
ROTI de fin de session :
6 votes à 5 -1 vote à 4
Le ROTI est défini comme ” Retrun On Time Invested”, soit la valeur reçue lors de l’atelier par rapport au temps investi. Une note de 1 signifie que la personne a perdu tout son temps rien avoir appris, tandis qu’une note de 5 signifie que la personne a reçue beaucoup de valeur par rapport au temps investi, et qu’il aurait pu investir encore plus de temps lors de l’atelier.
0 Comments