Ejecutando pruebas de unidades de JavaScript sin cabeza en una compilación de integración continua

Question

Tengo un plan de compilación de aplicaciones en ejecución en un sistema de integración continua (Atlassian Bamboo 2.5). Necesito incorporar QUnit pruebas de unidad de JavaScript basadas en el plan de compilación para que en cada compilación se ejecuten las pruebas de Javascript y que Bamboo interprete los resultados de la prueba.

Preferiblemente, me gustaría poder hacer que el proceso de compilación sea "independiente" para que no se necesiten conexiones a servidores externos. Buenas ideas sobre cómo lograr esto? El sistema de CI que ejecuta el proceso de compilación se encuentra en un servidor Linux de Ubuntu.

Answer 1

Como logré encontrar una solución, pensé que sería una buena idea compartirla. El enfoque puede no ser perfecto, pero es el primero que parece funcionar. Siéntase libre de publicar mejoras y sugerencias.

Lo que hice en pocas palabras:

• lanzamiento de una instancia de Xvfb, un framebuffer virtual
• Usando JsTestDriver:
  • lanzamiento de una instancia de Firefox en el uso de este dispositivo virtual (headlessly)
  • captura la instancia de Firefox y ejecuta la suite de prueba
  • generar resultados de las pruebas JUnit compatible .xml
• uso de bambú para inspeccionar el archivo de resultados para aprobar o no la acumulación

próxima voy a ir a través de las fases más detalladas.Esto es lo que mi mi estructura de directorios terminó pareciéndose a:

 
lib/ 
    JsTestDriver.jar 
test/ 
    qunit/ 
      equiv.js 
      QUnitAdapter.js 
    jsTestDriver.conf 
    run_js_tests.sh 
    tests.js 
test-reports/ 
build.xml 

En el servidor de compilación:

• Instalar Xvfb (apt-get install Xvfb)
• Instalar Firefox (apt-get install firefox)

En su aplicación que se construirá:

• Instalar JsTestDriver: http://code.google.com/p/js-test-driver/
  • añadir el QUnit adaptersequiv.js y QUnitAdapter.js
  • configurar JsTestDriver (jsTestDriver.conf):

 
server: http://localhost:4224 

load: 
# Load QUnit adapters (may be omitted if QUnit is not used) 
    - qunit/equiv.js 
    - qunit/QUnitAdapter.js 

# Tests themselves (you'll want to add more files) 
    - tests.js 

crear un script f ile para ejecutar las pruebas unitarias y la generación de resultados de la prueba (ejemplo, 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." 

Crear una tarea Ant que llama a la secuencia de comandos:

<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> 

Por último, decirle al bambú construir plan para tanto invoque el objetivo test y busque los resultados de la prueba JUnit. Aquí el valor predeterminado "**/test-reports/*.xml" funcionará bien.

Answer 2

Es posible que pueda utilizar el rinoceronte, el navegador sin cabeza, para ejecutar las pruebas de unidad en el equipo de CI. Por supuesto, la desventaja aquí es que no encontrará errores específicos del navegador X ... pero sí supera la instalación de 2-3 sistemas operativos en su cuadro CI, para cubrir todas las plataformas principales ...

Pero sí , este tipo de mierda ... pero podría funcionar lo suficientemente bien en un escenario de CI.

Answer 3

Como alternativa, también puede probar TestSwarm. Lo tengo funcionando usando QUnit para ejecutar mis pruebas JS.

• http://github.com/jquery/testswarm
• http://swarm.jquery.org/

Answer 4

Para cualquier persona interesada en el funcionamiento de sus especificaciones Jasmine TDC headlessly en Maven, que podría estar interesado en el jazmín-maven-plugin que sostengo:

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

Answer 5

He usado maven y junit para llamar a rhino. No es elegante, pero lo uso para probar los servicios básicos y el código de utilidad.

Requiere burlarse de clases no compatibles, como XHR con bibliotecas Java.

Encontré que es el mejor código todo en javascript (pruebas, etc.) y solo uso junit para la organización de compilación y un enlace al CI.

Me gustaría ver si JsTestDriver puede hacerlo. O mocha con un reportero de junio.

Answer 6

JS Test Runner es una muy buena solución. Utiliza PhantomJS y QUnit.

Answer 7

He jugado un montón de soluciones durante el año pasado, pero no encontré nada en el estadio de Karma (anteriormente testacular). Darle una oportunidad

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