2012-05-24 26 views
7

Guau, qué desastre. Este es el escenario.Jazmín + JSTestDriver + Cobertura + RequireJS

  • Backbone driven JS app.
  • RequireJS para la funcionalidad de AMD, inicializados como esto:

    <script data-main="js/main" src="js/require.js" type="text/javascript"></script> 
    

    continuación main.js dentro del siguiente código de configuración:

    require.config(
    { 
        paths: 
        { 
         ... : ... 
        } 
    }); 
    

    Cada Backbone Ver/modelo/router es un "define (. ..) "module" y "require (" theOneRouter ", ...)" se llama una vez en main.js.

  • r.js utilizado como optimizador con Uglify/Closure. Un main.js 'compilado' se crea en una subcarpeta ./release que selecciono dinámicamente dentro de mi framework .net.

  • Tardó un tiempo en hacer funcionar el Backbone + Require.JS, ¡pero funciona muy bien ahora!

  • Luego abofetear a Jasmine además de eso también requirió un poco de trabajo personalizado, pero funcionó bien. Tuve que cargar require.js desde mi SpecRunner.html, definir cada módulo de prueba como AMD usando la llamada a la definición de require (...) e instanciar & ejecutar Jasmine una vez desde una llamada a require (...) llamar una vez en el SpecRunner.html:

    require(
    [ 
    //"test/specs/testSpec1", 
    "test/specs/views" 
    ], 
    function() 
    { 
        jasmine.getEnv().updateInterval = 1000; 
        var reporter = new jasmine.TrivialReporter(); 
        jasmine.getEnv().addReporter(reporter); 
        .... 
        .... 
    }); 
    

    esto también funciona muy bien. Las pruebas cargan & ejecución, sin problemas. Require se ocupa de todo.

Ahora, me gustaría un marco como JSTestDriver para actuar como mi corredor. Elegí JSTD por su simplicidad, capacidad de prueba en navegadores remotos, compatibilidad con la cobertura de código, pero aún estoy abierto para otras sugerencias.

JSTestDriver per se funciona bien, el único problema que tengo es ejecutar la combinación JSTD + Jasmine + ReuireJS juntos. El mayor problema es, si le digo JSTD en el archivo de configuración de un jazmín/Requerir módulo de prueba con el fin de cargar, me sale el siguiente error:

http://requirejs.org/docs/errors.html#mismatch

Si uso r.js a todos Optmize mi código en uno main.js, la combinación funciona, incluida la Cobertura, pero la cobertura se recopila en un archivo gigante y es difícil de analizar. Sin mencionar que lleva mucho tiempo instrumentar un archivo js de 50k-lines-of-code y ejecutarlo a través de JSTD.

Intenté crear un archivo js parecido a un dispositivo que cargue todos los módulos de código de prueba Jasmine &, pero sigo volviendo al error de "falta de coincidencia" anterior, Y, si no le digo a JSTD sobre cada módulo individualmente (cargando un accesorio html/js que realiza la carga real) no se instrumentarán para la cobertura del código.

¿Alguien ha conseguido que esta combinación específica funcione? Tal vez estoy pidiendo demasiado ...

Respuesta

4

La solución es exactamente como se mencionó devadvocate. Como JsTestDriver y Require.js compiten para administrar la carga de archivos/dependencias, JsTestDriver genera un ajuste cuando intentas hacerlo al 100% de la manera Require.js (con módulos anónimos y define). En su lugar, debe nombrar sus módulos y usar require ([...], function (...) {... en lugar de definir ([...]. Escribí una publicación que muestra cómo integrar QUnit, Requirejs, y código de cobertura con JSTD: js-test-driver+qunit+coverage+requirejs. Uso QUnit en mi ejemplo, pero puede sustituir fácilmente a Qunit por Jasmine. Al tratar de resolver esto, consideré simplemente usar PhantomJS, pero para nuestra base de usuarios es esencial que tengamos un navegador cruzado probando, IE7, IE8, IE9, etc., así que un solo WebKit no lo cortaría. JsTestDriver es muy útil, pero me temo que la documentación deficiente aleja a los desarrolladores. Pronto conseguiré el código para mi ejemplo en GitHub . Espero que esto ayude.

+0

Gracias por la entrada, buen comentario. Sí, tiene razón sobre sus puntos y he intentado nombrar manualmente mis módulos y usar llamadas requeridas en lugar de definir() s, pero esa no es una solución factible: incluso si es automática, requeriría un trabajo adicional sustancial antes de cada ejecución de prueba, que me gustaría evitar por el solo hecho de ejecutar pruebas rápidamente durante el desarrollo. – Bernardo

+1

Así que ahora tengo una versión parcheada de jsTestDriver.jar que permite exlcusions de archivos a través de expresiones regulares. También permite cargar archivos JavaScript desde la sección 'servir'. Al servir los archivos fuente de JavaScript, no se ejecutarán automáticamente cuando se carguen las páginas de los navegadores. En cambio, cuando el navegador ejecuta require.js, require puede extraer los archivos de la sección de servicio. De esta manera, los módulos pueden ser anónimos sin ningún problema. Ver [Backbone-Testing] (http://pseudobry.com/backbone-testing/) – jdobry

2

No pude hacer que esto funcione y terminé usando PhantomJS para ejecutar mis pruebas de jazmín. http://phantomjs.org/

+0

he considerado PhantomJS, pero el punto de JSTD es ejecutar pruebas unitarias de plataforma cruzada, que PhantomJS no admite ser un web-kit sin cabeza. Supongo que eso lleva a la pregunta de si las pruebas unitarias multiplataforma son necesarias: ¿debo ejecutar pruebas unitarias en un entorno sin cabeza, y solo centrarme en ejecutar pruebas de integración/aceptación en un entorno de explorador cruzado de tipo Selenium? – Bernardo

+0

Creé mi propia solución para ejecutar pruebas unitarias en el navegador cruzado. No automatizo el proceso, pero podría ampliar fácilmente la solución para hacerlo. Aquí hay un enlace a mi publicación de blog -> [link] (http://blakeblackshear.wordpress.com/2011/12/09/a-simple-way-to-run-unit-tests-across-browsers-with -nodejs-socket-io-and-jazmín /) –

+0

Después de algunas semanas de experimentar, todavía estoy convencido de que las pruebas unitarias deben ejecutarse en un entorno de navegador, no sin cabeza. Por esa razón, he estado experimentando con Selenium y la solución alojada de SauceLabs y hasta ahora todo funciona. Mi único inconveniente es la cobertura del código: JSTD tiene una herramienta de cobertura y una presentación de informes perfectamente integradas, y parece que no puedo encontrar un instrumento comparablemente inteligente para un entorno personalizado. – Bernardo

2

¿Has probado nombrar tus módulos bajo prueba y usar require en lugar de definir en tus pruebas?

https://github.com/podefr/jasmine-reqjs-jstd

Editar:

acabo publicado un conjunto de herramientas de código abierto que se espera ayude a los demás tanto como me ayuda. Es una composición de muchas herramientas de código abierto que le proporciona una aplicación de red troncal requireks de manera inmediata.

Proporciona comandos únicos para ejecutar: servidor web dev, corredor de prueba de un solo navegador jasmine, corredor de prueba de varios exploradores jasmine js-test-driver y concatenación/minificación para JavaScript y CSS. También genera una versión no modificada de su aplicación para la depuración de producción, precompila sus plantillas de manubrio y admite la internacionalización. No se requiere configuración. Simplemente funciona.

También es compatible con los módulos sin nombre bajo prueba.

http://github.com/davidjnelson/agilejs

+0

Sí, he visto ese proyecto y he tenido éxito con él, pero es demasiado engorroso. En un proyecto grande con muchos módulos que requieren muchos otros módulos, tendría que tener un sistema para nombrar automáticamente todos los módulos bajo prueba. Gran punto de dolor, yo. Encontré una solución más limpia para Selenium & Node Coverage ... – Bernardo

+0

He resuelto este problema con mi nuevo kit de herramientas de agilejs: http: // github.com/davidjnelson/agilejs – davidjnelson

0

Control hacia fuera este repo (Bredele appolo), que es un ambiente que corre especificaciones Jasmine TDC sobre módulos anónimos cargados con require.js y JsTestDriver.

Si está desarrollando módulos no anónimos, también le aconsejo utilizar la solución podefr.

Olivier