59 votes

Exécution de tests unitaires JavaScript sans tête dans un build d'intégration continue

J'ai un plan de construction de webapps fonctionnant sur un système d'intégration continue ( Atlassian Bamboo 2.5). Je dois intégrer QUnit -Les tests unitaires JavaScript sont intégrés au plan de construction de sorte qu'à chaque construction, les tests Javascript sont exécutés et Bamboo interprète les résultats des tests.

De préférence, j'aimerais pouvoir rendre le processus de construction "autonome" afin qu'aucune connexion à des serveurs externes ne soit nécessaire. Avez-vous des idées sur la façon d'y parvenir ? Le système CI qui exécute le processus de construction est sur un serveur Ubuntu Linux.

55voto

miek Points 2173

Comme j'ai réussi à trouver une solution moi-même, j'ai pensé que ce serait une bonne idée de la partager. L'approche n'est peut-être pas sans faille, mais c'est la première qui m'a semblé fonctionner. N'hésitez pas à poster des améliorations et des suggestions.

Ce que j'ai fait en un mot :

  • Lancer une instance de Xvfb un framebuffer virtuel
  • Utilisation de JsTestDriver :
    • lancer une instance de Firefox dans le framebuffer virtuel (sans tête)
    • capturer le Firefox et exécuter la suite de tests
    • générer des résultats de test conformes à JUnit .XML
  • Utiliser Bamboo pour inspecter le fichier de résultats pour réussir ou échouer la construction.

Je vais ensuite passer en revue les phases plus détaillées. Voici à quoi ma structure de répertoire a fini par ressembler :

lib/
    JsTestDriver.jar
test/
    qunit/
            equiv.js
            QUnitAdapter.js
    jsTestDriver.conf
    run\_js\_tests.sh
    tests.js
test-reports/
build.xml

Sur le serveur de construction :

  • Installer Xvfb ( apt-get install Xvfb )
  • Installez Firefox ( apt-get install firefox )

dans votre application à construire :

Créer un fichier script pour exécuter les tests unitaires et générer les résultats des tests (exemple en Bash, run_js_tests.sh ):

#!/bin/bash
# directory to write output XML (if this doesn't exist, the results will not be generated!)
OUTPUT_DIR="../test-reports"
mkdir $OUTPUT_DIR

XVFB=`which Xvfb`
if [ "$?" -eq 1 ];
then
    echo "Xvfb not found."
    exit 1
fi

FIREFOX=`which firefox`
if [ "$?" -eq 1 ];
then
    echo "Firefox not found."
    exit 1
fi

$XVFB :99 -ac &    # launch virtual framebuffer into the background
PID_XVFB="$!"      # take the process ID
export DISPLAY=:99 # set display to use that of the xvfb

# run the tests
java -jar ../lib/JsTestDriver.jar --config jsTestDriver.conf --port 4224 --browser $FIREFOX --tests all --testOutput $OUTPUT_DIR

kill $PID_XVFB     # shut down xvfb (firefox will shut down cleanly by JsTestDriver)
echo "Done."

Créer une cible Ant qui appelle le script :

<target name="test">        
    <exec executable="cmd" osfamily="windows">
        <!-- This might contain something different in a Windows environment -->
    </exec>

    <exec executable="/bin/bash" dir="test" osfamily="unix">
        <arg value="run_js_tests.sh" />
    </exec>
</target>   

Enfin, indiquez au plan de construction de Bamboo d'invoquer à la fois la commande test et recherchez les résultats des tests JUnit. Ici, la cible par défaut "**/test-reports/*.xml" fera l'affaire.

4voto

Justin Searls Points 3078

Pour tous ceux qui souhaitent exécuter leurs spécifications BDD Jasmine de manière transparente dans maven, le plugin jasmine-maven que je maintiens peut vous intéresser :

http://github.com/searls/jasmine-maven-plugin

3voto

Dom Points 21

Comme alternative, vous pouvez également essayer TestSwarm. Je l'ai mis en place et fonctionne en utilisant QUnit pour exécuter mes tests JS.

3voto

Trey Points 4170

J'ai joué avec un certain nombre de solutions au cours de l'année écoulée, mais je n'ai rien trouvé de comparable à Karma (anciennement testacular). Essayez-le

http://karma-runner.github.com/

0voto

RyanWilcox Points 7838

Vous pouvez utiliser rhino, le navigateur sans tête, pour exécuter vos tests unitaires sur votre machine CI. Bien sûr, l'inconvénient ici est qu'il ne trouvera pas les bogues spécifiques au navigateur X... mais c'est mieux que d'installer 2-3 OS sur votre machine CI, pour couvrir toutes les plateformes principales...

Mais oui, ça craint un peu... mais ça pourrait fonctionner juste assez bien dans un scénario de CI.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X