Le test EST la spec ... 🤔

L’idée est à la mode, depuis Agile. Soutenue fréquemment par les meilleurs.

Prenons l’implémentation d’une password policy comme exemple, et voyons de quoi il retourne si l’on accepte que la suite de tests EST la spec.

1️⃣ Pas de test = pas de spec.

Tous les mots de passe sont admis, ou tous interdits. On ne sait pas,... mais on saura quand on aura testé, promis.

2️⃣ Ajouter des tests incrémentalement (p.ex. TDD) c’est changer la spec.

Il n’y a pas une password policy, il y en a autant que d’incréments. Autrement dit, la password policy change au fur et à mesure qu’on la teste.

3️⃣ Les bugs n’existent pas.

Un bug c’est un écart entre la spec et l’implémentation. Si les tests sont la spec, alors aucun bug n’existe quand les tests sont verts. Dites-le donc aux utilisateurs pour voir (« désolé, c’est pas un bug, tous les tests passent »).

👉 Désolé, ça tient pas 🤷‍♂️

La pensée Test = Spec vient du BDD/TDD. Ces techniques bien utiles permettent de découvrir la spec par induction. Quitte à s’arrêter en chemin et de conclure "rien ne sert d’aller plus loin, disons que ma suite de tests est ma spec, jusqu'à preuve du contraire".

🎶 La spec nous échappe. Soit. Elle ne s’exprime jamais autant que quand elle nous rattrape 🎶

Le développement logiciel est affaire de pensée précise. Confondre des concepts logiques est une pente glissante...

Si par exemple vous avez pensé "ben oui" aux points 1️⃣, 2️⃣, ou 3️⃣ vous confondez sans doute la Spec et votre Implémentation.

Rien n’est plus dangereux en vrai.
Relisez tout cela calmement.

#SoftwareEngineering