Lo que más me llamó la atención cuando empecé a estudiar programación fue la inmensidad de este mundillo: siempre hay algo que estudiar o probar, alguna librería o tecnología que no conocías y que te parece una fantasía del futuro.
Ahora mismo me parece imposible aburrirse o cansarse del desarrollo, y cada vez que estoy un rato viendo posts en dev.to, o la pestaña de trending de Codepen, o incluso Twitter, me reafirmo en que la información del mundo tech es tremendamente adictiva. No puedo contar las veces que he empezado leyendo un tweet del que no entendía la mitad y eso me ha llevado a dos o tres horas de investigación concatenada saltando de una página a otra buscando conceptos que me van apareciendo y de los que, hasta ese momento, no tenía ni idea.
Releyendo el párrafo anterior me veo obligada a hacer un disclaimer, ya que yo estoy totalmente en contra de romanticismos absurdos e innecesarios, y la verdad es que todo eso que he contado me pasa solo cuando tengo un buen día: cuando tengo un buen día abro una cosa y otra y voy estudiando, investigando, aprendiendo y me lo paso pirata, y si quisiera pasarme la vida así tendría contenidos para hacerlo. Pero no podemos contar con que todos los días van a ser buenos (yo al menos no), y los días malos esa misma inmensidad del mundo tech me resulta abrumadora y me deja sentada en la silla mirando a la pantalla sin saber muy bien a qué echarle mano.
Así que hace un par de semanas me hice un roadmap (que aunque suena como una cosa muy complicada, es simplemente apuntarte en algún sitio una lista de los lenguajes, tecnologías, librerías, etc que quieres aprender, por el orden en el que tiene sentido aprenderlos). Considero a mi roadmap un ente dinámico y en constante modificación, donde es posible cualquier variación sobre el camino inicialmente establecido, siempre y cuando tenga sentido (era la única forma de conseguir hacer una lista de cosas sin volverme loca pensando en qué me estaba dejando fuera).
¿Y por qué cuento todo esto que no tiene nada que ver con nada? Pues porque no fue hasta que hice este roadmap que me di cuenta de que no le estaba dejando lugar a aprender testing, lo cual resulta increíble con las veces al día que escucho o leo a alguien recordar las bondades e importancia de los tests. Si bien es cierto que aprendí a hacer test unitarios con Jest en el bootcamp, cuando estás aprendiendo muchas cosas nuevas reconoces a la perfección cuando manejas algo "bien bien" o "más bien no", y yo soy plenamente consciente de que en Jest en concreto y testing en general soy un "más bien no".
Así que había llegado el momento, y este lunes por fin abrí de nuevo la documentación de Jest. Después de eso decidí que necesitaba amenizarme un poco la existencia y que entrar así a palo con una documentación igual no era lo mejor para coger el tema con cariño, así que recurrí a quien considero mi niñera, profesor y mejor amigo: Youtube. Creo que no le descubro nada a nadie con los vídeos que me han parecido interesantes y me han ayudado a dar un contexto general previo muy sólido, pero igualmente los dejaré linkados al final del post por si a alguien le fueran de utilidad.
Mi principio: Test unitarios
Igual que me pasa con el mundillo Tech en general, el mundillo testing me parece inmenso para abordarlo. Como por algún sitio hay que empezar, yo he decidido empezar por el principio, y esta semana me he dedicado a aprender "Tests unitarios con Jest en JavaScript vanilla" (que suena un poco como cuando mi madre me presenta a alguien, que dice que soy su hija "Marta, la pequeña, que vive en Madrid pero está aquí un par de días de visita" y siempre me siento como con un apellido muy largo, como si fuera yo de la nobleza o algo).
Total, que allí me puse. Después de una mañana viendo y leyendo información me animé a empezar a intentarlo por mi cuenta: abrí un repositorio que tengo con todos los challenges que voy haciendo en Hackerrank y empecé a hacerle tests a todos (que son unos cuantos).
De mi aventura con los tests unitarios con Jest en JavaScript vanilla saco los siguientes aprendizajes y conclusiones:
- La instalación es súper sencilla y únicamente hay que añadir al package.json, en los scripts, la siguiente configuración: "test": "jest"; y otro objeto llamado "jest" al que le indicaremos la clave "testEnvironment" y el valor "node" (parecerá absurdo pero a mí solo la instalación de según qué cosas se me hace una bola gigante).
- Hay diferentes modos de organizar los ficheros de funcionalidades y los de test, pero la que me parece más fácil y práctica es mantener los ficheros de test al lado del los ficheros que testean.
- Los ficheros donde vayamos a hacer test deben usar la extensión .test.js para que Jest los reconozca al arrancarlo.
- La función o funciones a testear deben exportarse de su fichero mediante module.exports = {}. Indicando dentro las funciones a exportar.
-
La función o funciones a testear deben importarse en el fichero de test guardándolas en una constante con require:
Los test son también una forma de documentar, ya que muestran a la perfección lo que deben hacer los métodos.
El test siempre tiene que fallar primero para saber que está bien construido y que puede fallar, de lo contrario no podremos saber si no nos da fallo porque ha pasado correctamente o porque no está funcionando como esperado.
-
Para crear un test unitario de la forma más sencilla únicamente tendremos que utilizar el método test() con dos argumentos: el primero será la descripción de lo que hace el test, lo indicaremos como un string entre comillas; el segundo es una función donde estará el test en sí, y donde utilizaremos la constante donde anteriormente hemos guardado la función importada:
En la mayoría de casos yo he utilizado el método expect() para crear el test, aunque existen muchos otros que pueden ser más ajustados a las necesidades concretas y se listan aquí: https://jestjs.io/docs/expect
El método expect() recibe como parámetro la función a testear. Posterior a expect debemos usar un matcher, que es otro método que recibe la validación a realizar. En mi caso particular he intentado utilizar y probar todos los matchers que he podido, aunque considero que en la mayoría de las ocasiones podría haberme limitado a usar el .toBe (han sido muchos tests, de alguna forma tenía que mantener viva la llama entre Jest y yo).
Según el tipo de dato que tengamos que validar podremos usar ciertos matchers, en la documentación está indicado pero además la propia consola te sugiere el matcher a utilizar cuando has usado uno que no podías.
Jest tiene un watch mode muy útil que me ha hecho muy feliz: jest --watchAll
Existen las funciones mockeadas, que son funciones espía medio fake que creamos cuando necesitamos que ésta nos "chive" exactamente cuándo y cómo se le está llamando.
Y esta ha sido la primera de (preveo) varias semanas con testing. Cualquier feedback (si es con amor o gatos) es bienvenido :)
Recursos:
- Documentación: https://jestjs.io/
- @midudev https://www.youtube.com/watch?v=_DzBez4qMi0&t=594s
- @maxedapps https://www.youtube.com/watch?v=r9HdJ8P6GQI
- Repositorio donde están mis retos de Hackerrank por si le es útil a alguien para practicar: https://github.com/martreyz/hackerrank_challenges
Top comments (4)
Buah Marta, me haces super feliz con este post... justo esta semana me ha tocado investigar un poco el tema del testing por el curro, que ya le tenía ganas de hace mucho pero mira, nunca le llegó el momento hasta ahora porque como tú dices... HAY TANTO, que parece que nunca llego a todo lo que quiero. Y tonterías como la configuración inicial, a mi que con node aún voy dando palos de ciego, se me hizo un mundo jajaja, así que me guardo tu post y todos los enlaces para ponerlo todo en práctica :D
Carmen muchas gracias!!! cómo me alegro de que te sirva :) estamos en este camino loco juntas!!! ánimo ahí! :)
Genial Marta. Y gracias por la mención. 🤗
Gracias a ti por salvar mi vida cada día! Jaja 🤗🙃