TDD
Par Jean-Baptiste le mercredi 6 février 2008, 11:51 - Code - Lien permanent
Au détour d'un coin de web, je suis tombé sur un article intéressant de Patrick Smacchia
Cet article m'a paru intéressant car c'est un des premiers que je lis sur le sujet des tests. Oui, j'avoue, je pratique TDD au quotidien depuis plusieurs mois sans jamais avoir vraiment rien lu sur le sujet. J'étais d'ailleurs assez convaincu du fait que le test driven development ne pouvait pas être défendu oralement, mais qu'il fallait dans la grande majorité des cas pratiquer un bon pair programming avec un senior pour en apercevoir la richesse et l'intérêt.
Je trouve pourtant que cet article s'en sort plutôt très bien, ce qui est déjà un bel exploit.
Ceci dit, la partie qui m'intéresse le plus est celle sur l'adoption et le coût des test unitaires. Je me suis rappelé une conversation que j'ai eu il y a quelques temps, et dont Fabien a fait un bon résumé
Prenons les points de Smacchia un à un et parlons en:
Ils(les développeurs) peuvent ressentir le développement et la maintenance des tests comme autant de temps non consacré à l’application elle même.
Personnellement, je n'ai jamais ressenti de sentiment tant justement j'ai eu l'impression de me consacrer ENFIN à l'application et pas à des détails techniques périphériques (comme comment s'accrocher à IE pour debuguer, ce genre de choses). J'avais enfin un lien direct et sans intermédiaires avec le bout de code que j'étais entrain d'écrire.
En outre, les tests unitaires engendrent de la frustration puisqu’ils sont par définition un moule auquel doit se conformer en permanence le code. En supposant que les tests soient imposés au développeur, ils limitent de facto sa marge de manoeuvre.
Retirer aux développeurs la responsabilité d'écrire les tests me semble assez désastreux. C'est encore plus industrialiser le développement l'informatique en transformant le développeur en simple ouvrier écervelé. J'ai tendance à dire que c'est même un détournement abjecte d'une bonne pratique en credo tayloriste.
Si les développeurs écrivent eux-même leur test, alors je ne pense pas que ce sentiment de frustration vis à vis d'un moule va se développer. Smacchia le dit lui-même dans l'article, écrire des tests nous force à mieux coder et mieux designer. Qui peut se plaindre d'écrire du code plus élégant? Enfin du moins, c'est l'impression que je ressens après plusieurs moi de TDD intensif, mais je pense que s'il en parle, c'est qu'il a du rencontrer le problème.
Enfin, il faut bien admettre que lors de la rédaction d’un test unitaire, on a tendance a être convaincu que le code testé ne boguera jamais. [...]
C'est précisément pour ce point que je pense que TDD ne peut pas être mis en place sans du pair programming pendant un certain temps avec quelqu'un de plus expérimenté avec cette approche. Oui c'est vrai, parfois on a l'impression de perdre du temps en écrivant un test inutile, car on ne voit pas comment il pourrait passer au rouge. Seul la pratique, et la confrontation avec un cas ou ce test inutile à permis d'économiser des heures de debugging quand il est passé au rouge permet de voir toute la puissance de l'approche.
je ne vais pas commenter la partie sur la mise en place des tests sur un projet déjà existant, car Smacchia a tout simplement bien mieux expliqué le problème que je ne pourrai jamais le faire
Je trouve pourtant que cet article s'en sort plutôt très bien, ce qui est déjà un bel exploit.
Ceci dit, la partie qui m'intéresse le plus est celle sur l'adoption et le coût des test unitaires. Je me suis rappelé une conversation que j'ai eu il y a quelques temps, et dont Fabien a fait un bon résumé
Prenons les points de Smacchia un à un et parlons en:
Ils(les développeurs) peuvent ressentir le développement et la maintenance des tests comme autant de temps non consacré à l’application elle même.
Personnellement, je n'ai jamais ressenti de sentiment tant justement j'ai eu l'impression de me consacrer ENFIN à l'application et pas à des détails techniques périphériques (comme comment s'accrocher à IE pour debuguer, ce genre de choses). J'avais enfin un lien direct et sans intermédiaires avec le bout de code que j'étais entrain d'écrire.
En outre, les tests unitaires engendrent de la frustration puisqu’ils sont par définition un moule auquel doit se conformer en permanence le code. En supposant que les tests soient imposés au développeur, ils limitent de facto sa marge de manoeuvre.
Retirer aux développeurs la responsabilité d'écrire les tests me semble assez désastreux. C'est encore plus industrialiser le développement l'informatique en transformant le développeur en simple ouvrier écervelé. J'ai tendance à dire que c'est même un détournement abjecte d'une bonne pratique en credo tayloriste.
Si les développeurs écrivent eux-même leur test, alors je ne pense pas que ce sentiment de frustration vis à vis d'un moule va se développer. Smacchia le dit lui-même dans l'article, écrire des tests nous force à mieux coder et mieux designer. Qui peut se plaindre d'écrire du code plus élégant? Enfin du moins, c'est l'impression que je ressens après plusieurs moi de TDD intensif, mais je pense que s'il en parle, c'est qu'il a du rencontrer le problème.
Enfin, il faut bien admettre que lors de la rédaction d’un test unitaire, on a tendance a être convaincu que le code testé ne boguera jamais. [...]
C'est précisément pour ce point que je pense que TDD ne peut pas être mis en place sans du pair programming pendant un certain temps avec quelqu'un de plus expérimenté avec cette approche. Oui c'est vrai, parfois on a l'impression de perdre du temps en écrivant un test inutile, car on ne voit pas comment il pourrait passer au rouge. Seul la pratique, et la confrontation avec un cas ou ce test inutile à permis d'économiser des heures de debugging quand il est passé au rouge permet de voir toute la puissance de l'approche.
je ne vais pas commenter la partie sur la mise en place des tests sur un projet déjà existant, car Smacchia a tout simplement bien mieux expliqué le problème que je ne pourrai jamais le faire
