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 -- 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]
