On 24/04/2012 23:30, Benoit B. wrote:
Ensuite le TDD, c'est une question de religion. Et les religions,
c'est comme le père Noël, tu peux pas empêcher les gens d'y croire. :/
Sans troller, c'est sympa pour les projets très horizontaux, style
wrappers d'API. Red, green, refactor. On détruit pas le donjon en
creusant les douves du château de sable.
Sur les projets multi-stacks, ça brise tout de suite la créativité si
t'es un brin bricoleur. Pour ceux qui aiment concevoir dans
l'abstraction, peut-être... Sinon mieux vaut tester à la fin selon moi
(mais avant de refactorer/revoir la qualité du code).
Je ne peux pas m’empêcher de donner mon avis. Le TDD, c'est un peu plus
qu'une religion, et c'est beaucoup plus qu'un outil pour du "test de non
régression" comme tout le monde le suggère ici.
Si je peux me permettre, toute les personnes qui font du test after,
vous devriez n'utiliser que Selenium, via un selenium IDE. C'est bien
suffisant et plus pratique. C'est un vrai outil de non régression.
Le TDD, aide à créer une architecture simple. Et j'ai pu le constater
plus d'une fois, quand tu ne l'utilise pas, ton code marche peut-être,
mais c'est très très moche et compliqué pour rien du tout. Mais je ne
vous apprend rien car j'ai constaté cela dans une grosse grosse majorité
de la communauté Rails. On parle agilité, mais finalement... C'est du
flan. On parle test, mais bon, on le fait after hein, et c'est juste
pour la non régression.
Désolé d'être un peu raide. Je me demande si finalement c'est pas un peu
une religion... En fait c'est sûrement une religion. Mais pour moi c'est
bien plus, et passer derrière des dev rails qui on fait du test after,
pour moi c'est travailler sur du legacy code, ça fait le même effet.
Sinon, niveau structure, ou plutôt mode opératoire, et à condition que
les développeurs qui m'ont précédé dans le code m'en laisse la
possibilité (oui avec du test after on arrive vite à des tests qui
prennent trop de temps à s’exécute poru faire du TDD :))
1. je fait l'écran (quitte à mettre des fake dedans)
2. j'écris des tests simple sur le controller (je l'isole, sinon, c'est
plus un test unitaire) avec mock et co
3. j'écris le code juste nécessaire à faire passer le test
4. A chaque mock que j'écrit j'ai ecrit un test en pending pour les modèles.
5. J'écrit un test pour le modèle dont le controller à besoin
6. J'écrit le code juste nécessaire à faire passer le test
7. je reprend en 2, en 5 ou en 1 en fonction des besoins.
Je suis cependant d'accord, faire du TDD, c'est pas facile, ça
s'apprend. C'est peut-être pour ça que la plupart des Railers que j'ai
rencontré n'en font pas.
J'espère ne pas faire dériver le sujet sur un pour ou contre tdd. Si
quelqu'un souhaite en parle plus, je suis dispo pour en parler autour
d'une bière, pour accompagner quelqu'un au dojo de paris, ou en parler
par mail, IM, ou ici mais sur un autre fil ;-)
--
@ya_f
--
Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de
Google Groups.
Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse
[email protected]
Pour résilier votre abonnement envoyez un e-mail à l'adresse
[email protected]
