« Si une chose peut mal tourner, elle tournera mal ». Tel est la loi de Murphy. Je relisais ce merveilleux livre d’Arthur Bloch intitulé la loi de Murphy et autres raisons pourquoi les choses tournes mal. Après seulement une page, mon esprit divagua sur l’application des corolaires de la loi de Murphy sur le monde du développement. Corolaire #4 : Si vous percevez qu’il y a quatre moyens qu’une procédure aille mal, et que vous corrigez le tout, un cinquième moyen se développera aussitôt. Corolaire #8 : Il est impossible de faire un système à l’épreuve des fous car les fous sont tout simplement géniaux. En embrassant ces deux corollaires, nous avons le fondement du développement par
tests. Test-driven développement (TDD) part du principe que votre système logiciel aura des bugs indépendamment du contrôle de qualité mis en place et que le système crashera. Pour appliquer la méthodologie, on test de manière automatique les fonctionnalités le mieux possible sans aller dans l’excès. Suite à la découverte d’un bug, on écrira un nouveau test. On vérifiera que le bug existe vraiment. On corrigera le bug. On vérifiera que le bug est corrigé et que les tests précédant ne sont pas affectés. Cette méthode ne garantie pas qu’il y aura de nouveaux bug, mais à chaque relâche le système se comportera de mieux en mieux. Peut-être qu’à l’aide de celle-ci, vous pourrez vaincre la loi de Murphy. Mais comme la loi de Commoner sur l’écologie : Rien ne nous quitte jamais.
