TDD ne concerne pas que le test !!!

((/dotclear/public/programmation.gif|Programmation|L|Programmation, aoû 2009))J’ai traduit un billet intéressant de Alberto Gutierrez : ++[« TDD is not about testing!!! »|http://www.makinggoodsoftware.com/2009/11/21/tdd-is-not-about-testing/|en]++.%%% %%% > Beaucoup de gens confondent « les méthodologies de tests au plus tôt » avec le TDD. Il est très fréquent d’entendre des commentaires du genre « TDD c’est juste l’écriture de vos tests en premier », ce qui est complètement faux. Ce type d’affirmation ne décrit pas du tout le TDD mais parle en fait du développement des tests en premier.%%% > %%% > La principale raison de cette confusion entre TDD et le développement des tests en premier vient de son propre nom : « Test-Driven Development ». Si quelqu’un, qui ne sait pas ce qu’est TDD, doit deviner ce qu’est TDD à partir de son nom, il devinera probablement que c’est juste une méthodologie de tests au plus tôt. Mais ce n’est pas le cas !%%% > %%% > TDD, inventé par Kent Beck (qui a aussi inventé l’eXtreme Programming et Junit), va au-delà. Au cœur de TDD, il y a un processus à suivre, ce qui le rend déjà différent d’une simple approche de test en premier.%%% > %%% > ((/dotclear/public/traductions/Test-driven_development.PNG|TDD||TDD))%%% > Source : ++[Wikipédia|http://en.wikipedia.org/wiki/Test-driven_development|en]++%%% > %%% > Ce processus est également connu sous le forme rouge (faire échouer votre test), vert (faire réussir votre test) et remaniement. On pourrait considérer cela comme une petite différence avec une approche test en premier, mais combiné avec certaines pratiques d’ingénierie agile et autres philosophies de développement, TDD devient très différent de toute approche test en premier et met en réalité l’accent sur la conception.%%% > %%% > TDD est une pratique de conception et est plus lié à la conception qu’aux tests. TDD –est inutile– –  »texte revu par l’auteur suite aux commentaires sur son post d’origine » – perd beaucoup de son potentiel s’il n’est pas combiné avec d’autres pratiques d’ingénierie agile, comme la programmation en binôme, ou des philosophies agiles comme YAGNI et ++[KISS|/dotclear/index.php?post/2009/11/03/Les-7-caracteristiques-d-un-code-simple-KISS|fr]++. En TDD, avoir un grand nombre de tests est un effet secondaire sympa, et non uniquement son objectif.%%% > %%% > Pour savoir si vous faites correctement du TDD, regardez votre code, du code TDD doit paraître simple et lean, TDD génère généralement plus de code pour tester que de code pour produire, et vous devriez sentir que cela vous aide à concevoir votre code.%%% > %%% > Donc, la prochaine fois que vous dites que vous faites du TDD, assurez-vous que vous ne voulez pas plutôt dire que vous faites du développement de tests en premier.%%%

Une réflexion au sujet de « TDD ne concerne pas que le test !!! »

  1. Développement dirigé par les tests. Je trouve le nom plutôt efficace pour décrire la notion. Je me demande comment il peut y avoir confusion. Par ailleurs, serait-il possible de trouver une appellation plus simple? J’en doute.

    « TDD est inutile s’il n’est pas combiné avec d’autres pratiques d’ingénierie agile, comme la programmation en binôme, ou des philosophies agiles comme YAGNI et KISS. »

    Aie, j’en renverse mon bol de céréales. Je fais du TDD seul comme en binôme et j’en tire de nombreux avantages (conception simple, documentation de code, couverture bonne et pertinente). Par ailleurs, je me demande comment il serait possible de dissocier TDD du YAGNI si l’on suit la philosophie sous-jacente résumée par les règles de l’Oncle Bob.

    « En TDD, avoir un grand nombre de tests est un effet secondaire sympa »
    Ah oui sympa l’effet secondaire. En la présence de tests je peux faire du refactoring mais bon ce ne doit être qu’une incidence…

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *