Je l'ai vu mais il n'est pas compatible avec Spork. Je pense que donc que ça ne doit pas augmenter réellement la vitesse des tests.
Le 1 mai 2012 13:42, Jean-Hadrien Chabran <[email protected]> a écrit : > 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] > -- 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]
