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?
fuente
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).
fuente
$(document).ready(...)....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.)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.
fuente
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ó.
fuente