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]

Répondre à