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]
