Pourquoi Écrire des Vérifications Automatisées ?
[TDD]
Pourquoi écrire des vérifications automatisées ?
Parce que votre modèle du comportement détaillé du système tel que vous le programmez comporte du bruit, et que vous voulez corriger ce bruit. La plupart de ces vérifications s’exécuteront sans échec : vous les programmez en même temps que le code qu’elles vérifient. Un peu comme des garde-fous qu’on a posé là sur cette passerelle, alors même qu’aucun accident n’est jamais arrivé.
Les gens qui trouvent TDD inutile font souvent cette objection : un test qui passe d’emblée c’est une complète perte de temps. J’en connais certains qui m’ont dit : lorsque je code, je ne fais pas d’erreur (et je les crois volontiers, d’autant que je n’ai pas les moyens de m’offrir leurs services). En d’autres mots, ils disent : il y a très peu de bruit dans ma conception. Ou en d’autres mots : pourquoi mettre des gardes fous là où il y a si peu d’accidents ?
Objection 1 : Ce serait une perte de temps, si on gravait le code dans le marbre. Mais puisqu’on inscrit le code dans un substrat encore plus volatile que la glaise ou la poussière, et que ce code devra changer puisque l’on ne saurait écrire et faire passer d’un coup tout le code d’un système par une seule vérification, il nous faut des gardes-fous, des régulateurs qui contrôlent et éliminent les bruits présents dans le flot de conception.
— …Donc, lorsque le remboursement porte sur 2 items, il faut cumuler les montants HT… Et le test passe. Ça marche !
— Repasse tous les tests, stp ?
— Ok… Aïe !
— Celui-là échoue. On peut le regarder ?
— Ok…
— …
— Je vois : parce que le montant est négatif dans ce cas. J’ai parlé trop vite.
Ici, le modèle du comportement du système évolue, à travers un flot de conception du binôme vers le produit. Dans ce flot, les bruits de conception, comportements indésirables du système, sont filtrés par (entre autres) une batterie de vérifications automatisées. Un des tests ne passe pas : la barre est rouge, le bruit est signalé, puis rapidement corrigé par les développeurs.
On peut dire que le système : DÉV ↔ CONCEPTION ↔ PRODUIT comporte un sous-sytème de correction du bruit, qui est un régulateur. Sans ce régulateur, le flot de conception est intégré “brut” dans le système, et le “bruit” finit par rendre le système impropre à l’usage qui lui est destiné.
Ce qui dans TDD est intriguant — et pour certains professionnels, contre-productif — c’est qu’on fait grandir et qu’on ajuste ce sous-système de correction à mesure que le produit grandit, c’est à dire au fur et à mesure que s’élève le nombre de ses comportements possibles, de manière à toujours réguler le niveau de bruit. Dans d’autres démarches, on recherche activement le bruit une fois la conception/construction du produit à peu près “finie”. (Dans d’autres encore, on agit uniquement lorsque le bruit se fait entendre au standard du help-desk.)
Objection 2 : Dans la pratique, en fait, un test ne passe jamais d’emblée.
Hein ? Stay Tuned
