100 % tested – comment jardiner les tests automatiques

Dernièrement je suis intervenu dans une équipe qui débutait dans la pratique de Scrum et n’avait pas la culture « tests automatiques ». La pratique de Scrum et notamment la perte de propriété du code est périlleuse sans une forte utilisation de tests automatiques. En effet quand on est tout seul responsable de son code, on se passe généralement de tests auto vu qu’on se porte garant à la fois des non régressions et de la cohérence du code. Dans une équipe conséquente, où plusieurs personnes peuvent intervenir sur les mêmes parties du code on perd cette centralisation.

Voici la petite recette que j’ai utilisée pour jardiner la culture test :

  • Commencer par tester tout le code qu’on produit soi-même (balayer devant sa porte… 🙂 )
  • A chaque fois qu’un développeur fait passer au rouge, ne pas le laisser tout seul, l’aider à tout remettre au vert, et identifier le comportement mis en défaut.
  • Pair programmer pour montrer comment on peut faire des tests petits et simples
  • Pair programmer pour montrer comment on peut appréhender le TDD
  • Être un peu « intégriste » : un bug trouvé est une fonctionnalité non testée
  • Utiliser des outils pour afficher la couverture de code (voir des zones à 100% est  très motivant)

Par l’exemple, en refusant de fournir du code non testé, l’équipe s’est peu à peu rendue compte des avantages des tests automatiques. Au bout de 4 mois  de projet j’ai commencé à entendre des phrases du type : « Si les tests ne passent pas c’est que j’ai changé du comportement… », « J’ai encore du mal avec le test before, mais je comprend l’utilité du test auto », « J’ai été convaincu de l’utilité du test unitaire, c’est indispensable pour pouvoir faire des évolutions sereinement », « Quand je code un comportement, je suis serein lorsque d’autres personnes développent sur le même code car tout changement est signalé ».

Les tests auto sont une ceinture de sécurité et quand on n’en a plus on se sent un peu nu 🙂