Voir la source de TDD ne concerne pas que le test !!!

[[Category: Portail Equipe de développement]]
[[Category: Tests]]
[[Category: Alberto Gutierrez]]
Auteur : Alberto Gutierrez<br/>
Source : [http://www.makinggoodsoftware.com/2009/11/21/tdd-is-not-about-testing/ TDD is not about testing]<br/>
Date : 21/11/2009<br/>
----
Traducteur : Fabrice Aimetti<br/>
Date : 28/11/2009<br/>
----
Traduction:<br/>
<br/>
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.<br/>
<br/>
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 !<br/>
<br/>
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.<br/>
<br/>
[[Fichier:Test-driven development.PNG]]<br/>
Source : [http://en.wikipedia.org/wiki/Test-driven_development Wikipédia]<br/>
<br/>
Ce processus est également connu sous la 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.<br/>
<br/>
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. En TDD, avoir un grand nombre de tests est un effet secondaire sympa, et non uniquement son objectif.<br/>
<br/>
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.<br/>
<br/>
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.