Discussion :

[renoo]

Grosse perte de temps. Je n'ai jamais et je ne ferais jamais ce genre de chose.

Tout le contraire pour moi. Gros gain de temps, je code les tests d'abord puis la fonctionnalité buggée à l'arrache pour que ca compile et que ca casse. Ensuite je code la fonction jusqu'à ce que le(s) test(s) passent. Je gagne du temps à trouver les bugs (du temps perdu avec le debuger pour des bugs à la con) et je pense avoir un code moins buggé avec ça (les bugs chez les clients c'est toujours le pire : cout en terme d'image, difficulté à reproduire, se faire expliquer...). Ca permet aussi de donner un bon rythme (test, dev, refactor). En bonus, j'ai un code testé que je peux faire évoluer sans trop casser.

[Luckyluke34]

je code les tests d'abord puis la fonctionnalité buggée à l'arrache pour que ca compile et que ca casse.

Malheureux, c'est du pain bénit pour les détracteurs de TDD qui vont dire que tu perds du temps à imaginer ton implémentation à l'arrache pour ensuite l'effacer

Plus sérieusement, je préfère créer juste une méthode vide ou qui throw une NotImplementedException (souvent générée automatiquement par une fonctionnalité de refactoring dans l'IDE), ça suffit pour faire planter le test.

[renoo]

Plus sérieusement, je préfère créer juste une méthode vide ou qui throw une NotImplementedException (souvent générée automatiquement par une fonctionnalité de refactoring dans l'IDE), ça suffit pour faire planter le test.

Oui c'est bien mieux comme ça et c'est plus ça que je fais d'ailleurs : une fonction qui a le bon profile mais la plus courte possible et buggée (return 1; si ca retourne un int) et c'est vraiment le plus rapide à coder. Le truc c'est que cette étape permet aussi tester un peu le test.

Mais sinon écrire une première implémentation pas top sur certains aspects (pex perf & co) et y revenir ensuite avec un ensemble de tests dont une partie peut être conservée... ça me semble plutôt du temps gagné, d'autant plus que peut être il n'y aura pas à revenir dessus (premature optimization is the root of all evil).

[Laurent 1973]

Pour ceux qui se pose des questions sur l’intérêt du TDD, je vous invite à lire les articles de Bruno (http://bruno-orsier.developpez.com/)
Il propose un tutoriel de TDD simple (http://bruno-orsier.developpez.com/t...inos/index.php) bien guider par les recommandations d'Uncle Bob.
Même s'il commence à dater de quelques années, il est toujours d'actualité.
Il propose aussi des réflexions intéressante sur le refactoring et les tests en isolation.
Ses articles parles de .NET, mais il est assez facile de les extrapoler dans d'autres langages.

Je vais reprendre le questionnement de certain: a quoi ça sert? Est-ce que cela fait gagner du temps?
J'ai travaillé, il y a quelque temps, sur un petit projet open-source d'un client dure en Java (300 classe, 12000 lignes): connexion à un serveur en http et affichage d'interface swing.
J'avais eu la bonne idée de réaliser ce client initial en TDD avec une jolie collection de tests en isolation sur les différentes couches.
Ce choix initial, je l'avais fait pour m'assurer non seulement d'avoir un code au plus simple de ce que je voulais faire mais également d'avoir pour l'avenir un ensemble de tests "garde-fou" me permettant de réaliser des évolutions future.
Dernièrement, j'ai été amener à le convertir en Ajax/JQuery.
Et bien j'ai juste commencé à convertir mes tests TDD du java vers le jquery.
Ensuite, je n'ai qu’a eut à implémenter chacun des objets et fonctions qui faisait "planter" mes tests.
Je fais la conversion en 2 semaines environs.
C'est sur les parties "esthétique" du projet (css) que j'ai passé plus de temps: les parties qui n'était pas couvert par le TDD finalement.
L'outil Ajax est déployé et assez peut de retour et de bug.
Je n'aurais pas eu cette batterie de tests qui m'ont guider sur les fonctionnalités à avoir pour être compatible, je ne pense pas que je me serais lancer dans cette migration ... ou alors j'y serais toujours.

Donc, non, le TDD est loin de faire perdre du temps.
On en gagne un peu au développement.
On en gagne encore plus lors d'un changement de technologie.
De plus, la qualité de ce que l'on obtiens est meilleur en allant droit à l'essentiel.

N'oubliez pas qu'un développement ne se termine pas à la première livraison.
Le plus souvent, il y a des améliorations, des corrections, des évolutions de votre logiciel.
Et d'avoir déjà des bloques logiciels bien refactorisés et "protégés" par des tests d'anti-regression est un confort pour le future.