Catégories: Bonnes pratiques, Programmation

Une bonne pratique qui est apparue très rapidement dans nos dojos de programmation est de bien nommer les tests. En effet, comme les dojos successifs sont séparés de plusieurs semaines, à chaque fois on redécouvre le code, et quand les tests sont mal nommés, nous sommes obligés de les relire entièrement pour les comprendre. En fait l'un des avantages des dojos est de simuler sur une courte période ce qui se passe dans la vie réelle : quand vous revenez sur votre code plusieurs mois ou années plus tard, vous avez parfois l'impression qu'il a été écrit par quelqu'un d'autre, non ?

Par conséquent les participants des dojos sont tous d'accord sur le fait qu'il faut bien nommer les tests. Rien de très surprenant, me direz-vous, c'est une bonne pratique bien connue. Par exemple dans Clean Code, le livre de l'oncle Bob dont j'ai parlé dans un billet précédent, il y a plusieurs points qui parlent du nommage correct. Le deuxième chapitre, écrit par Tim Ottinger, est même entièrement consacré à la question du nommage. Plus loin dans le livre, le chapitre "Tests propres" mentionne notamment :

» Lire la suite!

Discussion intéressante ce 11 février lors du troisième dojo du Club Agile Rhône Alpes : nous nous apprêtions à introduire des commentaires dans notre code de test quand un participant a fait remarquer qu'il préférerait voir ces mêmes informations sur la trace de sortie, afin de rendre les résultats de tests unitaires plus lisibles. Plusieurs solutions ont été discutées, et nous avons retenu la plus simple, à savoir inclure l'information en question directement dans le nom de la méthode de test.

Cela m'a fait prendre conscience à quel point un commentaire représente une information "morte" par rapport au code, "vivant" car exécuté. Et cela m'a remis en mémoire un chapitre du livre Clean Code: A Handbook of Agile Software Craftsmanship par Robert C. Martin (et d'autres auteurs comme Michael Feathers qui a écrit le chapitre "Error Handling"). En effet ce nouveau manuel de référence consacre pas moins de 21 pages à la question des commentaires dans le code (presqu'autant qu'au TDD !).

Comment bien commenter son code est un sujet assez sensible, sur lequel les développeurs et leurs managers sont enclins à s'enflammer facilement ! Personnellement je converge petit à petit vers l'opinion qu'il faut éviter les commentaires autant que possible, et Robert C. Martin explique cela très bien, aussi je traduis ci-dessous quelques extraits :

» Lire la suite!