He mirado la larga lista de marcos de prueba en https://github.com/ry/node/wiki/modules#testing. ¿Cuál es la experiencia con estos marcos?¿Cuál es el mejor marco de prueba para usar con Node.js?
Obviamente, la posibilidad de ejecutar en el navegador sería una gran ventaja, pero estoy interesado principalmente en Node.js. Algo con un sesgo muy asíncrono sería genial.
Actualización:
Mocha es el mejor en mi opinión.
¿Cuál es la experiencia con estos marcos?
Jugué con expresso que es un marco de prueba bastante bueno que también tiene cobertura de prueba. Ha sido creado por TJ Holowaychuk, que también es el creador de Express.js (increíblemente rápido (y pequeño) marco de desarrollo web de JavaScript del lado del servidor construido en Node.js y Connect.). Recientemente vi que también tiene una biblioteca genial llamada should.js que se puede usar junto con Expresso para una experiencia de prueba aún mejor.
Obviamente la capacidad de ejecutar en el navegador sería una gran ventaja
no creo que se puede ejecutar en el navegador, pero también no entiendo por qué usted quiere ejecutarlo dentro del navegador?
pero estoy interesado principalmente en Node.js. Algo con un sesgo fuertemente asíncrono sería genial.
Cita del expresso:
el argumento pasado a cada devolución de llamada es beforeExit, que se utiliza típicamente afirmar que las devoluciones de llamada han sido invocado.
Puede usar beforeExit para probar funciones asincrónicas.
TIP: Siga TJ Holowaychuk en GitHub, porque crea muy buen código de fuente abierta.
He estado usando nodeunit y su capacidad para trabajar con funciones asíncronas es razonablemente sencilla.
Hay un buen tutorial que debería prepararte para ir con nodeunit on his blog.
[Nota: la API ha cambiado desde la entrada de blog - setUp(callback) y tearDown(callback) ambos toman una devolución de llamada como un argumento, que es necesario llamar cuando su instalación/desmontaje se ha completado.]
Al ver esto y después de intentar algunas pruebas de las funciones de mongoose.js en expresso, la preferencia de nodeunit para no ejecutar todas las pruebas en paralelo y permitir las pruebas de setUp y tearDown parece útil. – asparagino
Comencé a usar Jasmine para mis pruebas de JavaScript específicamente porque es pequeño y se ejecuta tanto en el navegador como en el nodo. También cuenta con una API de reportes y matcher realmente sólida, por lo que es fácil de integrar con otras herramientas en el futuro. Tener un framework de burlarse de Buildin también es útil ya que a menudo es una de las primeras cosas que agregaría cuando estuviese usando qunit para TDD en el navegador.
De acuerdo con los comentarios del solicitante, probé vows, y resolvió muchos problemas que estaba teniendo con mi prueba de sincronización. Su capacidad para mezclar pruebas seriales y paralelas es increíble.
Asegúrese de leer el documento de orientación con cuidado, pero una vez que lo domine, es flexible, potente y produce resultados agradables y limpios.
ACTUALIZACIÓN: También recomendaría a las personas que comprueben should por sus afirmaciones. Permite afirmaciones muy flexibles y muy legibles, y es compatible tanto con Expresso como con Votos, y probablemente con la mayoría de los demás frameworks de prueba.
(estoy publicando esto como una respuesta por separado en caso de que las personas no se dan cuenta las observaciones sobre la respuesta de Alfred.)
ACTUALIZACIÓN 07/01/2015: Por lo que vale la pena, desde entonces he cambiado de Votos a Mocha, y de Deber a Chai. Mocha tiene ahora un soporte mucho mejor para las pruebas asincrónicas que usan promesas, y Chai permite varias opciones flexibles de afirmación, incluida la api expect, para aquellos a quienes no les gusta modificar el prototipo del objeto.
'should' pone una propiedad no enumerable llamada' should' al prototipo 'Object', lo que significa que * todos * los valores/objetos con los que se trata se ven * ligeramente * diferentes en el momento de la prueba y en el tiempo de producción. Si bien esto probablemente "simplemente funciona" en la mayoría de los casos, en principio es una mala idea modificar los prototipos incorporados; hacerlo solo durante la prueba se siente mal. Todo ha sido hecho exclusivamente para que puedan tener una buena sintaxis. – flow
@flow desde v2 es fácil de usar 'should' sin extender' Object.prototype' (simplemente llame a 'require ('should'). NoConflict()' y use should.js como una alternativa esperada. –
Yo uso VowsJS que es fácil de usar asincrónico marco BDD (Desarrollo conducido por comportamiento) y hacer el trabajo.
Por lo que veo últimamente es lo que muchos eligieron para probar sus módulos de NPM, así que creo que hasta ahora es uno de los mejores para usar.
Algunos marcos de pruebas populares que podrían utilizarse con NodeJS son también los que:
También puede ver una lista de prueba de JavaScript marcos here
pocos más librerías que podrían ayudar a escribir mejor código son aquellos:
También hay Bamboo CI Server por Atlassian automatiza construye y pruebas. Es un paquete para Apache/Tomcat(que sux porque usa Java y que lo hace muy pesado) tampoco es gratuito pero tiene un starter license which costs $10, así que creo que es asequible. Es el más destacado de todos los servidores de CI que he encontrado hasta ahora y es compatible con todas las pruebas unitarias que admiten xUnit, lo que significa que puede ejecutar compilaciones/pruebas para cualquier idioma con Bamboo.
Otra opción para CI con NodeJS es Travis que mucha gente usa para sus proyectos de código abierto, como dice Un servicio de integración continua alojado para la comunidad de código abierto.
También hay un debate de grupo de Google con Continuous Integration for Node JS Projects tema.
Una nota para las personas pensando en usar Votos: no se ha actualizado desde 2012 –
Ellos [hicieron algunos cambios después] (https://github.com/vowsjs/vows/blob/master/CHANGELOG.md). Última versión: Sep, 2015 –
Si desea un verdadero marco BDD, entonces tal vez considere Yadda. Se integra con mocha, jazmín, nodeunit, qunit, zombie y casperjs, para admitir archivos de características, p.
Scenario: provides the version of all services
given service x is running
and service y is running
when I request the service versions
then service x should be version 0.0.1
and service y should be version 0.0.2
Gracias por la respuesta, traté de expresar pero descubrí que la compatibilidad asincrónica no era muy intuitiva. (Para mí, de todos modos) – doffm
Actualmente estoy probando votos (http://vowsjs.org/), lo cual fue más fácil de entender para mí. – doffm
vowjs también parecía un buen marco de prueba. Me gusta la función de cobertura de prueba de expresso. Además, ¿me pregunto qué es lo que no entendiste? – Alfred