Bonjour,
Je cherche à récupérer le résultat des tests RSPEC de mon appli et
déclencher une action. Une idée ?
J.
Souhaites-tu le résultat global = succès ou échec, ou bien quelque
chose de plus détaillé ?
Pour le résultat global, tu peux tester le code qui est retourné par
l’executable.
Pour un résultat plus détaillé, voir notamment les custom formats:
http://g-lunit.blogspot.com/2008/08/rspec-format-options.html
– Thibaut
Bonjour Thibaut et merci pour ta réponse,
Le jeudi 15 janvier 2009 à 10:41 -0800, Thibaut Barrère a écrit :
Souhaites-tu le résultat global = succès ou échec, ou bien quelque
chose de plus détaillé ?
Quelque chose de plus détailléPour le résultat global, tu peux tester le code qui est retourné par
l’executable.
c’est actuellement ce que je fais, je récupère la sortie standard de
spec (la sortie d’erreur ne renvoyant pas le résultat des tests
évidement)
Par contre, ce qui aurait été pratique, c’est de pouvoir par exemple
envoyer un bloc de code à spec qu’il exécute à la fin des tests ou même
customiser ses tâches dans un fichier de recette (task :after_tests
do …).
Pour un résultat plus détaillé, voir notamment les custom formats:
http://g-lunit.blogspot.com/2008/08/rspec-format-options.html
Bien pratique en effet pour customiser le format de sortie du résultat
des tests et il serait effectivement possible de lancer une action en
définissant un nouveau format. Cependant, je n’aime pas trop l’idée de
mélanger action en fin de tests et format de sortie.
J.
Je me pose une question: est-ce vraiment des tests dont tu veux
analyser la sortie, ou est-ce du code qui utilise la syntaxe de RSpec
pour réaliser des actions qui ne sont pas vraiment du test ?
Je demande cela parce qu’il m’est arrivé d’injecter par exemple les
assertions Test::Unit dans un code Ruby afin d’utiliser cette syntaxe,
sans que ça soit du test unitaire.
Auquel cas les solutions seraient différentes probablement (en
fonction de ce que tu en fais).
Par contre, ce qui aurait été pratique, c’est de pouvoir par exemple
envoyer un bloc de code à spec qu’il exécute à la fin des tests ou même
customiser ses tâches dans un fichier de recette (task :after_tests
do …).
Pour ce genre de cas en général je me fais une “meta-task” rake qui va
invoquer “spec” puis exécuter une action derrière si le code de retour
est OK (ex: envoyer un mail formatté avec l’output ou autre).
Si tu as besoin de plus de finesse, tu peux regarder
http://caldersphere.rubyforge.org/ci_reporter/classes/CI/Reporter/RSpec.html
pour t’inspirer. De la même façon, TeamCity (JetBrains) utilise un
custom rspec runner (voir sous TeamCity/buildAgent/plugins/rake-runner/
lib/rb/patch/teamcity/spec/runner/formatter) que tu pourrais regarder
de plus près.
Voilà pour quelques pistes…
– Thibaut
Le lundi 19 janvier 2009 à 00:47 -0800, Thibaut Barrère a écrit :
Je me pose une question: est-ce vraiment des tests dont tu veux
analyser la sortie, ou est-ce du code qui utilise la syntaxe de RSpec
pour réaliser des actions qui ne sont pas vraiment du test ?Je demande cela parce qu’il m’est arrivé d’injecter par exemple les
assertions Test::Unit dans un code Ruby afin d’utiliser cette syntaxe,
sans que ça soit du test unitaire.
oui c’est vraiment de l’analyse des résultats des tests dont il est
question.
est OK (ex: envoyer un mail formatté avec l’output ou autre).
c’est actuellement ce que je fais. Cependant, l’inconvénient de
l’analyse “regexp” de la sortie standard de spec et que le jour ou ils
modifient leur formulation…
La sortie d’erreur, quant à elle, ne renvoie pas le résultat des tests.
Cela aurait été pratique mais ce n’est pas son rôle.
Si tu as besoin de plus de finesse, tu peux regarder
http://caldersphere.rubyforge.org/ci_reporter/classes/CI/Reporter/RSpec.html
pour t’inspirer. De la même façon, TeamCity (JetBrains) utilise un
custom rspec runner (voir sous TeamCity/buildAgent/plugins/rake-runner/
lib/rb/patch/teamcity/spec/runner/formatter) que tu pourrais regarder
de plus près.
Effectivement, avec ci_reporter la sortie standard est formattée XML,
très bonne piste !
Merci Thibaut.
J.