Bonjour l’équipe,
J’avais hâte de contribuer au projet Discourse, et j’ai remarqué que vos tests RSpec se chargent en 0 seconde !
Avez-vous des conseils sur la façon de réduire ce temps, s’il vous plaît ? Dans un de mes projets, cela prend environ 30 secondes !
Quelle commande avez-vous exécutée ? Que s’est-il passé ? À quoi vous attendiez-vous ?
Vous dites que le temps est nul, mais vous voulez qu’il soit inférieur à zéro ? Le temps que prend votre projet n’a aucune incidence sur le temps qu’il faut sur Discourse, qui est un très grand projet avec des milliers de tests.
Non, j’étais impatient d’apprendre comment vous l’avez fait, s’il vous plaît. Je veux faire la même chose sur mon projet.
Vous dites que le temps est de zéro, mais vous le voulez inférieur à zéro ?
J’ai mon propre projet qui prend 30 secondes et je veux réduire ce temps pour mon propre projet Rails, donc j’utilise ceci comme une opportunité d’apprentissage pour savoir comment l’équipe Discourse a réduit le chargement de ses fichiers spec à zéro.
Où avez-vous vu cela ? Pour être honnête, si quelque chose indique 0,0s, c’est probablement une erreur de mesure 
Quelques éléments clés que nous utilisons pour améliorer les performances de RSpec sont :
GitHub - grosser/parallel_tests: Ruby: 2 CPUs = 2x Testing Speed for RSpec, Test::Unit and Cucumber
test-prof/docs/recipes/let_it_be.md at master · test-prof/test-prof · GitHub (nous l’encapsulons dans une aide fab! dans notre base de code)
Je pense que cela pourrait être un effet secondaire de l’utilisation de parallel_tests. Le processus qui écrit la sortie ne charge en fait aucun test lui-même. Au lieu de cela, il lance plusieurs processus de travail pour exécuter les tests.
Je vois, merci beaucoup !
Pensez-vous que l’utilisation de Spring dans l’intégration continue (CI) soit une bonne idée ?
