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 .
