DEV Community: Marta Rey

Snippets VSCode: Rapidito y con buena letra.

Marta Rey — Wed, 29 Dec 2021 13:20:26 +0000

Hace menos de un mes fue mi primer aniversario como programadora Front End, o hizo un año que acabé el bootcamp... Como quieras verlo. El tema de poner fechas de aniversarios ya se sabe... siempre hay discordia y no se sabe muy bien desde qué punto empezar a contar, pero a mí me gusta escoger un día de referencia siempre para todo, y repasar días mentalmente de vez en cuando para ir memorizando poco a poco un montón de fechas! (ya, no estoy bien, pero tampoco hago daño a nadie).

Total, que me he dado cuenta de que durante este año así a lo tonto he conocido a un montón de personas que programan (entre cursos y proyectitos y trabajo y chacharetas así en general...) y creo que a estas alturas tengo suficiente información para aseverar que en desarrollo cada persona tiene su súper poder: están las Súper Detallistas (que enganchan una docu y la exprimen hasta el último punto y coma), las Súper Recordadoras (que no necesitaría fechas en los commits porque sabe siempre qué se hizo dónde y por qué), las Súper Resolutivas (que siempre tienen un pseudo-elemento en la manga),... Y yo creo que ya veis por donde voy. Pues bien, yo creo que soy un poco de las Súper Rapiditas (que a priori parece que muy bien pero luego tienes un día un poco tonto y escribes cosas como “error.massage” y te quedas tan ancha y luego no sabes qué pasa y todo mal). Y es que al final todo gran poder conlleva una gran responsabilidad, y yo creo que la de cada Súper Dev es tranquilizar un poquito sus instintos e intentar encontrar el equilibrio perfecto.

Vamos, que si tienes muchísima atención por el detalle está genial, pero tienes que intentar no perderte en tus lecturas e investigaciones, y si tienes muchos recursos tienes que intentar no acabar haciendo un código que solo tú entiendes... y si a veces se te va un poquito la mano con las prisas tienes que intentar hacer las cosas con más calma y centrarte más en el detalle. O así lo veo yo, que al final es lo que viene a cuento que para eso estoy escribiendo yo (como con la radio del coche el que conduce).

En definitiva! A ver si me centro que no me centro. Que hace unos meses que estoy muy interesada en herramientas que me ayuden a eso, a afinar mejor, sea como sea la ayuda: el linter, por ejemplo, me ayuda porque me enseña mis errores en el momento y me obliga a parar a revisar, los tests me ayudan porque me obligan a refactorizar mi código para facilitar la tarea, y por tanto a revisar el código tal y como termino de escribirlo... (tengo algunos truquillos caseros también, por qué no decirlo). Pero hay una en concreto que nunca hubiera dicho que me fuera a ayudar, y resulta ser que sí, y son los Snippets de código.

Y estarás pensando “Amiga, los snippets de código no te ayudan a escribir mejor código, escriben código por ti” y sí, efectivamente, pero a la vez no, porque el código que escriben los snippets es la “paja”, el código repetitivo. Y esto me lleva a los motivos por los que en efecto, me ayuda:

Como decía, los snippets sirven para “automatizar” la escritura de código repetitivo, donde los errores suelen ser: “no he visto que me faltaba un corchete”, “no he visto que me faltaba ese paréntesis” o “ostras, la coma”. Es decir, no es que pienses que la flecha de una arrow function se escribe así =< , es que estabas mojando la galleta en el colacao y has soltado el shift antes de tiempo, y evitar esos errores evita mucha frustración y deja muy limpita la cabeza para pensar y razonar.
Al automatizar esas construcciones dedico menos tiempo a pensar en tareas repetitivas y dedico tiempo de calidad al resto del código.

En fin, que los Snippets son mis nuevos mejores amigos.

Crear un snippet es muy sencillo, al menos en VS Code (y me da a mí por pensar que en todos los IDE será igual de fácil): únicamente tenemos que hacer click en settings y seleccionar “User Snippets”:

Se abrirá arriba un cuadro de opciones de la que elegiremos la que más nos convenga (si es la primera vez tendrás que crear un nuevo archivo global como se indica en la imagen, en caso contrario puedes elegir de la lista de los archivos existentes el que quieres modificar:

También nos da la opción de configurar los snippets a nivel proyecto.

Una vez seleccionada la opción (si hemos elegido crear un nuevo archivo nos preguntará el nombre que le queremos dar), accederemos al archivo .json donde configuraremos nuestros snippets siguiendo la siguiente estructura:

"Nombre del snippet": {
    "scope": El ámbito al que pertenece el snippet (para que se muestren únicamente los relevantes a cada caso). Pueden ser lenguajes o 
proyectos,
    "prefix": La palabra con la que llamaremos al snippet desde el código,
    "body": [ Una o varias líneas de código que queremos que se inserte de forma automática. Tiene formato array de strings, donde cada
string es una línea de código. En el ejemplo a continuación se insertaría un console.log de un string, el $1 indica que el cursor se 
posicionará en ese punto en primera instancia, y el $2 será a donde iremos haciendo el primer tab. De esta forma al meter el snippet nos 
situará automáticamente en el punto donde incluir la variable del mismo (la palabra a consolear).
        "console.log('$1');",
        "$2"
    ],
    "description": Descripción opcional para mostrar cuando se introduzca el prefix en el código, para identificar la utilidad de cada uno 
de los snippets que se muestran.
 }

Si es la primera vez que oyes hablar de los snippets seguramente ahora mismo estés pensando la cantidad de estructuras que vas a crear y lo bonita que va a ser tu vida a partir de ahora, pero espera, porque todavía no conoces toda tu suerte.

Resulta que esa es la opción “difícil”, la de súper pro, la de “se me ha ocurrido una cosa que no se le ha ocurrido a nadie antes y que no se le ocurre más que a un genio” (yo todavía no he tenido que crear ninguno, así un poco para probarlo y tal... poco más). Para lo que es el día a día, para empezar a usarlo ya mismo, no he tenido que montar ni un snippet porque como suele ocurrir en este mundillo... ya lo ha hecho alguien.

Y es que, a parte de los Snippets que trae el propio VS Code (se consultan haciendo ctrl+shift+p para abrir la Paleta de Comandos y seleccionando “Insert Snippet”), existen un montón de extensiones del marketplace que te proveen con un montón dependiendo del lenguaje que quieras que sea SNIPPEADO (es tarde ya y empiezo a perder un poco el pie):

JavaScript Snippet Pack:

HTML Snippets:

Bootstrap 4 CDN Snippet:

React:

Y un montón más que se pueden consultar en el MarketPlace del VS Code y que me tienen loca.

Y creo que hasta aquí mi Oda a los Snippets... Como siempre cualquier feedback (si es con amor o gatos) es bien recibido.

Referencias:

Sé más de testing que ayer (Episodio 3: los matchers más guays de Jest)

Marta Rey — Wed, 01 Sep 2021 17:27:55 +0000

Cuando decidí empezar a aprender a estudiar testing por mi cuenta tuve que pasar muy por encima algunas cosas para ser capaz de darle un "concepto general" a lo que estaba aprendiendo. Como creo que ya conté en anteriores episodios de "Sé más de testing que ayer" (muy Troy McLure me ha quedado), cuando por fin me hice una idea general y ya tenía la documentación más o menos ubicada (yo es que antes de que una documentación me sea útil necesito un proceso de adaptación) me puse a hacer testing de forma, se podría decir, obsesiva.

Desde que supe montar mi primer test, empecé a incluir testing en las pruebas técnicas que hacía, y en mis ratos libres hice los tests de una buena parte del repositorio que uso para resolver retos de Hackerrank. A medida que avanzaba haciendo test a diferentes funciones y aplicaciones me daba cuenta que los matchers tienen mucho más protagonismo e importancia de la que yo me había imaginado en un principio.

Entiendo que es una evolución normal, pasar de creer que "toBe" vale para todo, a saber que hay ocasiones en el que no lo puedes usar, a darte cuenta de que sin variar y bucear un poco en los matchers existentes no vas a poder sacarle el máximo partido a Jest, pero a mí me lo tuvieron que contar, la verdad.

Han pasado aproximadamente tres meses de la última vez que escribí sobre mis avances con los test unitarios en Jest y creo que ha llegado el momento de recopilar los matchers que me resultan más guays y útiles. Jest y yo hemos pasado por mucho juntos y nos lo merecemos.

Matchers básicos: Para una función básica donde tengamos unos parámetros, una operación y un return, usaremos estos matchers. Es una forma de decir “espero que si le mando estos datos a esta función me devuelva esto otro”. Como veremos a continuación, dependiendo del tipo de dato que devuelva la función podremos usar uno u otro:

toBe: comprueba una igualdad entre strings o números ( expect(2+2).toBe(4);). Se puede utilizar not.toBe si queremos negar una igualdad.

Con array y objetos sólo devolverá true cuando lo comparemos consigo mismo, en caso contrario aunque todas las propiedades sean iguales devolverá false.

toEqual: Es el matcher adecuado para comprobar la igualdad en un objeto o array utilizaremos toEqual, ya que verificará y comparara los campos uno a uno. Podremos utilizar not.toEqual si queremos negar la igualdad.

Pues con esos dos matchers era que yo resolvía todos los problemas de testing que me iban surgiendo, hasta que un día una idea llegó a mí: “cuanta más información de lo que estás probando le des tú a Jest, más información te va a devolver él en caso de fallo”. Y ojo esto es importante, porque en cuanto empiezas a testear proyectos más grandes con funciones más diversas te das cuenta de que, o construyes una relación de respeto con Jest, o te va a amargar la existencia día a día y sin ningún remordimiento.

Total, que hay momentos en los que dices “si es que yo no quiero comparar lo que devuelve esto, yo solo quiero saber que devuelve algo, o que no”. Pues claro, y muy lógico, y para eso hay un puñado de matchers que se denominan “de veracidad” y que se encargan de verificar a null, undefined, truthy o falsy. De este modo, si como veíamos en los primeros ejemplos, quisiéramos testear que una función devuelve algo simplemente podremos usar .not.toBeUndefined(), por ejemplo.

Del mismo modo podríamos validar si una función ha sido llamada con .toHaveBeenCalled();

Por otro lado, en lo referente a los números, aunque lo más habitual será usar el toBe o toEqual del principio, puede que yo tenga una función que genera números aleatorios del 1 al 10, y que quiera verificar que el resultado siempre está por debajo de 10 y por encima de 1, pues bien en ese caso tenemos un grupete de matchers que nos pueden ayudar como .toBeGreaterThanOrEqual() y .toBeLessThanOrEqual().

Y también nos ocurrirá que tengamos que comprobar si un objeto o array tiene cierta propiedad o valor, pero no queramos comprobar la igualdad del array completo como haríamos con .toEqual(). Para esto podremos usar .toContain() (para valores en caso de arrays), .toMatchObject()(para clave-valor en caso de objetos), o .toHaveProperty() en el caso de que queramos verificar si existe una propiedad, independientemente de su valor.

Del mismo modo, podríamos corroborar si algo es instancia de una clase con .toBeInstanceOf().

En cuanto a los strings, podremos usar .toMatch() para verificar una igualdad parcial o incluso una expresión Regex (de las cuales por cierto me está llegando ya la hora de aprender algo y son firmes voluntarias para aparecer en un post próximamente).

Por último, habrá ocasiones en las que tengamos que trabajar con una excepción, ya que el test cubre algún caso en el que se genera un error y lo queremos testear también. En estas ocasiones usaremos .toThrow(), o .toThrowError() si queremos validar el mensaje concreto que devolverá la excepción. Al respecto de estos dos matchers es importante indicar que el código de prueba deberá estar metido en una función, de lo contrario el test fallará y no llegará a validar el error. Esto lo podremos hacer creando una función y utilizándola luego en el expect, o introducir el código directamente en una arrow function dentro del expect.

Como esto es lo típico que leerlo muy bien pero luego no te acuerdas y cuando lo necesitas tienes que volverlo a mirar todo desde cero… (y como soy una gran amante de las cheat sheets) dejo a continuación un esquemita resumen así como de mi cosecha por si a alguien le fuera remotamente útil :)

Como siempre, cualquier comentario, si es con amor o gatos, es bien recibido.

Sé más de testing que ayer (Episodio 2: Testeando el DOM y con la asincronía hemos topao')

Marta Rey — Fri, 21 May 2021 18:52:54 +0000

Si, como yo, eres desarrollador/a junior sin experiencia, tengo buenas noticias para ti: el mercado laboral para nosotras por fin se activa después de muchos meses de frustración y pocas oportunidades. Si, como yo, ya te habías dado cuenta, supongo que entenderás ese sentimiento de: ¿A dónde ha ido a parar todo el tiempo que yo tenía para leer y estudiar?

Y es que no es solo el tiempo que invertimos en hacer las pruebas/tests/entrevistas propias de los procesos de selección, es todo el tiempo a mayores que dedicas a desgastar el botón de actualizar del email y estar súper nerviosa por tu futuro inmediato (porque digan lo que digan todos nos ponemos un poco nerviosos en esos momentos, y ponerse nervioso también lleva su tiempo y ocupa su espacio en la vida).

¿Que todo esto que estoy diciendo parecen excusas para acabar diciendo que he dejado lo del testing? Correcto, pero no es el caso. ¿Que entonces para qué lo cuento? Pues porque hablo mucho y la síntesis no es lo mío y tal.

Centrándome en lo que me ocupa, durante esta semana he estado afianzando las funciones mock y probando el testeo de DOM, que no hubiera imaginado yo que era la fiesta que ha resultado ser. No fue una decisión consciente, me puse un día a hacer tests, coincidió que uno afectaba al DOM, y me di cuenta de que no funcionaba tal y como yo esperaba, vamos, no funcionaba en absoluto. Decidida me fui a la documentación y me encontré con esta guía específica de "Manipulación del DOM": https://jestjs.io/es-ES/docs/tutorial-jquery , leyendo eso me quedó claro que tenía que hacer algo especial para testear manipulaciones del DOM, pero en el ejemplo se usaba jQuery y yo estaba trabajando en JS Vanilla; además yo quería entender el por qué de lo que estaba pasando, así que no demoré, me puse las gafas de persona lista que lee mucho y empecé a investigar.

Asincronía

Tengo la teoría de que en todas las profesiones hay una pared con la que te encuentras constantemente estés haciendo lo que estés haciendo, y también la sensación de que en desarrollo front una de esas paredes tiene que ser la asincronía.

¿Y qué pinta ahora la asincronía aquí? Pues bien, como seguro sabrás el código JS es asíncrono (es decir, sus funciones no se ejecutan en completa correspondencia temporal), y esto genera que cuando el test llega a la función empiecen a producirse errores debido a que no es capaz de reconocer las referencias a elementos HTML que se va encontrando. Por poner un ejemplo claro y sencillo: si le hacemos un test con Jest a una función que en algún punto recoge el elemento con clase "input" en HTML y le añade contenido de esta forma:

Jest no ejecutará el test, ya que no será capaz de reconocer esa parte del DOM a la que estamos intentando acceder y dará un error. Esto mismo pasará con cualquier propiedad que hayamos utilizado y que actúe leyendo o modificando algún elemento HTML, dará error y el test no se ejecutará.

A esto se le suma un tema importante para el testing de front que me encontré por el camino mientras buscaba desesperada soluciones a todos mis problemas, y es que en un vídeo de CodelyTV (que dejaré referenciado abajo y es súper recomendable si estás empezando como yo) nos explican la importancia de centrarse en testear como usuario y no como desarrollador, es decir, que a la fuerza tenemos que acceder al HTML en algún momento.

En ese mismo vídeo Nuria hace una aproximación magistral y súper amplia al testing con Jest y Testing Library en 17 minutos (lo he tenido que mirar varias veces porque no sé cómo se puede contar tanto en tan poco tiempo... me quedo anonadada). Testing Library es una librería complementaria a Jest que viene a resolver el problema que comentábamos antes y que, aunque yo creía que su uso estaba limitado a la existencia de algún framework, según he visto posteriormente se puede utilizar en JS Vanilla también (dejo abajo un repositorio de GitHub con un ejemplo detalladísimo de esto y varias referencias a artículos súper interesantes sobre el tema).

Así que sí, ahí estaba yo con un test súper sencillo generando cinco mil errores que no había visto nunca, y unas 20 pestañas de Chrome abiertas cada una con información distinta (pero en todos los casos muy confusa) a sumar a mi maraña mental. Estaba viviendo uno de esos momentos en los que te dices mentalmente: "Recoge tus cuchillos y vete, es imposible que salgas de esta" cuando de repente di con EL artículo, una persona que hace un año explicó exactamente lo que yo necesitaba saber en el presente. Dejo a continuación el link al artículo que está rebien explicado y masticado https://dev.to/ms314006/use-jest-write-unit-testing-for-dom-manipulation-3n6c . Básicamente explica cómo debemos utilizar Jest (sin librerías adicionales) para testear funciones que manipulan el DOM en JS vanilla, vamos, que lo necesites cuando estás leyendo esto o no, si todavía no sabes de testing déjate ese artículo en marcadores que te va a venir bien.

Una vez superada la fase "ERRORES A LO LOCO" conseguí hacer mi primer test: "cuando le doy aquí tiene que aparecer esto". Estupendo. Funciona.

Funciones mockeadas

Llega el momento de hacerle un test a un input con un evento de escucha, quiero testear si llama correctamente a la función handler. ¡Pues a buscar otra vez! Aunque esta vez la búsqueda fue mucho más acotada y rápido di con la solución que más se ajustaba a lo que necesitaba: las funciones mockeadas. Es cierto que en el episodio 1 de "Sé más de testing que ayer" ya comenté su existencia, pero la realidad es que no llegué a desarrollar su aplicación.

Las funciones mockeadas son funciones "espía", ¿Qué quiere decir esto?, que son funciones que nos permite crear Jest y que nos "cuentan" el comportamiento que tendrá cualquier otra función en su lugar. Imaginemos que tenemos una función llamada scaleImage() que se activa con la modificación de un input de tipo range (el típico zoom) por parte del usuario, si queremos saber exactamente cómo se comportará esa función haremos un test con ese mismo input apuntando a una función mockeada (en el ejemplo inputSize cuando ocurra el evento "mousemove" disparará mockFn, nuestra función mockeada), que como es nuestra espía nos contará todo lo que ha ocurrido cuando se le ha llamado.

En el código de ejemplo añadimos una implementación a la función mockeada, es decir, le decimos qué queremos que haga cuando la disparemos. Como cualquier otra función, si no le indicamos el valor a devolver o no indicamos una implementación, devolverá undefined.

En esta página de la documentación de Jest están todos los métodos que podemos usar con las funciones mock (para "preguntarle" detalles de su comportamiento o establecer la implementación entre otros muchos): https://jestjs.io/es-ES/docs/mock-function-api

Hasta aquí mi avance de esta semana con Jest, como siempre, cualquier feedback (si es con amor o gatos) es bien recibido :)

Recursos:

Repositorio GitHub sobre testing en JS Vanilla con Jest+Testing Library (las referencias que deja el autor también son de muchísima utilidad para el contexto): https://github.com/thawkin3/dom-testing-demo
Vídeo youtube Midudev de testing en React JS con Jest+Testing Library: https://www.youtube.com/watch?v=KYjjtRgg_H0
Vídeo CodelyTV: https://www.youtube.com/watch?v=SH7JSlc36uA

Sé más de testing que ayer (Episodio 1: Tests unitarios en Jest y JS vanilla)

Marta Rey — Wed, 12 May 2021 10:41:31 +0000

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

CSS tiene planes para ti - Polaroid funcional con CSS y JavaScript

Marta Rey — Thu, 29 Apr 2021 16:37:05 +0000

Cuando acabé el bootcamp tenía ganas de hacer cosas, no sabía qué cosas, pero cosas. Me pasé varias semanas enganchadísima a Hackerrank y sus retos de código: los primeros días es un tormento (al menos para mí lo fue), pero poco a poco vas cogiéndole el punto, vas ganando medallitas, te sueltan confetti para celebrar tus avances y es un mundo de fantasía del que no quieres salir.

Pero un día por algún motivo entré en Codepen, descubrí la pestaña de "trending" (esa pestaña para mí ahora mismo es un pozo donde tiro horas del día al nivel "lupa de Instagram"), y vi la primera Polaroid hecha en CSS. Aluciné. Y después de alucinar me apunté lo de la polaroid para que no se me olvidara hacerla algún día con tanto alucine.

Total, que esta semana me encontré un pen de hace meses con una prueba rápida de cómo abrir la cámara y sacar fotos utilizando HTML y JavaScript y, aun siendo millennial y junior y todo, me di cuenta de que era el momento perfecto para intentar LA POLAROID (siento el grito, de alguna forma tenía que enfatizarlo después de la chapa introductoria).

A parte de estar tremendamente emocionada con esta creación por el resultado final en relación a mis expectativas, tengo que decir que ha sido uno de los proyectos CSS más agradecidos que he hecho hasta el momento. Obviamente me ha llevado su buen tiempito (demasiados detalles en la foto para tan poca experiencia en CSS), pero para nada ha sido la tortura que me había imaginado.

Tanto es así que me he permitido el lujo de volver a hacer una cheat sheet con las partes que me resultan más complicadas o "difíciles de simplificar":

Dejo por aquí el link a Codepen donde está todo el código que he usado para hacerla: https://codepen.io/martreyz/pen/ExNvbGd

Cualquier feedback (si es con amor o gatos) es bien recibido! :)

¿Se acuerdan de lo de Redux?... Que por no guardar una cosa en el estado... toda esa mierda?

Marta Rey — Fri, 23 Apr 2021 10:24:03 +0000

Este lunes por fin me decidí a reorganizar los cientos de miles de recursos que he ido acumulando desde que empecé en el desarrollo front end y tenía inconvenientemente repartidos por todas partes: elementos guardados de Twitter, marcadores de Chrome, distintas páginas en Notion, mensajes a mí misma en Whatsapp, mensajes a mí misma en Slack e incluso en algún email a mí misma.

A mitad de esa misma mañana ya había dejado la organización para el martes y empezado un tutorial de Youtube que me había encontrado en alguno de mis "trasteros digitales". No me avergüenzo de mi decisión, creo que cualquiera al que le vengan por primera vez con que si "estados globales", que si "concurrencia", que si "eliminación de la asincronía de JS" y demás bondades de Redux hubiera hecho lo mismo que yo.

Redux es una librería de gestión de estado para aplicaciones JavaScript, que no suena tan impresionante como luego resulta ser, de verdad lo digo.

Los tres personajes principales aquí son: el "store" (el almacén, donde guardamos los estados de forma global), las "actions" (debe haber una acción para cada uno de los eventos que ocurren en la página, cada action tiene un identificador único que nos permite "dispararlas" de forma independiente y controlada), y los "reducers" (funciones puras que definen el resultado de cada una de las acciones en nuestro estado).

Yo he acabado asimilando cómo funciona comparándolo con un montacargas de comida de un hotel (el pasado siempre vuelve):

De esta forma, en mi cabeza el "store" es la cocina, los "reducers" son los montacargas y las "actions" serían el botón que llama al montacargas. Es decir, en Redux utilizaremos una action para disparar los reducers que estén afectados por esa action, y que nos ayudarán a hacer la gestión de estado en el store.

Desde que he empezado a aprender Redux he debido de leer unas 50 veces que no se debe utilizar para proyectos pequeños, ya que el uso de Redux complica el código y hay en ocasiones que no nos va a resultar rentable, pero claro, ¡Yo quería probarlo! Así que he hecho un pequeño cronómetro muy sencillo (pero muy matón) en el que toda la funcionalidad trabaja usando Redux:

Aunque dejaré abajo el repositorio del proyecto, porque compartir es vivir, no tiene mucho sentido que me ponga a contar cómo lo hice (seamos honestos, llevo literalmente cuatro días usando Redux y habrá partes como para llevarse las manos a la cabeza). Sin embargo sí que me ha parecido interesante dejar por aquí ciertos puntos que podrían resultarte de mucha utilidad si has decidido empezar con Redux y no te puedes permitir perder la cabeza en el intento como llevo haciendo yo cinco días:

Redux está basado en el paradigma de programación funcional, que a mí por lo menos me pillaba muy lejana de mi adorada "orientada a objetos", por lo que tuve que dar un rodeo bastante amplio antes de entrar en materia para contextualizarme un poco.
En mi proyecto lo utilicé con React JS, pero se puede utilizar Redux con cualquier framework JS, incluso con JS vanilla.
En caso de utilizarlo con React JS, el routing se tiene que hacer diferente a como estamos habituados. Para usarlo en Redux deberemos recurrir a Connected React Router, en su repositorio de GitHub dejan información detallada sobre la instalación y configuración: repositorio GitHub
Si has desarrollado usando estados, ten muy presente el cómo harías cada cosa en la librería o framework que conoces, ya que todo va a funcionar muy parecido. Yo me pasé dos días buscando una solución para la función de restart y no di con ella hasta que pensé en cómo lo haría con ReactJS únicamente.
Entre los fundamentos de Redux se encuentra la inmutabilidad, es decir, cuando creamos un objeto no podremos mutarlo, tendremos que hacer una copia y mutar esa copia. Por este motivo, te va a resultar de muchísima utilidad entender y practicar el spread antes de ponerte manos a la obra (esto ayudará a que el código no sea tan verboso y quede todo más limpio y legible, por no decir que mola mucho y te quedas con toda la peña usándolo).

Recursos mencionados/utilizados:

Proyecto cronómetro: https://github.com/martreyz/redux-sports-watch
Tutorial Mosh Hamedani (Twitter: @moshhamedani): Dura hora y media y en la introducción habla también de la programación funcional, ultra completo! Vídeo Mosh Hamedani
Tutorial Dev Ed (Twitter: @deved94) : Dura media hora, yo lo vi después del de Mosh Hamedani y me vino muy bien para aclarar ciertas dudas ver una construcción más sencilla, además personalmente este chico me cae estupendamente y me río mucho con sus vídeos) Vídeo DevEd
Connected React Router: https://github.com/supasate/connected-react-router

A este "cacho carrrne" le gusta CSS - Bender (Futurama)

Marta Rey — Thu, 15 Apr 2021 16:38:10 +0000

Tener 30 años y ser programadora front end, junior, sin experiencia laboral, y además una motivada en tus ratos libres se hace durillo, no nos vamos a engañar. Si no has pasado por esto, te cuento que la idea es pasarse todo el día haciendo cursos, aprendiendo cosas, perfeccionando skills y buenas prácticas y un largo etc mientras vas recibiendo descartes de procesos de selección.

Y ¡ojo! yo también he sido junior en mi profesión anterior antes de ser senior (vamos, lo normal), pero no es la misma sensación estar empezando en el mundo laboral que pegar un volantazo a mitad de camino. Con el volantazo tienes que sumar a los agobios y preocupaciones habituales de la búsqueda de empleo el síndrome del impostor, que es una movida , y que se encarga de hacerte sentir un fraude cada vez que tiene un ratillo, y recordarte que "algún día se darán cuenta de que eres una estafa".

Pues bien, yo al síndrome de impostor le doy en la cara con CSS. No es la primera vez que digo esto, pero es que es la verdad. Antes de ser "programadora impostora" ya era "dibujanta impostora" (que por cierto, era mucho más impostora como dibujanta y lo hacía con toda la normalidad del mundo, tendría que hacérmelo mirar). Total, que hacer dibujitos me entretiene, me relaja y mantiene mi foco en un lugar constructivo; y si los dibujitos se hacen en CSS y luego puedo añadirle animaciones, transiciones y JavaScript ya ni te cuento.

Por lo visto si a mi síndrome del impostor le sumas la emisión de Futurama en Disney+ y un fin de semana de lluvias y pandemias de por medio resulta esto:

En realidad hacer a Bender con CSS no ha sido demasiado complicado ya que es un personaje con líneas bastante claras y poquitos detalles, no obstante dejo aquí un cheat sheet que he hecho con las partes que me parecen más rebuscadas por si a alguien le apetece probarlo:

Este es el trabajo en Codepen donde también está todo el código, cualquier feedback (si es con amor :)) es bien recibido!:
https://codepen.io/martreyz/pen/vYgdzog

Escrito con -^. .^- por martreyz

No sé mucho de GIT pero tiro palante

Marta Rey — Thu, 08 Apr 2021 10:14:35 +0000

Llevo programando y usando GIT aproximadamente 7 meses, sin embargo nunca he tenido claro exactamente ni qué es, ni cómo funciona por detrás, ni cómo separar las funciones de GIT y las de GitHub. Un desastre, vamos. Pero para eso estamos aquí, para hacer una guía rápida y básica de GIT con todo lo que necesitamos saber para tirar palante con la vida como desarrolladoras.

Empezando por el principio... ¿Qué es GIT? Git es un software de control de versiones, quizá esto ya lo sabíamos, pero quizá no sabíamos que se trata de software libre, y que su mantenimiento actual recibe actualizaciones de aproximadamente 280 programadores.

Cuando iniciemos Git en un repositorio veremos que nos creará un subdirectorio llamado ".git". Este subdirectorio es el encargado de ir guardando el "esqueleto" de nuestro proyecto, esto es todos los archivos necesarios para su funcionamiento. A partir de este punto, iremos haciendo cambios y actualizaciones en nuestro código que podremos ir añadiendo a commits de Git, es decir, "versiones" de nuestro proyecto que se van quedando guardadas y plenamente identificadas de forma individual. ¿Y para qué todo este lío? Pues probablemente eso sea lo único que tengo claro escribiendo sobre Git, hacemos todo este lío porque pase lo que pase el software nos permitirá volver a cualquier versión anterior que necesitemos, es decir, si a mí un día se me ocurriera trabajar en un proyecto tomándome un chupito de tequila cada vez que escribo "lenght", al día siguiente podría recuperar la última versión antes del desastre.

Además, Git nos permite trabajar con "ramas". El trabajo con ramas, además de estar presente en infinidad de metodologías de workflow actuales, es muy útil para cualquier tipo de proyectos, incluso los más pequeños y personales. La creación de una nueva rama es simplemente la creación de una "copia" del proyecto tal como está, en la que podrás probar nuevas funcionalidades, estilos e ideas peregrinas sin miedo de romper nada de tu avance, ya que siempre tendrás tu copia idéntica a salvo en tu rama inicial.

Vale, y ahora, en toda esta bendita historia, ¿Dónde entran las plataformas como GitHub? Las plataformas como GitHub son servicios en línea a los que Git puede conectarse para subir o bajar código y recursos. Es importante, por tanto, entender en este punto que GitHub no gestiona nuestras versiones, solo se conecta con Git para recoger o dar información, o para crear nuevos commits que podamos realizar desde este repositorio remoto.

A mí, como profana, me ha resultado muy útil hacer un paralelismo entre GitHub y Google Drive (como servicio de almacenamiento) para entender todo esto: Si yo escaneo un documento con una app del móvil y posteriormente lo subo a Google Drive, lo único que hace Google es guardar ese archivo, no lo ha creado. Sin embargo, si lo deseo puedo utilizar Drive como editor de ciertos archivos, y esos archivos los puedo devolver de nuevo a local y seguir trabajando con él en el editor del ordenador que sea. Pues algo así es lo que yo entiendo que ocurre con GitHub.

Pero aunque yo considero súper necesario tener una desambiguación correcta de las herramientas que utilizamos antes de utilizarlas, vamos a lo que más mola, al tema que te quema, a los comandos más guays y necesarios de Git:

- git init: Inicia git, crea el subdirectorio .git que comentamos antes.
- git fetch: Revisa el repositorio remoto (el que tengamos en el servicio online X, por ejemplo en GitHub) en busca de cambios vs el local y se los descarga.
- git pull: Revisa el repositorio remoto (el que tengamos en el servicio online X, por ejemplo en GitHub) en busca de cambios vs el local, se los descarga, y los aplica a nuestra versión local.
- git add <nombre_archivo>: Añade el archivo que indiquemos a la versión (commit). Si indicamos git add -A le estaremos diciendo que añada todos los archivos para el nuevo commit.
- git commit -m "mensaje": Crea una versión con los cabios realizados en los archivos que hayamos añadido. El mensaje se utiliza para indicar una breve descripción de los cambios realizados. Según convención los commits acostumbran a ser en inglés, y comenzar por un verbo en infinitivo. (E.G "Add landing page styles").
- git push: Sube el commit realizado al repositorio remoto. Si estamos subiendo cambios en una nueva rama tendremos que indicar `git push -u origin <nombre_rama>`
- git status: Muestra el estado actual de la rama, como los cambios que hay sin commitear.
- git checkout -b <nombre_rama_nueva>: Crea una rama idéntica a en la que te encuentras con el nombre "nombre_rama_nueva", y una vez creada te lleva a esta rama nueva.
- git merge <nombre_rama>: Desde una rama X haremos merge de otra rama Y para unir ambas versiones. Realizar esta acción, dependiendo de la naturaleza de los cambios entre ambas ramas, derivará en un merge blando (git lo realizará solo y únicamente tendremos que confirmar) o un merge duro (tendremos que resolver conflictos manualmente e indicar con el código de qué rama nos queremos quedar).
- git branch -a: Crea una lista de todas las ramas (locales y remotas).
- git remote prune origin: Actualiza tu repositorio remoto en caso que algún otro desarrollador haya eliminado alguna rama remota.
- git reset --hard: Elimina todos los cambios realizados de los que aún no se haya hecho commit.
- git revert <commit>: Revierte el proyecto al commit "commit".