Les bonnes habitudes du développement piloté par les tests

Pour un sénior, on doit obéir à trois cycles durant la phase de développement

Robert C. Martin alias Uncle Bob revient avec un nouveau billet dans sur son blog « Clean Code », avec pour sujet : le Test Driven Development (TDD).
Cette méthode de développement axée sur l’écriture des tests avant le code obéit à trois lois :

• première loi : toujours écrire le test avant d’écrire le code de la fonction testée ;
• deuxième loi : définir dans le test les comportements et les résultats attendus de la fonction testée ;
• troisième loi : écrire dans la méthode testée le code suffisant afin que le passage du test soit un succès.

Le développeur devrait garder ces trois lois à l’esprit pour chaque ligne de code qu’il écrit. Mais selon les explications de Robert Martin, un codeur TDD respecte durant la phase de développement trois autres cycles :

1. Le micro-cycle (Red-Green-Refactor) : répété chaque minute, il se base sur l'idée que « nos esprits limités ne sont pas en mesure de poursuivre les deux objectifs simultanés de tous les systèmes de logiciels, dont un comportement correct et une structure correcte. Donc, le cycle RGR met d'abord l'accent sur le travail de faire correctement le logiciel, avant de se concentrer la structure du logiciel ».
   Les règles de ce cycle sont simples :
   
   • créer une unité de tests ;
   • écrire le code de production qui permet de passer ce test avec succès ;
   • nettoyer le gâchis que vous venez de faire.
   
   
2. Le milli-cycle (Specific/Generic) : répété chaque 10 minutes, se base sur le principe suivant :
   
   • plus les tests sont spécifiques, plus le code devient générique.
   « On dit souvent que la structure à grain fin des trois lois et le cycle Red-Green-Refactor mènent à des optimisations locales ». Ces optimisations locales font parfois que le développeur se trouve « bloqué » à cause du manque de généralisation. Si cela arrive, « la seule solution est de revenir en arrière à travers les tests précédents, les supprimer, jusqu'à atteindre un test à partir duquel il peut prendre un autre chemin ».
3. Le cycle primaire : répété chaque heure, son objectif est de faire en sorte que les autres cycles nous conduisent bel et bien vers une architecture claire.
   Ainsi, chaque heure, le développeur doit « s’arrêter pour regarder l'ensemble du système » afin de détecter « les limites architecturales » de son logiciel et voir si sa solution suit une logique bien définie.

Source : Clean Code Blog

Et vous ?

Êtes-vous d’accord avec l’avis de Robert Martin ?

Utilisez-vous (ou utiliserez-vous) le Test Driven Development ?