[MÚSICA] [MÚSICA] Bien. Continuamos ahora con nuestra API, vamos a testear nuestra API. Lo que vamos a hacer es crear una carpeta, spec, new folder, api. Dentro de api, un file, que sea bicicleta_api_test.spec.js. Bien. Y aquà como vamos a tener que testear varios request, HTTP, y controlarlos, con cierto detalle, para justamente facilitar el testing, vamos a instalar una herramienta que se llama Request. Vamos a dar request. Me da save, asà lo guardamos como dependencia. Bien. Aquà está. Fantástico. Y vamos a comenzar a trabajar en nuestro, en nuestra API. Require, aquà estamos en lo mismo, punto, punto, punto, punto. Modo de bicicleta. Fantástico. Vamos a tener que traernos el request. [SONIDO] [SONIDO] Perdón. Request. Es una librerÃa. Y aquÃ, vamos a empezar a programar la API, vamos a ir explicando paso a paso, por necesidad, qué es lo que vamos a ir, o seguirle pidiendo. Vamos a hacer un primer describe, indicando dónde vamos a testear la API. Asà nos agrupa los test por la api de la bicicleta. Y aquà los describe pueden anidarse, ¿está bien? Asà que vamos a poner aquà get bicicletas para que sea el primero que vamos a probar. [SONIDO] Y dentro de éste, vamos a pedirle que, por ejemplo, status de bicicleta, nos dé un status 200. [SONIDO] ¿Y qué vamos a hacer acá? Vamos a hacer lo siguiente. Hagamos como antes, pedirle que bicicletas.oldbicis.legth, tobe.0, porque después probablemente vamos a agregarle algo y revisar que ese algo nos lo devuelva, porque si no, podrÃamos estar testeando un método que lo que haga es, esta copia y pega es más fácil, lo único que haga es devolverme esta vacÃa, tampoco nos sirve, ¿no? Entonces, you si le pedimos que agregue algo, y probamos que ese algo nos lo esté devolviendo, you [INENTENDIBLE] está vacÃa, digamos que tenemos un poquito más de confianza en el testing. Pues acá vamos a usar el modulito que acabamos de, de instalar, ¿no? Hacemos request.get para simular un get, mejor dicho, simular no, para ejecutar un get. Lo primero que tenemos que pasar es la URL, http://localhost, puerto 5000, le voy a indicar, pones el puerto que a vos más te guste, bicicletas. Ahà tenemos la URL, y después le vamos a pasar el callback, que va a recibir tres parámetros. Error, response, respuesta, y el body. Bien. Y aquà vamos a pedir que response punto statusCode, tobe, 200. Arranquemos con esto. Perdón, hagamos jasmine, ejecutemos solamente el tema de la api asà you. No, bueno, estamos con el otro, you sabemos que funciona. Bien. FÃjate qué está pasando acá. Nos tira un error que es cierto, no es muy descriptivo, simplemente nos dice que, no puede agregar la propiedad statusCode de algo indefinido, es decir, nunca se realizó el response. Aquà podemos ver el stuck, y fÃjate, no pretendo que puedas llegar a este, que llegues a este nivel de detalle con este curso introductorio hasta lo que vimos ahora, ¿eh? Pero aquà lo explican a nivel muy técnico y poco intuitivo, que el socket no está escuchando, http_client no está funcionando, el request cayó en un error, etcétera. Si pensamos un poquito más allá de este mensaje de error, lo que podemos ver es que estamos haciendo un request a esta URL, cuando todavÃa no está activo el servidor. Entonces, en nuestra consola activemos el servidor y vemos a ver qué pasa. Hacemos un npm start. Dame un segundo. Chequeemos en qué puerto está corriendo, está en el 3000. Bien, vamos a modificarlo para que esté en el 5000, npm start nuevamente, y ejecutemos ahora el test. Y ahora el test pasó. Y fÃjate que ahora se registra el get, ¿no? El request. Bueno, pero ¿qué podemos encontrar acá con esto que acabamos de hacer? De alguna manera, lo que nos gustarÃa que pase, sea que el server, cuando corra los test, que implique en el servidor, se active, se levante, sin necesidad de nosotros tener que manualmente operar sobre el servidor a mano, porque nos lo olvidamos, ¿y qué hacemos? Perdemos, se pierde tiempo, propenso errores, confusión, si está activo o no estaba activo, qué le hicieron y demás. Entonces, lo que vamos a hacer es incorporar el servidor como un módulo más, vamos a exportarlo dentro del módulo que genera el servidor, que crea el servidor, lo levanta y lo pone en escucha, y acá vamos a hacer lo mismo, cuando comiencen los test, que se ponga en activo el servidor, y cuando termine los test, se apaga el server. De esa manera, you tenemos, nos olvidamos de alguna manera, de estar pendientes del estado del servidor. Avancemos con eso. Bien. Incorporemos el server. FÃjate que acá voy a ir a donde lo creamos, ¿no? En archivo éste, www, dentro del bin, y simplemente lo que vamos a hacer acá es exportar server. ¿Está bien? Que es, que haga que se ponga en escucha y demás. Entonces, de esta manera, lo que podemos hacer aquà es traernos el módulo entero, var server que exporta justamente [SONIDO] [SONIDO] a estos. Bien. Bien. Y una cosa más que vamos a necesitar hacer es, empezar a lidiar con esto que mencionábamos antes, que es cuánto tiempo tarda esto para resolverse, ¿no? Asà que probemos a ver qué pasa ahora con el test. FÃjate que el servidor está parado, y el test ha pasado. ¿Por qué no hicimos un connect o algo? Porque you cuando trajimos, cuando hicimos el require de este módulo, se ejecuta todo lo que está dentro de este archivo para poder exportarse. Y fÃjate que acá el server yace según listen to port. ¿Está bien? Ejecutamos de vuelta. Y cuando termina se cierra, y al cerrarse, el proceso se mata directamente. Entonces, por ahora no hace falta que hagamos más, más nada. Veamos qué pasa si ponemos 400. [SONIDO] Llega a dar un error porque el callback se está ejecutando. Bien. Pasemos ahora a evaluar otros test, como los otros, del create, las búsquedas, los delete, y ahà vamos a ver que vamos a empezar a necesitar cierto anidamiento de tareas, y vamos a ver qué nos ofrece Jasmine en concreto para lidiar con estas diferencias de, de sincronismo de tiempo. Bien, vamos a testear un post ahora. Tengo que copiar y pegar el código porque no, no tiene tanta ciencia. Lo hacemos de vuelta con el describe, en el nombre le ponemos el post de bicicletas y la ruta que es el /create, el callback. Le pedimos que el status sea 200, y fÃjate que la diferencia, por eso me parecÃa interesante mostrarte este caso, le vamos a pasar por parámetro una variable que es un callback, que es done, y después nos vamos a ejecutar al final del callback del post, ¿está bien? La última acción que vamos a hacer en el post. ¿Qué hace este done? Este done se ejecuta, obviamente, cuando nosotros le digamos, pero es lo que espera Jasmine para finalizar el test. Hasta que done no se ejecuta, el test no termina. Es decir, el test se puede cortar por timeout, eso obviamente, y vas a ver que cuando testeamos APIs muchas veces pasa. Pero salvo esa excepción, hasta que no se ejecute done, el test no termina. ¿Qué ganamos con eso? Como es asincrónico este request, y todo lo que hacemos en Node.js, puede pasar que si nosotros no ponemos el done, se ejecute el request, mejor dicho, se manda a ejecutar al request, y después el test termina sin haber obtenido el resultado del request. FÃjate que lo que nosotros esperamos testear es en el resultado del request. Entonces, tenemos que tener algo que le diga a Jasmine, esperá que termine de ejecutarse el request para poder finalizar el test. Bien. Eso que tenemos a disposición es el done directamente. ¿Y cómo nos vamos al test? Bueno, muy fácil. Le pasamos los headers, creamos una bicicleta, fÃjate que está en formato string, o sea, es un JSON pero con string, algunos prefieren hacer el objeto JSON y convertirlo a string, como quieras, es lo mismo. Y después, salvamos el post pasándole el header, la URL, el body, y lo que vamos a testear es que la respuesta sea 200, y luego lo que vamos a hacer es buscar la bicicleta, preguntarle el color, y pedirle que sea rojo tal cual lo hemos creado. Y después le ponemos el done. Vamos a probar. Corrimos todos los test, y los test han pasado correctamente. Bien. ¿Con qué vamos a seguir? Se puede testear el delete y el update, te lo voy a dejar a vos como ejercicio. Y you enseguida vamos a incluir Mongo, y vas a ver que vamos a tener que ajustar poco, pero vamos a tener que ajustar los test para incluir la persistencia en el testing. [MÚSICA] [MÚSICA]
