En voila un message intéressant! Il suffirait de mettre les deux bouts de code dans le spec_helper, fourni par 37signals, pour accélérer grandement la rapidité des tests?
Pour ce qui est de FactoryGirl je viens d'en faire l'expérience. J'ai créé mes tests en utilisant les mock puis j'ai vu que c'était un peu compliqué alors j'ai utilisé FactoryGirl. Peux tu fournir un exemple de code utilisant les mock comme il faut, selon toi? Merci pour ton aide! Le 30 avril 2012 14:11, Jean-Hadrien Chabran <[email protected]> a écrit : > Tu peux accélérer les choses avec divers petits tips, notamment tweaker le > GC pour qu'il run qu'entre les tests. > > Voir : http://37signals.com/svn/posts/2742-the-road-to-faster-tests > > Il y en a d'autre, je mailerais si je retrouve l'article. > > Je réagis sur le point de Florian : > > *Sinon, Ruby est lent, les tests sont lents, c'est pénible mais c'est > comme ca =).* > > Ruby n'est pas spécialement lent. Ce n'est clairement pas le truc le plus > rapide du coin, mais bon, si on fait des sites web avec, c'est que ce n'est > pas un veau pour autant et que c'est "good enough". Bref, je pense que tu > plaisantais de toute façon, je trouve ça juste un peu dangereux ce FUD sur > la ML :) > > Le gros problème avec les tests est l'écosystème conséquent et l'ensemble > de pièges qui peuvent s'y accumuler. > > > - Le boot de rails est lent quoi qu'il arrive > - spork, comme cela a déjà été abordé. > - FactoryGirl, aussi pratique que cela soit, représente quand même > pas mal de code executé, de création, etc .. > - être très vigilant et ne créer que ce qui est absolument > nécessaire. Ca parait très con, mais il est très tentant de recréer un > truc > qui ressemble à la prod en terme de modèle pour écrire ses tests. Or > cela > veut dire être dans une logique d'intégration, ce qui n'est pas du tout > l'optique avec des tests de modèles ou de controllers par exemple. > Donc, la > bonne méthode est de vraiment faire le plus minimaliste. J'ai divisé par > deux le temps de run d'un projet avec ce genre de trucs. > - Pas assez de mock. C'est tellement facile d'écrire un test de > controller avec un bout de FactoryGirl au lieu de mocker. C'est con, mais > hop, ça mange encore beaucoup de temps pour finalement peu de choses. > - Cucumber est mou. Récemment j'ai vu passer > https://github.com/jnicklas/turnip qui semble de ce que j'ai lu bien > plus rapide. Pas testé personnellement. > > Bref, de mon XP, c'est souvent un zêle coté data qui vient foutre en l'air > le truc, ainsi que l'accumulation de petites choses à gauche et à droite > qui au final viennent pourrir les tests suites. Avec quelque memoize, > refactor en tout genre, j'ai divisé par deux le temps de run de la test > suite de tutorys.com. Bref, c'est quand même lent, mais on peut gagner du > terrain si on est vigilant. > > > L'idée du ramdisk de Florian est vraiment intéressante, c'est peu > compliqué à faire, je serais curieux de voir les gains. > > Ca me plairait pas mal aussi de tester de run les tests //, sur une implé > qui le supporte, genre JRuby. > 2012/4/30 Guirec Corbel <[email protected]> > >> Mon projet de référence est >> RailsFrance<https://github.com/railsfrance/railsfrance.org>. >> Je suis sur un PC portable. Mon disque dur est à 5200 RPM. Ça se peut que >> ça soit ça. J'ai un disque dur externe à 7200 RPM. Je vais le tester mais >> je pense que le fait qu'il soit USB ralentisse la vitesse d’exécution. >> >> Merci beaucoup pour votre aide. Ce sont de très bons conseils. >> >> Le 30 avril 2012 10:44, Olivier Morel <[email protected]> a écrit : >> >> ton disque durs c'est un combien de tours par minute car pour ma part j >>> ai un 15000tours scsi avec un intel p4 4 coeurs et il utilise le disque >>> à peine plus de 20% avec une fenetre firefox ouverte et 6 onglet . >>> >>> Après cela depend peut être aussi de si tu utilise beaucoup de gem ou >>> pas ! >>> >>> -- >>> 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] >> > > > > -- > Jean-Hadrien Chabran > > -- > 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]
