+1, tout pareil ici (enfin sur RailsAdmin, pas sur Locomotive) Les tests sur un projet OS sont essentiels pour freezer les features et permettre à n'importe qui de refactorer sans connement supprimer des fonctionnalités (notez comme le franglais me permet d'éviter les répétitions sans étendre le champ lexical).
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). Le lundi 23 avril 2012 23:55:46 UTC+2, Didier Lafforgue a écrit : > > Ah le bon sujet bien polemique ! Surtout que si tu reponds pas bien, on va > te cataloguer direct mauvais programmeur. > > Ecrire des tests ne te fera pas devenir le meilleur programmeur au monde > :-) J'ecris plus de tests qu'avant et j'ai tjrs malheureusement des bugs > dans mes programmes, tjrs des cas non prevus, ...etc. Cependant, ils me > rassurent fortement, rassurent aussi l'equipe et evitent que lors de mes > nombreux refactoring, je ne casse pas tout. > Apres, je ne suis aucune methodologie particuliere sinon celle du bon > sens. Apres je pourrais en appliquer une a la lettre, mais cela se ferait > au detriment de la progression globale du projet. Tout est une question de > dosage. > > Sinon, mon workflow sur LocomotiveCMS est simple: > > 1/ si nouvelle fonctionnalite: > > a. j'ecris le code a l'instinct de vieux programmeur. > b. j'ecris 2 ou 3 tests qui montrent que le cas nominal passe ainsi que 2 > ou 3 cas speciaux > c. je refactore (la partie que j'adore le plus !) > d. j'ajoute d'autres tests si je vois des cas susceptibles de faire bugger > la fonctionnalite > > 2/ si bug > > a. j'ecris le test qui fait planter l'appli ou un des composant de l'appli > b. je debugge > c. je relance mes tests et je commit > > voila > > > Le lundi 23 avril 2012 19:54:41 UTC+2, Guirec Corbel a écrit : >> >> Bonjour, >> >> Dans ma quête pour devenir le meilleur programmeur Ruby On Rails du monde >> (rien de moins) je me pose encore une question. Quelle structure utilisez >> vous pour vos tests? >> >> Pour le moment, voici ma philosophie : >> >> 1. Je créer mon test d’intégration (Happy path). >> 2. Je créer le code pour passer ce test et j'optimise. >> 3. Je créer mes specs pour les modèles. >> 4. Je créer mes specs pour les controllers afin de pouvoir tester en >> détails certaines fonctions. Par exemple, pour une recherche, je vais >> tester si le résultats est bien ce que je veux selon les différents >> critères. >> 5. Je commit. >> 6. Je créer un second tests d'intégration (Unhappy path), s'il y a >> lieu, afin de voir si les différents messages sont affichés. >> 7. Je commit. >> >> Au niveau de mes specs pour les controllers, j'isole mes tests >> partiellement. Je créer un enregistrement dans la base de données mais je >> stub pour vérifier le validité, par exemple. >> >> Je ne créer par de tests pour mes presenters, helpers, mailers, etc... >> tout ça est testé dans les autres tests. >> >> J'ai vu que beaucoup de projets ne testaient pas les controllers. Qu'en >> pensez vous? Je les fais parce que ça va plus vite que de tester un test >> d'intégration mais je me rend compte que ça m'arrive de les oublier et que >> ça tests quasiment toujours ce qui est déjà testé dans les tests >> d'intégration. >> >> Personnellement, comme modèle de référence je me fie beaucoup sur >> RefineryCMS. Quel projet utilisez vous comme modèle? >> >> >> Merci, encore une fois, pour vos avis. >> >> Guirec CORBEL. >> > -- 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]
