Nuestro primer spy con Jasmine

Esta mañana el amigo Marc Rubiño ha escrito un interesantísimo post sobre como empezar con TDD y JavaScript, utilizando qUnit y ReSharper. Esto ha iniciado una pequeña charla en twitter.  Con todo esto me he lanzado a hacer una pequeñísima introducción a los spy con Jasmine.

Mi primera tentación, como ha comentado Marc en su post, ha sido utilizar Chutzpah. Ya había hecho pruebas con el con Visual Studio 2012 y había quedado encantado, pero la verdad es que para Visual Studio 2010 no lo tienen tan bien resuelto. En lugar de correr junto con los otros tests de la solución, hay un dos menús contextuales para ejecutar los tests. Uno para ejecutarlos en el propio Visual Studio e informando de los errores en la ventana de Output y de Error List (pero no en la de test) y otro para ejecutarlos en un browser. Si escogemos esta segunda opción, veremos que la versión de Jasmine con la que está pasando los tests es la 1.1.0 y no he encontrado manera de actualizarlo a la 1.2.0. En VS2012 es bastante sencillo, pero en VS2010 no. Así que al final he desestimado esta opción y he tirado por la de toda la vida de tener un html que pase los tests (podéis ver uno de ejemplo en el mismo zip en el que se distribuye Jasmine).

Empecemos pues con el proyecto. La estructura del mismo es algo como esto

Solucion

 

Vamos a empezar nuestro primer test para comprobar que tenemos bien configurado el SpecRunner.html.

FirstTest

Alucinados con el test, ¿eh? Es sencillo pero ya podemos ver muchas cosas. Primero como definir un Suite con describe y un spec con it. Y después como hacer un aserción muy sencilla. Con esto, ejecutamos SpecRunner.html desde nuestro navegador favorito y vemos que todo ha ido bien.

FirstTestExecution

Perfecto, ya nos podemos poner con el test que nos interesa. Echémosle un ojo a la clase que queremos testear.

SimpleClass

Como veis es una clase muy sencilla que hace una llamada por ajax a un controlador y guarda el resultado en un atributo de la clase. Imaginaros que todavía no tengo el controlador hecho, o que yo no lo voy a hacer y que, a parte, quiero que mis tests sean unitarios, rápidos y que no dependan de elementos externos. ¿Qué tendría que hacer? Pues claramente, mockear la llamada al controlador. Si lo hacemos con nuestras clases en .Net con Moq, Rhino, Moles o el framework que utilicemos, por qué no lo tenemos que hacer en JavaScript?

Y aquí tenemos una de las ventajas de Jasmine sobre otros frameworks de testeo unitario de JavaScript: ella misma ya lleva el framework de mockeo incorporado, lo que ella le llama los spy.

Crear un spy es muy sencillo: tenemos que indicar cual es el objeto y la función que queremos espiar y después ya podemos simular callbacks, mirar si se ha llamado con los parámetros adecuados, si se ha llamado las veces esperadas, simular los valores de retorno, etc.

Vamos a quedarnos con la primera de las opciones y vamos a simular la llamada al controlador via la función ajax de jquery.

MockingJquery

Como veis, estamos indicando a Jasmine que queremos espiar la función ajax de jquery y que queremos que al llamarla, llame a un fake que simule el success. Con esto, ya podemos hacer después el expect que más nos interese, en nuestro caso que se está igualando el resultado al objeto asset. Podríamos haber espiado otras cosas, como que solo se ha llamado una vez, o que se haya llamado con el id 1 como parámetro.

Y hasta aquí esta pequeñísima demo. Espero que entre el artículo de Marc y este, ya no tengáis excusas para testear vuestro código JavaScript!

Hasta la próxima!