¿Qué se debe probar en Javascript?

En el trabajo, acabamos de comenzar con una aplicación fuertemente basada en Javascript (en realidad usando Coffeescript, pero aún así), de la cual he estado implementando un sistema de prueba automatizado usando JsTestDriver y fabric.

Nunca hemos escrito algo con tanto Javascript, así que hasta ahora nunca hemos hecho ninguna prueba de Javascript. No estoy seguro de qué deberíamos probar exactamente en nuestras pruebas unitarias. Hemos escrito complementos de JQuery para varias cosas, por lo que es bastante obvio que deben verificarse su corrección tanto como sea posible con JsTestDriver, pero todos los demás miembros de mi equipo parecen pensar que también deberíamos probar el Javascript de nivel de página.

No creo que debamos probar Javascript a nivel de página como pruebas unitarias, sino usar un sistema como Selenium para verificar que todo funcione como se espera. Mi razonamiento principal para esto es que, por el momento, las pruebas de Javascript a nivel de página tienen éxito a través de JsTestDriver, porque están intentando acceder a elementos en el DOM que posiblemente no puedan existir.

Entonces, ¿qué debe probarse en JavaScript?

javascript testing unit-testing

— Nathan Hoad
fuente

Aísla cualquier código de JavaScript que haya escrito en los módulos. Luego, simplemente prueba las entradas y salidas de esos módulos. Cualquier módulo que trate con el DOM significa que debe probar el DOM. Use una herramienta mejor que jsTestDriver.

— Raynos

Deberías probar la unidad de lógica de negocios. Si su lógica de negocios y elementos en el DOM están entrelazados, entonces tiene un defecto de diseño. Extraiga la mayor cantidad posible de lógica de negocios de los elementos de la página para que pueda probarse adecuadamente en la unidad. Para la verificación de la interacción del elemento DOM, debería usar Selenium.

— maple_shaft

@NathanHoad Usted escribe pruebas unitarias que se ejecutan en el navegador mismo, nodeunit, qunit y jasmine son herramientas sensatas. Cuando se ejecuta en el navegador, tiene el DOM. Podría usar una herramienta como testling para automatizar las pruebas del navegador.

— Raynos

Gracias. Estaba mirando hacia jsTestDriver porque decía que podía ejecutarse en el navegador, lo que, aunque técnicamente es cierto, descubrí que no es lo mismo que ejecutar con QUnit. He estado trabajando en mi propia herramienta en el momento que usa QUnit, con un panel de barra de herramientas de depuración Django personalizado. Usando Selenium podré detectar pruebas fallidas. Además, dudo que mi jefe pague por el testling, ¡aunque se ve bastante bien!

— Nathan Hoad el

relacionado: ¿Cómo prueba su javascript?

— mosquito

Respuestas:

Prueba todo lo que puedas.

La lógica pura se puede probar fácilmente.

Si su código interactúa con el DOM o la red, es mucho más difícil.

Si puede abstraer un fragmento de código para trabajar en un elemento DOM arbitrario en lugar de uno específico, puede probarlo más fácilmente. (Hacer que el elemento funcione en un parámetro).

El código que usa Ajax se puede probar simplemente llamando a la función de devolución de llamada con datos fijos. He tenido algunas pruebas donde sobrescribí $.ajaxcon mi propia función. ¡Solo asegúrate de volver a colocar el real cuando hayas terminado!

Lo que encontrará es que "JavaScript a nivel de página" realmente significa "código estrechamente acoplado", y si desacopla las partes del código, puede probarlas de forma independiente.

(Selenium no es una herramienta de prueba de unidades. Es ideal para escenarios de alto nivel, pero no se puede probar con él, y no funciona en un entorno aislado).

— Sean McMillan
fuente

Jasmine puede burlarse de las llamadas a funciones y los datos de respuesta, puede investigar eso en lugar de anular funciones.

— Steve

Debo aclarar: tenemos funciones y demás en cada página. Estaba hablando más sobre probar el código que se ejecuta dentro $(document).ready(...).

— Nathan Hoad

Todo es cuestión de cuán grande ...es eso . :-) Siento que deberías poder reducir eso a una sola función con nombre que también se prueba. Entonces su código no probado es una sola línea. (Ahora ese es un objetivo, no un hecho. En la práctica, siempre he tenido más de una línea de código no probado.)

— Sean McMillan

@SeanMcMillan: me resulta muy difícil probar partes de una aplicación que solo afectan al DOM, por ejemplo, una función que solo vincula varios eventos a algunos elementos DOM. ¿Cómo verificaría que esos eventos se escribieron correctamente? no es algo que las pruebas unitarias puedan hacer, sino hacer clic y verificar el navegador real (usando selenio o lo que sea)

— vsync

@vsync: puede probar que, digamos, un controlador de clic se adjuntó a un elemento DOM dado con bastante facilidad. No creo que sea posible probar que 'clic' es el controlador correcto, y que lo ha adjuntado al elemento correcto.

— Sean McMillan

Prueba de algoritmos. Las partes relacionadas con la GUI dependen más de un navegador específico, por lo que deben probarse con utilidades similares al selenio.

Su código, por supuesto, debe contener algoritmos como piezas de código aisladas, si no lo hace, entonces las pruebas unitarias son casi imposibles.

Los complementos de jquery, por cierto, no son fáciles de probar.

— Sergey Stolyarov
fuente

Todos los buenos puntos! Estoy de acuerdo en que tampoco son fácilmente comprobables por unidad, dependiendo de cómo estén escritos.

— Nathan Hoad

-1

Solía trabajar con Java y, por lo que veo, las pruebas unitarias de Java son más fáciles que las pruebas unitarias de JavaScript porque Java es más rígido.

Estoy convencido de que el desarrollo basado en pruebas es lo mejor, así que también estoy explorando cómo probar JavaScript de forma unitaria. En Java, me he burlado del código que hizo la conexión a la base de datos, los Objetos de acceso a datos, y lo comparo con el código en JavaScript que cambia el DOM y el código que hace llamadas AJAX al servidor.

Lo que quiero decir es que me parece que lo que debería probarse es la lógica explícitamente. Por ejemplo, no desea realizar una llamada AJAX cuando ejecuta pruebas unitarias porque (a) necesita que el servidor se ejecute y (b) es lento y una de las pautas de las pruebas unitarias es que debe ser súper rápido para que los desarrolladores no eviten ejecutarlos como cada minuto.

Otra pauta es que el proceso de integración continua envíe un correo electrónico diciendo que encontró una prueba unitaria que falló.

— SBel
fuente