Nouveaux Plateaux 🌄

J’ai utilisé TDD pour la 1ère fois en 2001, sur un projet en crise. 🤸

Le chef de projet, un consultant indépendant dont le contrat avait pris fin à l’avant-veille de la recette, avait fait un fait un bon travail de coordination, de négociation (c’était un projet réalisé au forfait) et de reporting.

Il s’agissait de la “refonte iso-fonctionnelle” d’une application de gestion, dont le code FoxPro devait être converti en Delphi. Aucun projet dit de “refonte iso-fonctionnelle” ne tient réellement debout, mais celui-ci était particulièrement acrobatique :

🌞🌚 Windows et Dos, c’est le jour et la nuit
😛 volume de la documentation fonctionnelle : ∅
😨 pas de phase de rétro-analyse, ni de spécification

Dixit le client 6 mois plus tôt : pourquoi spécifier, quand on dispose du code ?

Il avait ajouté : en fait on va même la réécrire ISO-bug.😉

C’est à dire : mot pour mot, feature pour feature, au bug près.

Une prédiction pour le moins optimiste. La recette dura 12 semaines (au lieu des 2 prévues dans le “Plan d’Assurance Qualité” du projet) durant lesquelles le Maître d’Ouvrage identifia environ 450 anomalies.

Bien sûr, beaucoup de défauts prenaient leur source dans l’absence de spécification des fonctionnalités concernées, et ma société ne manquait pas de le souligner en comité de projet.

🤺 Pendant que les commerciaux croisaient le fer à propos des pénalités de retard, les développeurs luttaient avec le monstre qu’ils avaient créé. 🤺

À mon arrivée, je leur demandai :

— Vous faites des tests unitaires ?
— Jamais entendu parler. C’est quoi ?

Ensuite l’état de l’art évolua :

➕ débogage en binômes
➕ assertions dans le code pour valider des hypothèses de débogage
➖ fin des system.print dans le code
➕ isolement des assertions dans leur propre modules a.k.a “suites de tests”
➕ refactoring du code une fois celui-ci couvert
➕ réécriture de certains modules en TDD le cas échéant
➕ Maître d’Ouvrage présent dans l’espace de travail 3 jours sur 5
➖ fin du remplissage des PV de tests unitaires

Ce dernier point mérite une explication. La méthodologie des forfaits incluait la production de nombreux documents, dont un formulaire papier sur lequel on devait consigner tous nos TUs:

nom du TU | date de passage du TU | résultat (OK/KO) | signature du développeur ✍︎

Un jour le responsable de la Direction Qualité (la même DQ qui avait émis le fameux Guide des Projets en C), passe inspecter notre “qualité structurelle”.

— Je peux voir les PVs de tests unitaires signés ?

Je lui montrai notre suite de tests dUnit. Un clic et la barre verte dévalait 150 tests en 5 secondes. Je lui expliquai en quoi ça consistait.

— OK. Mais je vois pas vos feuilles de TU signées.
— Si on imprime une copie de cet écran, ça passe ?
— Bah non.

Signe que votre état de l’art évolue vers un nouveau plateau : certains de ses procédés deviennent obsolètes.

publié sur LinkedIn le 24/03/2023