En la clase de hoy vamos a ver el testing, sobre todo testing, por qué es importante el testing, vamos a hacer testing desde cero
y a partir de ahí vamos a hacer el testing de nuestra aplicación de backend, todo lo que tenemos en el backend, nuestra aplicación de notas.
Para ello vamos a ver por qué es importante el testing, lo vamos a ver con un ejemplo pues muy clarito y a partir de ahí vamos a ir escalando poco a poco,
con dependencias, complicando, integrando cosas, ¿vale? Así que vamos a empezar desde cero. Aunque yo sigo el contenido que tenemos aquí en FullStackOpen,
yo a veces doy saltos, le cambio el orden porque creo que es más claro, así que lo podéis seguir como guía pero no es exactamente igual, ¿vale? Ya lo iréis viendo.
Entonces para empezar con el testing, a mí, sobre todo para la gente que no sepa por qué usamos el testing, vamos a empezar con un ejemplo bastante sencillo, ¿vale?
Vamos a poner que tenemos un método que se llama suma y que recibe pues dos parámetros y lo que hace es devolver a menos b.
Claro, alguien ya me dirá, bueno, pero esto está mal. ¿Y cómo sabemos que está mal? ¿Cómo podemos saber realmente que esto que hemos hecho está mal?
¿Qué es lo que nos dice, oye, te has equivocado? Claro, lo que tendríamos que hacer obviamente es ejecutar este método.
Pero ¿dónde lo ejecutamos, no? Porque normalmente si no podemos esperar a mitad de nuestra aplicación y hacer las pruebas.
Así que en este caso podemos ejecutarlo en un entorno controlado.
En este caso yo tengo aquí una aplicación que se llama Ranges, que es totalmente gratuita y sirve como un banco de pruebas para poner aquí código totalmente arbitrario,
que está bastante bien. Y podríamos ejecutar nuestro, pues nada, nuestro método suma, ¿no?
Es decir, vale, suma 1, 3 y esto nos da menos 2. No es lo que esperábamos.
¿Qué es lo que esperamos entre sumar 1 y 3? Pues esperamos que esto sea 4.
Ya nos dice que es falso, por lo tanto ya vemos que no está funcionando correctamente nuestro método.
Parece una chorrada, ¿verdad?
Ahora, podríamos subir un poco el nivel y decir, bueno, pues hacerlo más expresivo,
porque esto que nos debe volver a un false es un poco raro. Así que podemos poner, vale, si suma es diferente a 4,
porque no es lo que esperamos, que sea diferente a 4, entonces podemos utilizar consoleError y decir, bueno, pues la suma of 1 and 3 expected to be 4.
Bueno, debería salir el consoleError. No sé por qué. No sé por qué no le gusta el consoleError.
Supongo que porque lo formatea de una forma diferente, este, pero vamos a poner consoleLog. Ya está, no pasa nada.
Con consoleError sí que funciona. ConsoleError debería salir, pero en rojo.
A lo mejor esta aplicación no soporta el consoleError por beta saber qué motivo.
Ya nos está avisando que la suma de 1 y 3 debería ser 4 y nos ha dado algo diferente, ¿no?
Pero claro, esto es un caso que, bueno, vemos que obviamente no hace lo que esperábamos,
pero puede haber más casos. Por ejemplo, si ponemos la suma de 0 y 0,
esto, si es diferente a 0, debería aquí dar un error, ¿no?
Pero este funciona bien, por eso no entra por aquí.
Así que el hecho de tener más casos, podemos ver que nuestro método sí que funciona bien en algunos casos.
Ya estaríamos comprobando más de una cosa, ¿no? Algunos cornerCases.
Esto no siempre va a ser exactamente que funcione mal.
Es importante justamente ver que nuestro método, dónde falla para poder arreglarlo,
pero también podemos ver que hay otros casos en los que sí que está funcionando bien.
En este caso está funcionando bien, porque si intentas hacer 0 y 0, nos está devolviendo 0, lo cual está bien.
Ahora, claro, igual esto de poner consoleError es un poco de aquella forma.
Igual lo más interesante es directamente devolver un error y decir, vale, pues esto es un nuevo error.
Entonces nos debería decir, vale, hay un error porque la suma de 1 y 3, yo esperaba que fuese 4.
No funciona el consoleError, pero no funciona el error.
Y así de alguna forma le estamos dando como todavía más semántica.
Hay un método que es bastante interesante para esto, y de hecho vamos a pasar ya del run.js, vamos a irnos a no.js.
Vamos a irnos a nuestro proyecto, a ver si ya lo tengo abierto por aquí.
Pues lo que vamos a hacer en este proyecto es, vamos a crear aquí una carpeta, le vamos a llamar ya test,
y aquí vamos a poner, no sé si, suma.test.js.
Bueno, vamos a quitar este nombre que luego será un poco suma test.
Aquí tenemos nuestra suma, bueno, nos dice que no usemos newError, porque no sé qué, no sé cuánto.
Ya está bien que me dé este error, no le gusta el linter, no importa porque lo vamos a cambiar.
Lo que vamos a hacer, en lugar de utilizar el console, el newError y el if y tal, que esto se lee un poco raro,
vamos a comentar esto, y lo que voy a hacer en su lugar es utilizar el consoleAssert.
El consoleAssert lo que hace es que si te da, si lo que tú pones como primer parámetro es false,
entonces te va a salir el error que tú le vas a poner como segundo parámetro.
Suma de 1 y 3, esto debería ser 4.
Y si no es 4, pues vamos a poner el error este.
Suma de 1 y 3 debería ser 4, ¿vale?
De esta forma, si yo ejecuto este programa, este test, voy a poner aquí no test, suma test,
no sé si se ve, lo voy a hacer un poquito más grande, lo ejecuto, ¿vale?
Me dice que la aserción ha fallado, que la suma de 1 y 3 debería dar 4.
Esto significa que no está dando 4.
Esto, exactamente lo mismo, lo podríamos hacer con la de 0 y 0.
Si aquí le decimos que debería dar 1, lo cual está mal, ¿no?
La suma de 0 y 0 debería ser 1, sí que me entraría, ¿vale?
Me dice que la aserción está mal, pero esto no debería ser 1, debería ser 0.
Y ahora veremos que la aserción no aparecerá, ¿vale?
Es una forma interesante de utilizar el console como para hacer este tipo de aserciones.
Las aserciones, al final, lo que significa es que tú tienes una cosa que esperas que dé una cosa,
esperas que esto tenga este valor.
Si esto es true, significa que, vale, ha ido bien.
Si es false, significa que no ha ido bien y, por lo tanto, vamos a ver en consola este error de aquí.
Así funcionaría.
Bueno, pues ya tenemos como una pequeña herramienta para hacer aserciones, ¿no?
Ya tendríamos como nuestro propio sistema de testing.
Esta sería un poco la forma de saber si realmente nuestro método suma funciona bien.
Porque es que si no, si no lo ejecutamos, ¿cómo vamos a saber que funciona bien?
Obviamente, dos casos tiene pinta de ser pocos.
Lo mejor sería tener todavía más casos.
Al final, podríamos tener aquí un array que dijésemos, vale, pues cuando la a es 0 y la b es 0,
el resultado debería ser 0.
Ahora, cuando la a es 1 y la b es 3, el resultado debería ser 4.
Cuando la a es menos 3 y la b es 3, el resultado debería ser 0.
Podríamos tener aquí un montón de casos, tenemos un montón de checks.
Ahora, podríamos un poco refactorizar nuestros tests, estas aserciones que habíamos hecho,
y utilizar checks.foreach.
Lo que vamos a hacer es recorrer cada uno de los checks que hemos puesto aquí, en este array.
Ponemos el check y de cada check vamos a recuperar la a, la b y el resultado.
Y ahora utilizamos, bueno, esto me lo puedo copiar, ¿no?
Aquí vamos a eliminar esto.
Vamos a utilizar este console assert que teníamos aquí.
Solo que ahora, en lugar del 0, vamos a utilizar la a, aquí pondremos la b, y esto será el resultado.
Esto es muy conveniente porque así podemos automatizar también el mensaje.
Y así, de esta forma, ya nos estaría generando el error que queremos.
Ahora guardamos los cambios y vamos a poner aquí note.
Vale, y nos está fallando otra vez.
Obviamente los mismos tests porque nuestro método no está bien, ¿vale?
Está fallando la suma de 1 y 3, esperamos que de 4 y no está dando 4.
Podríamos ir más allá e intentar poner también cuál es el error que está dando, qué es lo que nos está devolviendo.
Aunque eso ya veremos que tampoco vale la pena que lo hagamos nosotros porque hay herramientas mucho mejores que las que podemos hacer nosotros que no lo van a chivar.
En este caso, obviamente, aquí esto sería un más.
Y lo que vemos aquí es que ahora ya han pasado, han pasado nuestros tests.
Para saber el número de tests que han pasado, podríamos poner aquí, por ejemplo, checks perform y ponemos aquí checks.length.
Y al menos sabríamos que...
Uy, 3 checks perform.
Mejor, ¿no? Creo que se lee mejor.
Pues han hecho 3 tests.
Esta sería la razón, sobre todo, por la que necesitamos tests.
Porque necesitamos comprobar que nuestras aplicaciones funcionan correctamente.
Vamos a ir un paso más allá.
Esto, obviamente, es una forma muy pillata de hacer tests.
Esto no es como lo deberíamos hacer.
Pero al menos hemos conseguido comprobar la funcionalidad de un método.
Esto nos está ayudando, nos está acercando un poco a nuestro objetivo.
Pero ya hay herramientas que nos van a ayudar justamente a ejecutar una tanda de tests.
De poder testear y que nos dé errores lo más descriptivos posible para ayudarnos a detectar dónde están esos fallos y solucionarlos.
Ya este suma test lo tenemos por aquí.
Vamos a crear una carpeta por aquí, le damos utils, y vamos a poner aquí que esto es for testing.
Vamos a hacer unos métodos que solo son para testear.
Vamos a poner un método que es palíndromo.
No sé si sabéis lo que es un palíndromo, pero básicamente lo que hace un palíndromo,
o el método palíndromo, sería darle la vuelta a la palabra, ¿no?
Ponerla en un espejo.
Y podrías detectar un palíndromo si, dividiendo una palabra entre dos,
la primera parte que queda a la izquierda es igual a la derecha.
En este caso lo único que vamos a hacer es construir un palíndromo.
Para ello vamos a, con el string que le pasamos como parámetro, aquí, string.
Este string le vamos a hacer un split, de esta forma lo convertimos en un array,
le vamos a dar la vuelta, y una vez que le damos la vuelta lo que hacemos es un join.
O sea, vamos a volver a juntar ese array y convertirlo en un string.
Esto ya tendríamos nuestro palíndromo.
Y también vamos a tener aquí un método que le vamos a llamar average,
que lo único que hace es, pues nada, vamos a medir, no, a calcular la media.
Para eso vamos a tener una suma, vamos a recuperar el array,
y para cada uno de los elementos del array, que va a ser un array de números,
lo que vamos a hacer es guardar en suma todo lo que tengamos en el número.
O sea, que cada número lo vamos sumando en suma.
Ahora lo veremos, ¿no?
Si tenemos un array, el 1, el 2 y el 3, pues primero en sum sería 0,
luego tendríamos 1, luego 1 más 2, 3, y luego el 3, pues 6.
Y ahora aquí lo único que tenemos que hacer es, de toda esta suma,
pues dividirlo por la longitud del array.
Ahora me dice que no estoy utilizando ni palíndromo ni average,
pues lo que voy a hacer es un module.export, porque estamos en common.js,
y vamos a sacar tanto el palíndromo como el average.
Ahora podría volver a crear mi funcionalidad que hemos hecho maravillosa, ¿no?
Del console.aser, pero esto sería un coñazo.
O sea, seguramente pues me empezaríais a odiar y me diríais,
pero ¿por qué haces esto? y tal.
Y lo haríais con razón, seguramente.
Porque hay herramientas muy buenas que ya nos van a ayudar a hacer testing.
Mocha es una de ellas, es un framework para hacer justamente testing,
que te viene con algunas utilidades.
Es una de las más usadas, pero seguramente actualmente ya no es tan usada.
Digamos que era la más usada, pero ha aparecido una
que le ha quitado la corona a día de hoy.
Seguramente todavía hay más proyectos con Mocha que con la otra,
que vamos a ver, pero si ahora mismo tienes que empezar un test,
seguramente no empezarías con Mocha.
Se parece mucho, así que tampoco tendrás ningún problema.
Otra opción sería Ava.
Ava es un test runner, también un framework para hacer testing,
que es muy rápido, muy interesante, pero no lo vamos a ver hoy.
Pero bueno, te los digo más que nada por si te animas,
pues que sepas que existen y que les eches un vistazo.
Ava está muy bien.
Vi hace poco una charla sobre Ava y la verdad es que me gustó mucho.
Además en el equipo está Cindy Sorhus, que si no lo conoces,
está en un montón de proyectos en Node que, vamos,
seguro que alguno has tenido que utilizar, aunque sea sin querer.
Así que bueno, es imposible no haber usado algún paquete
o dependencia de este hombre.
Y finalmente, un test runner, un framework para hacer testing,
de Facebook, que aunque estaba pensado especialmente para hacer
testing más en el navegador, en la parte del cliente,
poco a poco ha ido evolucionando de forma que también se puede utilizar
sin ningún tipo de problema en la parte del servidor.
De hecho, puede ser que veáis en algunos sitios,
de hecho, en Mongoose hablan de esto y dicen de
oye, que Jest no está muy bien pensado para hacer testing en el servidor.
Y bueno, yo creo que eso es una cosa más histórica.
Lo digo para que lo entiendas, que muchas veces cuando hablan de eso,
en realidad es porque históricamente estaba más pensado
para la parte del cliente, tenía justamente esta funcionalidad
de snapshots, que lo que te permitían era como ver
qué HTML en ese momento se había generado
y luego comparar en un momento que habías generado este snapshot
con los cambios que has hecho en tu aplicación,
si ese snapshot se seguía creando exactamente igual.
Pero bueno, vamos a ver que por fin
Jest funciona perfectamente para testing en servidor.
Y de hecho, este va a ser nuestro telrunner que vamos a utilizar.
Se parece mucho a Mocha, así que si vienes de Mocha no te preocupes
y si no sabes Mocha, pues que sepas que aprendiendo Jest
no te va a costar absolutamente nada pasar.
Vamos a instalar Jest.
Vamos a nuestro proyecto y aquí vamos a hacer un npm install.
Jest e importante, Jest, como es para el test,
lo que vamos a hacer es que sea para una dependencia de desarrollo.
Así que ponemos el save dev o ponemos la mayúscula D
y ahí lo dejamos.
Vale, cosas importantes con Jest.
Jest la verdad es que a veces es un poco tricky.
Es un poco tricky.
Y por ejemplo en Windows sé que existe un problema
en el que si tu carpeta tiene espacios,
puede no funcionar correctamente.
Nosotros estamos en Mac, en un sistema Unix y tal,
no vamos a tener ningún problema.
Pero si estás en Windows, yo que sé,
hay veces que estás en una carpeta donde está tu nombre del usuario,
¿vale? Yo que sé.
Y te llamas Miguel Ángel y estás separado por espacios.
Que sepas que te puede dar problemas, ¿vale?
Otra cosa importante.
Esto es un proyecto que es de Node.
Y como te he dicho, por defecto,
Jest está pensado para trabajar en el cliente.
Esto lo que hace es que puede simular cosas del DOM.
Y nosotros esas cosas no las necesitamos
y de hecho pueden ser problemáticas.
Así que en nuestro package.json
vamos a añadir una configuración que se llama Jest
y le vamos a decir que el entorno
en el que vamos a ejecutar nuestros test,
environment, es Node.
De esta forma, así lo he escrito bien,
test environment, ¿vale?
Que si no luego tenemos problemas.
Le estamos diciendo que nuestro entorno va a ser Node.
No va a ser por defecto que es el cliente.
Esto lo podríamos crear aquí en el package.json.
Hay gente que puede crear aquí un jest.config.js,
como prefieras.
A mí me gusta normalmente cuanto menos archivos creo, mejor.
Por eso tengo la config de Slyn la tengo aquí,
la de Jest.
Me gusta tenerlo todo en el package.json.
Fácil de encontrar y perfecto.
¿Qué más?
Pues vamos a crear nuestro primer test.
Por defecto, Jest lo que hace es buscar todos los archivos
que tengan el punto test.js.
Así que lo que vamos a hacer es ya crear aquí
palíndrome.test.js
y aquí vamos a generar nuestros test de Jest.
Lo primero que tenemos que hacer no es importar Jest,
no es necesario,
porque Jest una vez que encuentre este archivo
pues ya detectará perfectamente
que tiene que ejecutarse y la dependencia que tiene que utilizar
y todo esto.
No tenemos que importar Jest ni nada.
Pero sí que tenemos que importar, obviamente,
el método que queremos comprobar, ¿no?
Palíndrome.
Palíndrome.
Así que vamos a hacer un require
y buscamos en utils
y buscamos el for testing
que es el archivo que he creado antes.
Ahora, hay diferentes formas aquí de crear un test, ¿no?
Antes hemos visto el console.assert.
Ahora aquí vamos a verlo de una forma diferente.
Lo que vamos a hacer es utilizar por ahora el test.
Se llama test, ¿vale?
El problema que normalmente tiene Visual Studio Code
es que como no tienes aquí,
no sabe que quieras hacer un test, ¿vale?
Test.
¿Veis que aquí pone que test is not defined?
Eso lo arreglaremos después,
pero el inter se nos va a quejar.
Ahora vamos poco a poco.
Primero vamos a escribir nuestro test.
¿Cómo se describe un test?
Primero se le dice qué es lo que hace este test.
Vamos a decir, palíndrome of midude.
Y ahora veremos justamente qué es un palíndromo
y cuál sería el palíndromo de midude.
Es súper interesante el tema de los tests.
Es súper interesante porque vas a ver que los tests
no solo sirven para un tema de saber
si funciona o no nuestro método,
sino que también es una forma de documentar nuestros métodos.
Si una persona no sabe exactamente qué hace un método
y va justamente a los tests,
va a entender fácilmente qué es lo que está haciendo nuestro método, ¿vale?
De esta forma, pues ya no tendrás que documentarlo tanto,
sino que los tests te pueden servir de documentación en sí misma.
Muy bien.
Entonces, ¿cuál es el palíndromo de midudev?
Pues vamos a ver el resultado del palíndromo de midudev.
Aquí tendríamos el resultado, ¿no?
El resultado.
Palíndrome nos devuelve un string
y aquí tendríamos el resultado.
¿Qué hacemos con este resultado?
Pues hacemos la aserción que hemos visto antes.
Esperamos que el resultado tenga un valor
y el valor que va a tener que hacer, pues sería...
A ver si lo pongo bien.
Ed, U, D, I, M.
¿Vale?
Sería midudev al revés, básicamente.
Vamos a guardar los cambios
y puedes ver que se me queja el linter.
Me dice, oye, el test y el spec.
El test y el spec vienen de Jest, ¿vale?
Esto es parte de su documentación y de su API.
Lo que estamos diciendo aquí, esto,
estamos creando un test
y aquí lo que estamos diciendo,
una vez que tenemos este es el test,
este callback que tenemos aquí,
es la función que va a ejecutar
para comprobar el test
que le estamos indicando aquí,
que nos va a ayudar luego justamente
a la lista de testing
para ver si pasa o no.
Y lo que decimos aquí, vale,
espero que este resultado,
el que hemos guardado aquí,
sea este, ¿ok?
Pero claro, ya te digo,
test y spec no lo detecta.
Para solucionar esto,
lo que tenemos que hacer es,
en SlimConfig,
que puede ser que lo tengas aquí,
puede ser que lo tengas en otro sitio,
donde sea que lo tengas, ¿vale?
Pues lo que tienes que hacer aquí
es añadir la key env para de entorno
y lo que vamos a hacer aquí,
sería decirle que es just true.
Aquí en env, al final,
lo que puedes tener es un montón de entornos,
puede ser mocha,
puede ser que si es en navegador,
porque el window, por ejemplo,
tiene métodos globales también.
Aquí lo que te está diciendo
es una configuración que ya tienes,
Slim,
que sepas que estoy usando just
y que, por lo tanto,
estos errores no me los des
porque ya los tengo controlados, ¿vale?
Y ves que me han desaparecido,
ya no se queja de esto.
¿Cómo podemos ejecutar el test?
Podríamos empezar a ir a node modules,
cómo lo ejecutamos y tal,
pero en las anteriores clases
ya hemos visto
cómo se tienen que hacer bien estas cosas, ¿no?
Así que nos vamos aquí a test
y lo que vamos a hacer aquí
es poner just
y vamos a utilizar el flag de verbose,
que esto es lo que significa es verboso,
es que nos va a dar
la máxima información posible.
Así que si nos da algún error,
de esta forma nos ayudará,
ahora que estamos empezando,
a determinar dónde está el problema, ¿vale?
Entonces ya tenemos un script
que es para hacer testing,
ya tenemos nuestros primeros tests,
vamos a ver si esto funciona.
Empiezo en run test
y ha pasado.
Vale, esto está bien,
pero también está mal.
Así nos empiezan los tests.
¿Por qué nos empiezan así los tests?
Porque ahora, vale,
parece que nuestro test pasa,
pero no estamos seguros
si realmente el test que hemos hecho
pasaría siempre, ¿vale?
En este caso ya sabemos que no,
pero es interesante siempre
ver que tu test falla,
al menos una vez,
al menos al principio.
Por ejemplo,
si ponemos aquí un string vacío,
pues ver que el test realmente está en rojo
y que si le pongo el valor
que yo estoy esperando,
realmente da lo que yo quiero, ¿vale?
¿Ves?
Me dice,
oye,
tú decías,
esperabas esto,
pero yo he recibido esto.
¿Veis?
Aquí está la información que os digo
que va a ser súper útil,
que nos va a dar jest
y que no nos estaba dando el console assert.
Así que,
ahora que ya sabemos esto,
pues podemos poner el string
que sí que estábamos esperando.
Ahora que también tenemos nuestros test,
pues podemos probar
esos corner cases que decíamos,
¿no?
¿Qué pasa si a palíndrome
pues le pasamos un empty string?
Vamos a ver cómo se comporta.
Estos,
también los tests te pueden ayudar a esto.
¿Por qué?
Porque normalmente en tu aplicación
quizás no eres consciente
de una forma más global
de cómo se pueden utilizar
los tests unitarios
que tenemos dentro.
Y aquí lo que estamos haciendo
justamente es comprobar
una funcionalidad en concreto.
Luego iremos viendo
los tipos de tests
que pueden haber
a lo largo del bootcamp.
Vamos a ir viendo más.
Pero aquí lo que estamos probando
es un método en concreto
para ver lo que hace.
Esto es lo que se llama
un test unitario
porque estamos probando
una unidad,
un método en concreto.
Una cosa en concreto
que sabemos que tiene
una entrada y una salida
y dentro no tiene side effects
ni llama a otras funciones
ni nada.
O sea que está bastante acotado
lo que estamos probando.
Así que vamos a probar
el palíndrome.
¿Qué pasa?
Si le pasamos un string vacío.
Palíndrome de un string vacío.
¿Qué es lo que esperaríamos?
Pues aquí viene un poco
lo que te comentaba.
Que aquí sí
puede ser un string vacío
pero a lo mejor
alguien me dice
no, es que esto
debería ser false
porque en realidad
un palíndromo
cuando es un string vacío
realmente el string vacío
también es el palíndromo.
En este caso
si ponemos un string vacío
esto debería funcionar bien.
Funciona bien.
Pero aquí está bien
porque nos está sirviendo
también otra vez
de documentación.
¿Qué pasa realmente
si tenemos un string vacío?
Pues alguien
lo puede chequear aquí fácilmente.
Si no, puede tener dudas.
Y decir bueno
pero ¿cuál es el caso
si pasa esto?
¿Qué debería ocurrir?
Otro caso.
¿Qué pasa si no se le pasa nada?
Un palíndrome de undefined.
Si no le pasó aquí nada
¿qué esperaríais que fuese aquí?
¿Un string vacío también?
Bueno, yo al menos
esperaría primero
que no petase.
Así que vamos a probar el test
y vamos a ver
que está habiendo un error.
Ni siquiera me está diciendo
que está esperando
un valor en concreto
sino que es que está petando.
Está petando.
Me dice que no puede leer
la propiedad split de undefined.
Ya hemos encontrado
un corner case de nuestro método.
Parece ser que cuando
no le pasamos nada
peta.
Pues esto no lo tenemos controlado
y es un caso de uso
que podría ocurrir.
Aquí hay diferentes formas
y esto digamos
que sería una decisión ahora
que tendrías que tener
con tu método.
Este método
este no
el de utils
este método
que es este string
podríamos decir
vale
si el tipo
del string
es undefined
pues entonces
voy a devolver
un string vacío
o alguien puede decir
no
vas a devolver
un undefined también.
Bueno
podría tener sentido
que fuese un undefined.
Así que lo que podemos decir
es que si
si esperamos este resultado
utilizamos estos métodos
que esto también viene
justamente de jest
tendríamos el to be
que es para decirle
a lo que
cuál sería el valor que tiene
pero tienes un montón.
Tendríamos aquí
el to be undefined
por ejemplo.
Ahora todos estos métodos
no te los tienes que saber
de memoria
y de hecho
creo que hay extensiones
que te pueden ayudar
pero si no
en la API
tienes un montón
a ver si sale por aquí
to be
spec
mira
API reference
spec
aquí tenemos todos los métodos
el to be
es el más evidente
es el más claro
que al final lo que esperas
es que
esperas que un resultado
sea de un valor
tenga un valor en concreto
y aquí puedes ver
un montón de ejemplos
pero aquí hay un montón
un montón
puedes utilizar el to equal
también
que al final
es muy similar
al otro
lo que pasa es que
tiene diferencias
respecto a los objetos
pero el to be
yo creo que se puede entender mejor
de hecho tienes también
como estos short hands
no hace falta que hagas
to be
de paréntesis null
sino que puedes utilizar
directamente
to be null
igual que voy a utilizar
ahora el to be undefined
de esto
de esta forma
es un poquito más legible
tu test
así que esto es lo que voy a esperar
yo ¿vale?
voy a esperar
que si digo que el palindrome
es undefined
pues voy a devolver
undefined
aquí podrías hacer
que tuviese un error
lo que sea
por simplificar
vamos a dejarlo así
vamos a probar otra vez
y ahora sí que está pasando
nuestro test
bueno pues ahora que sabemos esto
vamos con los test del average
vamos a poner
average.test.js
pero aquí lo vamos a hacer
un poquito distinto
porque sí que vamos a importar
el average
vamos
de utils
igual
utils
for testing
tenemos el average
pero ahora no vamos a utilizar
directamente el método
test
que hemos utilizado antes
¿por qué?
porque hemos visto que bueno
test está bien
pero me van saliendo aquí
todos los test
me dice el palindromo
de midudev
este de esto
esto de lo otro
y se puede hacer un poco difícil
a la hora de leer
cómo van los test
¿no?
sí que está bien
no está mal
pero conforme van creciendo
se pueden ir mezclando
y es difícil de leer
entonces hay que agrupar
y para agrupar
se utiliza el describe
que es una forma
de describir
como un contexto
o una situación en común
que tienen todos los test
que vas a utilizar
en este caso
uno muy sencillo
sería decir
average
solo para no tener que repetir
average
average
como hemos hecho aquí
¿no?
palíndrome
palíndrome
lo hemos tenido que hacer aquí
todo el rato
palíndrome de tal
palíndrome de tal
en este caso
así podemos agruparlos
en este contexto
average
y aquí le tenemos que pasar
un callback
dentro de este callback
es donde vamos a ejecutar
todos los test
entonces podemos decirle
otra vez
esto es el Visual Studio Code
que como no detecta
que quiero utilizar
jest
no encuentra el método
y cuando hace otro complete
se vuelve loco
por ejemplo
un valor
si le pasamos un valor
pues es el mismo valor
sería la media
¿no?
así que esperamos
que si ejecutamos
average
y le pasamos
un array
con uno
podremos hacer
que esto
debe ser uno
esto sería así
por ejemplo
podemos pasar
ya los test
rápidamente
y fíjate la diferencia
¿no?
palíndrome
aquí me han salido
todos juntitos
y aquí me dice
average
de un value
no sé qué
no sé cuánto
vale
pues ya vemos
esto es lo mismo
deberíamos hacer
lo que pasa
que para ir rápido
no lo vamos a hacer
así que pete todo el rato
pero deberías ver
que peten
¿vale?
que vayas viendo
cómo van petando
y tal
vamos repitiendo
porque así
vamos a ir viendo
más casos
2, 3, 4, 5
y 6
la media de estos
pues esto sería
3 y medio
y tenemos que poner
of many
is calculated
correct
el average
se leería así
¿no?
el average
de unos cuantos
es calculado
correctamente
voy a añadir otro
y luego así
los pasaremos todos
¿no?
y aquí vamos a poner
otro corner case
¿qué pasa si
se le pasa
un empty array?
pues vamos a decir
que si le pasamos
un empty array
la media sea 0
así que vamos a añadir
aquí el empty array
y vamos a decir
que esto debería ser 0
venga
vamos a pasar los test
rápidamente
ya han petado
ya han petado
ya han petado
algo pachado
vale
pues fíjate ¿no?
que dice
que esperaba 0
y ha recibido
none
not a number
pues esto es porque
justamente seguro
que en nuestro
for testing
¿qué pasa aquí?
que el array este
que tiene una longitud
de 0
0 dividido entre 0
explosión del mundo
¿vale?
porque no se puede
dividir entre 0
así que bueno
aquí lo mismo
puedes decidir
lo que tú quieras
pero al menos
ya estamos controlando
mejor los corner cases
¿no?
ya estamos viendo
que nuestro método
que parecía
muy sencillo
en realidad
no está controlando
del todo
algunos corner cases
y para esto
nos está ayudando
el testing
¿qué podríamos hacer aquí?
bueno pues si el array
en la longitud
es 0
pues devolvemos
que sea 0
ahora podríamos
volver a añadir
otro test
¿no?
bueno voy a pasar
el test
a ver si funciona
correctamente
pasa correctamente
pero ahora
¿qué pasaría?
que le podrías pasar
un define
y esto también petaría
bueno pues esto
te lo dejo
como un ejercicio
para que le eches
un vistazo
por tu parte
¿vale?
bueno ya tenemos aquí
lo primero de testing
que hemos hecho
perfecto
ahora lo que vamos a hacer
para continuar
es hacer el testing
del backend
ya veréis que ahora
se nos va a empezar
a complicar un poco
la cosa
ya no va a ser tan sencillo
como lo teníamos antes
¿vale?
ya va a empezar
un poco a subir
¿vale?
pero