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 .
