Oh, je viens de trouver ça, ça peut t'intéresser : http://rubygems.org/gems/rails_parallel<http://rubygems.org/gems/rails_parallel/stats>
2012/5/1 Jean-Hadrien Chabran <[email protected]> > Pour ce qui est du GC, je dirais pas grandement, mais c'est quand même > conséquent. C'est surtout un amas de petites choses qui à force accélère le > tout. > Pour ce qui est du net, tu peux utiliser la gem VCR, c'est fait pour ça :) > Btw, capybara-webkit déchire, c'est de ce que j'ai testé le truc le plus > stable de tous. > > Faudra que je regarde pour le ramdisk, ça doit se packager dans une gem > sans trop de difficultés ! > > Ravi de t'avoir été utile :) > > > 2012/5/1 Guirec Corbel <[email protected]> > >> Bonjour, >> >> Je m'excuse mais je pense qu'il s'agit, finalement, d'erreurs de >> programmations. >> >> Je me suis rendu compte que les tests de RailsFrance utilisait >> internet... et me connexion est pourrie ce qui rend le test lent. >> >> J'ai refait les tests avec refineryCMS et j'obtiens une durée de 3 >> minutes 30. Je pense que c'est un temps raisonnable étant donné qu'il lance >> Firefox. Vos temps d'executions me seraient utiles, pour comparer. >> >> Pour mes propres tests, je pense que ce qui ralenti beaucoup l’exécution >> c'est le javascript. J'utilise beaucoup d'ajax et j'attends les réponses. >> Je fais des sleep de 0.1 seconde. J'ai vu qu'il existait de meilleure >> solution, je vais les tester. Pour précision, j'utilise capybara-webkit. >> >> Je m'excuse pour Florian, j'ai repondu trop vite en me disant que je >> n'étais pas assez bête pour me plaindre de lenteur et faire des sleep... >> Apparemment je le suis. >> >> J'ai tester la solution du ramdisk et je gagne une dizaine de seconde. >> C'est très facile a faire sur Ubuntu. >> >> Bonne journée à tous! >> >> Le 2012-04-30 14:36, Guirec Corbel a écrit : >> >> 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] >> > > > > -- > Jean-Hadrien Chabran > > -- 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]
