Le TDD et les pièges à éviter

• Grosse discussion ce soir avec un ami développeur autour des pratiques TDD. Le constat personnel est que 99% des équipes qui souhaitent adopter la TDD échouent. 
  
  Cela peut nous laisser penser que 99% des développeurs sont mauvais mais je pense que la vérité et toute autre : 
  
  1)     Le refactoring devient vite impossible / L’évolutivité du produit est plus compliquée 
  
  La qualité du code s’améliore de manière itérative par du refactoring. Or quand la couverture des tests est importante, chaque changement structurel du code casse les tests. Au bout d’un moment, les développeurs vont préférer naturellement la facilité : skip.test=true ??. 
  
  Ce qu’il faut retenir : Il ne faut absolument pas tester chaque méthode publique (des implémentations de classe) mais plutôt des comportements/algos. Il ne faut pas tester par mocking les classes avec des dépendances externes. 
  
  Donc TDD = 100% de couverture de tests c’est du bullshit. 
  
  Aucun texte alternatif pour cette image 
  Voici un article intéressant sur le sujet : 
  
  http://blog.stevensanderson.com/2009/11/04/selective-unit-testing-costs-and-benefits/ 
  
  2)     Tester tout devient non productif 
  
    Comme expliqué plus haut il ne faut pas tout tester. Il faut trouver le bon équilibre entre la quantité de tests et la quantité du code critique/important. Sinon on va avoir l’impression de pédaler dans le vide et ne rien livrer pour les clients. 
  
  Si la couverture des tests est une métrique à maximiser (car suivi par le management dans Sonar) les développeurs ont tendance à produire des tests sur du code trivial juste pour maximiser cette métrique. C’est du temps perdu …. 
  
  3)     Le principe “reed - green - factor” est souvent mal compris 
  
  Les devs comprennent qu’il faut : 
  
  Ecrire un test qui échoue ou qui ne compile pas 
  Ecrire une implémentation qui fait passer le test 
  Refactoring …du coup le test echoue à nouveau 
  Réécriture totale du test 

Si on fait de la réécriture totale (pas du refactoring) du test on ne fait pas réellement du TDD mais plutôt du test unitaire. C’est très subtil mais à mon avis très structurant.