Personnellement, comme je l'ai déja dit (mais j'insiste, que voulez vous, je suis très pieu ^^):
Mes tests me servent D'ABORD à utiliser du code que je n'ai pas encore écrit et ainsi parfaire (ou invalider) la structure de mes objets. Il me sert ensuite à vérifier que ce que j'implémente répond bien à ce qu'on attend. Enfin et enfin seulement, il me sert à vérifier qu'il n'y a pas de régressions dans les itérations n + x. Je vois pas ca comme une religion perso. Mais par contre, maintenant que j'y ai gouté, j'ai beaucoup plus de mal à coder sans. Ca apporte quand même une grosse sérénité pour le(s) dev(s). Les 2 premiers points améliorent naturellement la qualité des projets. Le 3eme aussi, mais il ajoute en plus un gain énorme de productivité (on cible plus vite les erreurs en cas de refactoring, on a une idée plus précise de ce qui ne va pas en fonction de la granularité des tests, surtout les tests de modèles). Pour ceux qui minimisent l'aspect "non-régression" des tests, je serai curieux de connaitre votre expérience. J'ai vu bon nombre de clients (et de développeur) littéralement "péter des cables" sur des projets qui n'avaient que peu d'itérations et qui merdaient déjà à plein tube parce que rien ne pouvait garantir que ce qui avait été fait marchait encore. C'est insupportable pour un client de demander une petite modif a droite et de se rendre compte à la livraison qu'à gauche (la ou on n'avait pourtant rien demandé), tout s'est effondré. (toute comparaison avec de la politique serait fortuite). Pour ma part, les tests "after", ca a 2 problèmes: 1) On ne teste pas ce qui "devrait" être. On écrit des tests et on s'arrange pour qu'ils passent (puisque le code est déjà écrit, donc "il marche"). 2) C'est très démotivant: à quoi tester du code qui marche déjà? Après, ce n'est que ma vision. Et en tant que bon croyant, je suis très prosélyte =). Le 25 avril 2012 08:11, Yannick François <[email protected]> a écrit : > 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 > railsfrance-unsubscribe@**googlegroups.com<[email protected]> > -- 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]
