Discussion :

[tnarol]

Salut,

Je viens de lire [ame="http://fr.wikipedia.org/wiki/Test_Driven_Development"]l' article de wikipedia[/ame] à ce sujet.

Je comprends tout à fait l'intérêt d'écrire le code de test avant le code à tester. Par contre je comprends beaucoup plus difficilement l'intérêt de commencer par écrire le code juste suffisant pour passer le test puis de le refactoriser. Quel est l'intérêt ? Pourquoi ne pas chercher à écrire directement du code le plus abouti possible ?

[Patriarch24]

Pourquoi ne pas chercher à écrire directement du code le plus abouti possible ?

Rappels : faites simple, mais pas plus simple (Einstein) ; L'optimisation prématurée est la racine de tous les maux (ou presque) en programmation (Knuth).

[rad_hass]

Parce que croire qu'on peut écrire un code non perfectible dés le premier coup est au mieux un fantasme et au pire très dangereux ...

Si tu reprend n'importe quel code que t'as écris, normalement si tu le reprend à zéro une seconde fois tu va forcément mieux l'écrire, non ? Au moins tu vas chercher à mieux l'écrire ...

Je cite Robert C.Martin qui dans son excellent livre Coder Proprement compare l'écriture d'un code à l'écriture littéraire et le besoin indispensable de refactoriser son code, à l'image de l'utilisation d'un brouillon et sa relecture lors d'une rédaction ...

Le TDD pousse cette réflexion à son extrême, il faut écrire fonctionnelle, simple et se relire ensuite en améliorant le code et l'enrichissant.

[Maximil ian]

Parce que croire qu'on peut écrire un code non perfectible dés le premier coup est au mieux un fantasme et au pire très dangereux ...

+1. L'être humain est ainsi fait qu'il est utopique d'espérer pondre un code parfait du premier coup. Les paramètres sont souvent trop nombreux pour les prendre tous en compte d'entrée de jeu de manière satisfaisante.

A la place, on procède donc par petits pas, de manière à constituer une boule de neige qui grandit au fur et à mesure. Cette vision itérative et incrémentale est d'ailleurs la clé des méthodes agiles qui l'appliquent, au-delà du code, au cycle de vie du produit logiciel tout entier.

Bien sûr, il y a parfois des incréments évidents qu'on intègrera de manière naturelle sans leur consacrer de cycle TDD supplémentaire. Par exemple, si tu repères que la méthode utilitaire sur une chaine de caractères dont tu as besoin existe déjà dans ton code, tu ne vas pas la réécrire pour ensuite la supprimer lors de la phase de refactoring. Autant l'utiliser tout de suite. Cependant, beaucoup de code smells apparaissent lors de la phase de refactoring et uniquement là, cela vaut donc la peine d'y consacrer une étape entière après que ton test soit passé au vert.

[Rams7s]

Si le code auquel tu penses doit faire plus de choses que le test que tu écris, peut-être convient-il d'ajouter des cas de tests?

De toutes façon, si tu rajoutes d'autres choses à ton code que le minimum, en faisant de la couverture de tests ça se verra de suite que certaines parties ne sont pas testée.