Ne devrait-on pas avoir quelque part une mesure de vitesse du client ?
Cela permettrait en particulier de mieux apprécier les améliorations comme #2127 (closed) / !7 (merged).
Ah oui, Marc avait fait... test_speed.html qui appelle js/test.js, pas modifiés depuis presque 3 ans (e18b4077).
Ne marche pas actuellement (adresse DB + CGI en dur, voir si c'est juste cela ou d'autres choses).
Il pourrait être intégré à la suite de tests.
Essai pas fini dans 738d2156. En fait ce code est vieux (et n'utilise même pas app.js)... il faudrait probablement plutôt repartir d'un truc propre comme dans la segmenter_page.html de @tydax.
Dpeuis 65d890a7, speedTest est lancé dans les tests unitaires, mais on ne voit pas la sortie. Pourrait-on faire quelque chose pour afficher la sortie dans les jobs, pour ensuite faire des graphes ?
(Pour le coup Jenkins avait l'air plus complet là-dessus.)
Effectivement, on dirait que c'est plutôt du monitor en suivi d'un environnement, et pas de plusieurs.
gitlab-org/gitlab-ce#28106 et autres.
En tout cas, Gitlab, Jenkins, ou script maison sur la sortie des jobs, pour l'instant on n'affiche pas sur stdout (ou ailleurs) le résultat de speedTest.
#4141 (closed) montre qu'il nous faudrait vraiment surveiller par dev-ci la vitesse de certaines opérations. Après !578 (merged), a-t-on retrouvé la vitesse obtenue après !566 (merged) ?
Avec watir-performance, pour mesurer un test et/ou l'ensemble des tests dev-tests-watir ? Un test sur un slave fixe, et trouver comment indiquer cela (un temps en dur dans un fichier, et le test plante si +/- 10%) ?
C'est dernier temps, je crois avoir mis parfois des sleep a divers endroits sur des tests watir. Il faudrait les changer par des wait/until si on commence a chronométrer les actions car cela va sûrement provoquer des délais non compatible qui masqueront ce type de test.