N'as-tu jamais eu le probleme d'un reload de spork qui n'a pas été
fait et qui faisait que ton test passait ? La configuration de spork
est une horreur et peu vite cacher des problèmes. C'est comme
l'auto-reload de rails, pourrais-tu vivre sans? Spork le block ...
Non, j'ai pas vraiment de problème.
Je fais ceci dans mon spec_helper :
Spork.each_run do
Dir["#{Rails.root}/app/models//*.rb"].each do |model|
load model
end
FactoryGirl.reload
Rails.cache.clear
ActiveSupport::Dependencies.clear
end
J'avoue que que ça reload beaucoup de chose mais c'est super rapide. Un
test s'execute en moins de 0,5 secondes. C'est peut être une seconde pour
10 tests. Je sais qu'avec du pure Ruby ça va plus vite mais sincèrement, je
vois pas l’intérêt d'aller plus vite.
Avez-vous vu le railscasts concernant les services objects? Je ne dis pas
qu'il faut tout mettre dans un modèle mais, pour moi, l'interface avec la
base de données doit rester dans le modèle. Tout ce qui n'est pas de
l'interfaçage avec la base de données devrait être ailleurs. Regarde ce
modèle :
https://github.com/GCorbel/comment-my-projects/blob/master/app/models/comment.rb.
Je pense que c'est tout à fait lisible. Ça ne s'occupe de la persistance et
de la validation. La validation est sûrement de trop car j'utilise
ActiveRecord et que Rails ne suit pas le SRP. C'est un fait établi.
Avant d’être créé, je vérifie que le commentaire est un spam ou pas. J'ai
créé un service pour ça ici :
https://github.com/GCorbel/comment-my-projects/blob/master/lib/spam_checker/spam_checker.rb.
Le but de cette objet est de vérifier si un commentaire est un spam.
L'objet ne fait que ça.
Une fois qu'un commentaire est créé je veux qu'il y ai des emails envoyés.
J'ai donc un callback ici :
https://github.com/GCorbel/comment-my-projects/blob/master/app/observers/comment_mailer_observer.rb.
Cette objet ne fait que vérifier la vérification de nouveaux commentaires
et envoie des courriels.
Enfin, j'ai mon contrôleur :
https://github.com/GCorbel/comment-my-projects/blob/master/app/controllers/comments_controller.rb
.
Et les tests correspondants :
-
https://github.com/GCorbel/comment-my-projects/blob/master/spec/models/comment_spec.rb
-
https://github.com/GCorbel/comment-my-projects/blob/master/spec/lib/spam_checker/spam_checker_spec.rb
-
https://github.com/GCorbel/comment-my-projects/blob/master/spec/observers/comment_mailer_observer_spec.rb
-
https://github.com/GCorbel/comment-my-projects/blob/master/spec/controllers/comments_controller_spec.rb
Je dis pas que mon code est parfait et j'ai encore beaucoup de chose à
apprendre mais je ne crois pas que l'on puisse dire que mon code est
illisible et qu'il n'est pas segmenté.
Le 1 février 2013 09:35, Cyril Mougel <[email protected]> a écrit :
> 2013/2/1 Guirec Corbel <[email protected]>:
> > Bonjour,
> >
> > Il y a une question que je me pose souvent. On dit souvent que ce n'est
> pas
> > nécessaire de charger rails entièrement pour tester certaines classes.
> > Personnellement, j'utilise spork. Rails est chargé en permanence et un
> test
> > ne recharge pas mon code à chaque fois. Mes tests sont très rapide.
>
> N'as-tu jamais eu le probleme d'un reload de spork qui n'a pas été
> fait et qui faisait que ton test passait ? La configuration de spork
> est une horreur et peu vite cacher des problèmes. C'est comme
> l'auto-reload de rails, pourrais-tu vivre sans? Spork le block ...
>
> >
> > En ce qui concerne l'extraction de la création d'un utilisateur dans un
> > service, j'avoue que je n'aime pas trop ça. Pour moi, je garderais
> > l'interface à la base de données dans un modèle. Ceci dit, je suis
> ouvert à
> > toute proposition. Si vous pouvez m'envoyer des articles pour me contre
> dire
> > je suis tout ouvert. J'en ai déjà vu un là dessus mais j'ai pas accroché
> à
> > l'idée.
>
> Regarde un peu tes models. Dis moi si vraiment, tu ne trouve pas
> qu'ils sont devenu illisible ? N'as-tu jamais eu le soucis d'avoir des
> objet devenir impossible à créer dans tes tests car il possedait trop
> de validation, de callback ? Le dernier article que j'ai lu à ce sujet
> est celui-ci (
> http://thunderboltlabs.com/posts/5-simple-rules-to-good-oo-in-rails)
>
> >
> > Ensuite, pour moi, un test unitaire doit être unitaire et doit donc
> stubber
> > tout ce qui n'est pas de la responsabilité de l'objet qu'il test. Je
> suis le
> > Single Responsability Principle.
>
> Si tu es SRP, justement, il faut faire cette couche Service. Depuis
> quand c'est la responsabilité d'un objet de lancer des 10aines de
> méthode ? Depuis pour être SRP il ne faut pas faire de méthode de
> classe.
>
> >
> > Je suis peut être un peu hors champs mais j'avoue ne pas comprendre
> pourquoi
> > créer un service pour la création d'un modèle et ne pas utiliser un
> modèle
> > avec un ORM classique.
>
>
> Bad Fat Model.
>
> >
> > Le 1 février 2013 09:13, Olivier El Mekki <[email protected]> a écrit :
> >
> >> Hello,
> >>
> >> Ces service objects sont extraits de models, ça ne me choque donc pas,
> >> ici, de les laisser interagir avec la db sans ne rien stubber, comme ce
> >> serait le cas si tu testais directement le model.
> >>
> >> Il est vrai que dans les tests unitaires, nous sommes censé stubber les
> >> dépendences d'une classe. Mais je ne suis pas certain que nous puissions
> >> vraiment parler de dépendence en ce qui concerne User, ici : ça ne
> >> serait probablement pas excessif de voir en UserCreate une extraction
> >> d'une partie fondamentale de User (et donc : de ne pas traiter User
> >> comme une dépendence, mais comme un contexte).
> >>
> >> C'est d'autant plus important que tu vas sûrement, à un moment ou un
> >> autre, vouloir tester des validations. Ça n'aurait plus vraiment de sens
> >> en forçant leur résultat.
> >>
> >>
> >> On 14:52 Fri 01 Feb , Cyril Mougel wrote:
> >> > Bonjour,
> >> >
> >> > Suite au podcast Parlons Ruby avec Jean-michel Garnier (
> >> >
> http://parlonsruby.com/pr006comment-je-teste-avec-jean-michel-garnier/
> >> > ), j'ai voulu avoir un retour d'expérience de personne ayant réussi ce
> >> > genre de technique.
> >> >
> >> > De plus en plus, les développeurs rails commence à avoir une couche
> >> > "service" qui permet de limiter son controller et ses models. Un Thin
> >> > Controller / Thin Model. De plus dans une logique compléte de test, il
> >> > est conseiller de faire du fast test. Le require de rails prenant pas
> >> > moins de 5 secondes, il peut être interessant de l'éviter. Pareil pour
> >> > les accés en BDD qui prendre quelque 100aine de milliseconde en plus.
> >> >
> >> > Je suis moi en train de
> >> > commencer cette démarche. Mais je me heurte assez vite à un problème.
> >> > C'est que ma couche service étant tellement lié à ma couche
> >> > model que je dois très vite require 1 ou plusieurs models. De même, si
> >> > je ne require pas ces models et ne passe que par des mocks, je me
> >> > retrouve à avoir un test qui ne comprend que des stub pour verifier
> >> > que ma methode appele bien les methodes de mes objets. Donc l'intérêt
> >> > est très faible car aucune valeur ajoutée.
> >> >
> >> > Pour expliquer cela rien ne vaut mieux que du code. Cas simple, mais
> >> > qui peut être globalement correcte.
> >> >
> >> > J'ai une class UserCreate qui me permet de créer un utilisateur avec
> >> > son adresse.
> >> >
> >> >
> >> >
> https://gist.github.com/4691019/9d449582d9522e867ea4af6dfe4d6e66965c1041#file-user_create-rb
> >> >
> >> > On commence ensuite à lui mettre les specs adéquates ( bien sur il
> >> > faut le faire avant )
> >> >
> >> >
> >> >
> https://gist.github.com/4691019/ed7a66f305002177bd8abf68f8885234507f02a4#file-user_create_without_model_require_spec-rb
> >> >
> >> > Avec ce genre de test, je change un tout petit peu mon implémentation
> >> > dans ma classe et je dois la changer dans mon test. Je stub 80% des
> >> > methodes appeler par ma classe. Personnelement, je ne trouve pas cela
> >> > utile.
> >> >
> >> > Donc, on se dit qu'il faut stuber uniquement la persistence en BDD. On
> >> > obtient ainsi le test suivant :
> >> >
> >> >
> >> >
> https://gist.github.com/4691019#file-user_create_with_stub_persistence_spec-rb
> >> >
> >> > On require un peu plus de chose car on require 3 nouveaux fichier dans
> >> > notre exemple, mais on limite globalement la persistence, mais sans
> >> > aucune certitude de persistence réel sans compter le cas ou demain
> >> > l'API de notre objet User change.
> >> >
> >> > Enfin on arrive à la solution "bourrine" le test d'integration :
> >> >
> >> > https://gist.github.com/4691019#file-user_create_integration_spec-rb
> >> >
> >> > Cette fois-ci on est sur que notre objet est persisté. Par contre il
> >> > faut avoir require toute la stack rails. Le test est plus long à
> >> > executer et le require aussi.
> >> >
> >> > Je voulais avoir des retours sur ces 3 exemples.
> >> >
> >> > Doit-on tester le 3 ? juste 2 et 3, ou juste 1 et 3 ? Je suis
> >> > actuellement dans de
> >> > grande phase de réflexion de ce coté là, car je n'arrive pas à me
> >> > décider sur le bon process. Je suis ouvert à tous commentaires.
> >> >
> >> > Merci
> >> >
> >> > --
> >> > Cyril Mougel
> >> > http://blog.shingara.fr
> >> >
> >> > --
> >> > --
> >> > 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 recevez ce message, car vous êtes abonné au groupe Google Groupes
> >> > Railsfrance.
> >> > Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le
> >> > concernant, envoyez un e-mail à l'adresse
> >> > [email protected].
> >> > Pour plus d'options, visitez le site
> >> > https://groups.google.com/groups/opt_out .
> >> >
> >> >
> >>
> >>
> >> --
> >> Olivier El Mekki.
> >>
> >> --
> >> --
> >> 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 recevez ce message, car vous êtes abonné au groupe Google Groupes
> >> Railsfrance.
> >> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le
> >> concernant, envoyez un e-mail à l'adresse
> >> [email protected].
> >> Pour plus d'options, visitez le site
> >> https://groups.google.com/groups/opt_out .
> >>
> >>
> >
> > --
> > --
> > 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 recevez ce message, car vous êtes abonné au groupe Google Groupes
> > Railsfrance.
> > Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le
> > concernant, envoyez un e-mail à l'adresse
> > [email protected].
> > Pour plus d'options, visitez le site
> > https://groups.google.com/groups/opt_out .
> >
> >
>
>
>
> --
> Cyril Mougel
> http://blog.shingara.fr
>
> --
> --
> 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 recevez ce message, car vous êtes abonné au groupe Google
> Groupes Railsfrance.
> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le
> concernant, envoyez un e-mail à l'adresse
> [email protected].
> Pour plus d'options, visitez le site
> https://groups.google.com/groups/opt_out .
>
>
>
--
--
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 recevez ce message, car vous êtes abonné au groupe Google Groupes
Railsfrance.
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant,
envoyez un e-mail à l'adresse [email protected].
Pour plus d'options, visitez le site https://groups.google.com/groups/opt_out .
