Ah ouais, mais faudra jamais t'attendre à des miracles avec capybara. Sur mon dernier projet, 80% du temps de test était du aux tests des vues alors qu'ils ne représentaient même pas 10% du volume de tests.
J'ai demandé autour de moi si y'avait moyen d'optimiser ca et a priori non. Tu peux peut-être réduire le temps de chaque test (7 minutes, c'est très très long, ainsi que 20s pour accéder à une propriété de la page) mais tu n'auras jamais des perfs de fou avec ca. L'idéal, c'est de limiter au minimum tes tests de vue en reportant le plus possible de choses sur les controllers et les helpers (par exemple tu peux tester que ton assignment - controller - contient bien l'erreur X pour la clef Y). Par exemple, sur une vue qui sort une liste de products, je teste juste s'il existe une div product_<id> avec l'id du premier élément de la liste et je teste aussi que si la liste est vide, on a bien un message qui l'indique. Je teste rarement les formulaires qui n'ont pas de métier et si c'est le cas, en général, je teste plutot le js directement. Je teste pas les messages d'erreurs (ils sont déjà testés dans formtastic, que j'utilise). Les vues sont les choses qui sont le plus soumises aux changements du client. Faire beaucoup de tests dessus s'avère rapidement contre productif vu qu'il faut tout le temps les modifier et c'est loin d'être trivial d'écrire des xpath AVANT d'écrire les vues. Le plus simple reste de juste chercher à accéder à la vue pour vérifier qu'il n'y a pas d'exceptions quand on l'affiche (helper mal appelé, variable nulle etc.). L'apparence tu la testes avec tes neuils et le métier coté client, tu le testes en js. Donc réduis le volume de tes tests de vue et optimise ceux que tu conserves. Fous ton projet sur travis CI et utilise guard pour ne relancer que les tests nécessaires. Ce n'est pas a toi de faire tourner l'intégralité des tests mais ton serveur d'intégration =). Le 2 mai 2012 15:37, Guirec Corbel <[email protected]> a écrit : > C'est 10 secondes sur 5 minutes... C'est pas grand chose mais je > réessaierais une fois que j'aurais résolu mes problèmes de programmation. > > Pour le moment, ce que je fait, c'est que je regarde le temps d’exécution > de chaque test et je règle les plus longs. Je me rend compte que ce qui m'a > pris le plus de temps c'est l'utilisation des XPath inappropriés (10 à 20 > secondes à chaque fois). J'utilisais les Xpath pour voir s'il y avait un > message d'erreur pour chaque formulaire, donc souvent. Je vais voir pour > une meilleure utilisation. > > Ce qui prend tu temps, également, c'est le premier test avec Capybara. > J'imagine qu'il lance Capybara-webkit. J'ai réduit le temps de 5 secondes > en mettant l'option Capybara.server_port et Capybara.app_host dans mon > prefork. > > Le fait de faire un sleep pour attendre l'AJAX n'était pas une mauvaise > chose. Ça va plus vite que que si j'ajuste le default_wait_time ce > Capybara. Je vais quand même voir s'il n'y a pas de meilleures solutions. > > Je vous transmettrais un résumé des mes erreurs, pour éviter que ça arrive > à d'autres. > > Le 2 mai 2012 03:47, Florian Dutey <[email protected]> a écrit : > > > 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. >> >> Ce n'est pas de la bétise. Juste le genre d'erreur courante qui arrive à >> tout le monde et qui fait, malheureusement, perdre énormément de temps. >> >> >> > J'ai tester la solution du ramdisk et je gagne une dizaine de seconde. >> C'est très facile a faire sur Ubuntu. >> >> 10s sur combien de temps de test stp? Pour voir si c'est significatif. >> >> Le 2 mai 2012 09:22, thierry henrio <[email protected]> a écrit : >> >> 2012/5/1 Guirec Corbel <[email protected]> >>> >>>> Comme beaucoup de monde, je pense, je lance juste quelques tests à la >>>> fois, souvent un seul. Il est assez rare que je lance tous mes tests d'un >>>> coup. Je pense que c'est environ deux fois par semaine. >>> >>> >>> Pourquoi et quand lances-tu tous les tests ? >>> ?, Thierry >>> >>> -- >>> 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] >> > > -- > 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]
