Pour ma part, je n'ai encore jamais fait de tests avec cucumber par contre, je teste systématiquement mes controllers ainsi que mes modèles (avec rspec). Je fais un minimum de tests d'intégration avec rspec + capybara (au moins 1 par vue, histoire de vérifier que dans le cas nominal, ma vue s'affiche correctement). J'ai tendance à tester tous mes helpers aussi.
Ca fait beaucoup de tests au final mais je pense que: 1) tester les modèles est essentiel puisqu'il faut être certain que l'intégrité des données + métier est correcte (sinon l'appli ne fait pas ce que veut le client) + protection contre les régressions 2) tester les controller aussi parce que même si le modèle fait les choses correctement, ca ne veut pas dire que le controller l'appelle correctement. 3) tester les vues à minima est intéressant, nottemment les cas ou il y a des nil un peu partout (si la vue ne s'affiche pas, le reste a beau marcher, pour le client la valeur est de zéro) 4) tester les helpers car il s'agit de logique et comme toute logique elle doit être "garantie" et on doit pouvoir s'assurer qu'il n'y a pas de régressions. Au final, je ne suis léger que sur les tests de vue (on ne parle pas de javascript ici) parce que tester la présence de tel ou tel tag, ca rigidifie énormément le code et ca n'a aucune valeur pour le client. De toutes façons, les vues se testent plus manuellement lors d'une recette, en particulier pour tout ce qui est bugs css. Pour mon workflow: 1) j'écris les tests, qui vont me permettre de manipuler mes objets avant de les avoir écrits, et de me rendre compte par la même si mon design (quasiment full instinct) est utilisable 2) j'implémente (et/ou refactore) 3) je teste / corrige 4) commit 5) a la fin du sprint, quand le po valide le produit, je merge et je déploie Je rejoins didier L sur le discours. Y'a pas de méthode qui fait de toi le meilleur dev du monde ou pas (sinon on l'appliquerait tous et on serait tous les meilleurs du monde :p). Ecrire des tests, ce n'est pas la preuve que tu es bon (ya des très mauvais qui écrivent de très mauvais tests xD), c'est simplement un garde fou qui te permet d'assurer un minimum de qualité à ton produit. Seules ton expérience, ton intelligence et ton humilité feront de toi un bon ou un mauvais dev. Je te dis cela en qualité de meilleur développeur ruby du monde. Désolé mais je te laisserai pas la place comme ca. Pas très cordialement puisque tu veux me piquer ma place =). Le 23 avril 2012 23:55, Didier Lafforgue <[email protected]> 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] > -- 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]
