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]
