Bonjour a tous, Je suis la meme methode que Guillaume mais en environment pro. (Pour http://versapay.com).
Quelques precisions: * J'essaye d'utiliser les "websteps" au minimum (celles fournies par cucumber-rails par defaut). La majorite des steps utilisees dans les scenarios sont donc des steps de haut niveau du type: "Given I log in as Quatchi", ou "Given I added a bank account", ou "Given I fill in the bank account form with valid details". Les scenarios sont ainsi beaucoup plus courts et lisibles. Et puis comme ca, c'est un vrai bonheur de faire des UX reviews avec viemcumber. https://github.com/versapay/viewcumber * Quand je programme en binome en jouant au ping pong (une personne ecrit un test, l'autre le fait passer et ecrit un autre test....), on change de "driver" (personne au clavier), a chaque fois qu'on descend ou monte d'un niveau. (du scenario, a la step, a la definition de la step, ecriture vue, controlleur ou modele) * Tres peu de test de controlleurs. Les scenarios cucumber testent malgres eux la majorite du code des controlleur et je trouve (apres 6 mois d'exprerimentation) que de decrire une ligne de code ruby par 5 lignes d'expectations rspec est assez inutile. J'en profite pour passer quelques articles dont je suis l'auteur qui pourraient vous interesser: * (My) RSpec best practices and tips - http://eggsonbread.com/2010/03/28/my-rspec-best-practices-and-tips/ * (My) Cucumber best practices and tips - http://eggsonbread.com/2010/09/06/my-cucumber-best-practices-and-tips/ * VersaPay flow. J'y parle entre autre de viewcumber qui est utilise pour effectuer de l'assurance qualite - http://www.versapay.com/developer-blog/versapay-development-flow/ φ http://pcreux.com 2011/9/13 Guillaume Desrat <[email protected]>: > Bonsoir, > > pour ma part, je n'utilise que Test::Unit au bureau, et, pour la partie > contrôleur / vue, je dois vous avouer qu'assert_tag m'a rendu fou. Plusieurs > fois. > > En revanche, sur mon temps perso, j'ai commencé à me documenter sur RSpec et > Cucumber. J'ai visionné quelques présentations, puis lu le RSpec book. Et le > démarrage (en douceur) d'un projet perso [1] pour suivre les dépenses du > couple a été l'occasion de m'essayer aux deux. > > Pour la méthode de développement, je suis ce qui était décrit dans une vidéo > sur Confreaks : > - je commence par écrire mon scénario, qui contient potentiellement des steps > inconnus > - j'écris les steps inconnus > - j'exécute le scénario, il échoue > - pour "résoudre" chaque step qui échoue, je descend d'un cran : > - s'il faut un contrôleur ou un modèle, je le crée > - s'il faut une action, je vérifie son existence avec une spec ; s'il > faut une méthode dans le modèle, j'écris la ou les specs > - une fois que mes specs passent, je remonte vers Cucumber, et je continue ce > top-bottom-top pour chacun des steps jusqu'à ce que le scénario passe > > Mon sentiment après quelques semaines d'utilisation (un peu le soir, un peu > le week-end) : j'aime beaucoup Cucumber, qui permet d'écrire des scénarios > que le Business va pouvoir comprendre, voire valider. Sur un plan perso, ça > m'oblige à formaliser les fonctionnalités que je souhaite développer. > J'aime également RSpec, pour l'écriture des specs les modèles, même si > quelques années en arrière j'étais réfractaire à cette façon d'écrire. > > En revanche, je me retrouve à avoir des specs pour les contrôleurs qui se > limitent à tester que telle ou telle action existe, et c'est tout. Ça me fait > une drôle d'impression, un vide, quand avec Test::Unit je teste tout le > fonctionnement de chacune des actions, en vérifiant qu'après l'appel telle > donnée a bien été modifiée. > Mais à bien y réfléchir, pour tester que tel contrôleur fait bien son travail > et qu'il m'affiche bien les données, je me repose sur Cucumber. Et là, "I > should see ..." bat assert_tag, et ma santé mentale va bien mieux. > > Seul bémol, le temps d'écriture Cucumber plus RSpec est plus long que pour du > simple Test::Unit. Qui plus est, on se retrouve à devoir lancer deux suites > de tests : les features et les specs. > > > Voilà pour mon retour d'expérience, dans un contexte perso, je tiens à le > (re-)préciser. > > > [1] le code est par ici : ; les répertoires features/ et spec/ sont à votre > disposition > > Le 13 sept. 2011 à 21:34, Guirec Corbel a écrit : > >> Tu as raison. Je parle aussi mieux Ruby qu’Anglais. Par contre, je trouve >> dommage que l'on perde l'aspect scénario et ceux pour trois raisons : >> 1 - Ça permet de communiquer avec le client. >> 2 - Ça permet de réfléchir à ce que l'on doit faire avant de le faire. >> 3 - On perd une grosse partie du BDD étant donné que l'on ne définit pas >> vraiment le comportement de l'application dès le début. >> >> Je pense que ce que je vais faire c'est la chose suivante : >> Vérifier avec RSpec la page qui est rendue, les variables qui sont envoyées >> et les messages envoyés en flash. >> Vérifier avec Cucumber que les formulaires sont bien affichés, peuvent être >> remplis, font l'action qu'il doivent faire. >> Je ne vérifierais PAS avec Cucumber la page dans laquelle j'arrive et >> l'affichage des messages flash. >> >> Finalement je voudrais garder uniquement les tests vraiment simples. >> >> Qu'en pensez-vous? >> >> -- >> 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] > > -- > Guillaume Desrat > > -- > 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]
