El Arte de las 'Vistas Humildes': Probando Aplicaciones React Native de Manera Inteligente

Rate this content
Bookmark

En esta charla, exploramos el mundo divisivo de las pruebas, donde los desarrolladores a menudo se encuentran divididos entre no escribir pruebas y esforzarse por una cobertura de pruebas del 100%. Aprenda a navegar estas posiciones polarizantes y adopte una estrategia más matizada que hace que las pruebas sean eficientes y efectivas. Profundizaremos en el concepto de 'Vistas Humildes', donde minimizamos los objetos no probables extrayendo la lógica de los elementos de la interfaz de usuario a partes amigables para pruebas del código base. Este enfoque simplifica las pruebas, centrándose en la lógica de negocio en lugar de las complejidades de la interfaz de usuario. Descubra cómo la arquitectura Modelo-Vista-Presentador (MVP) ayuda a lograr esto, con los presentadores sirviendo como una capa lógica para las pruebas y los hooks ayudando a separar la lógica de los componentes de la interfaz de usuario. A lo largo de la charla, discutiremos los compromisos de este enfoque, el papel de las pruebas de extremo a extremo (E2E), y cómo lograr el equilibrio perfecto entre demasiadas y pocas pruebas. ¡Únase a nosotros mientras nos adentramos en el arte de crear 'Vistas Humildes', asegurando que nuestras aplicaciones React Native sean escalables, mantenibles y efectivamente probadas!

32 min
07 Dec, 2023

Comments

Sign in or register to post your comment.

AI Generated Video Summary

Esta charla discute los desafíos de las pruebas en las aplicaciones React y React Native, particularmente con respecto al escaneo de códigos de barras. Explora la violación de la separación de preocupaciones en React y propone el uso del modelo HumbleObject para simplificar las pruebas y mejorar la limpieza del código. También se introduce el modelo MVP como una forma de separar el estado de la interfaz de usuario y la lógica del componente. Se enfatiza la importancia de seguir patrones, la estandarización y los principios de enseñanza, junto con los beneficios de usar hooks personalizados para compartir la lógica de negocio. También se menciona el potencial de las herramientas de IA en la refactorización del código.

1. Introducción a las Vistas Humildes y Pruebas

Short description:

Hola a todos. Muchas gracias, Nathaniel. Esa fue sinceramente una introducción muy amable. Hoy estoy emocionado de estar en Berlín hablando sobre las vistas humildes en las aplicaciones de React y React Native. Dirijo el equipo móvil en el Reino Unido para Theodo, una consultoría global con experiencia en React y React Native. Las pruebas son un tema polémico con diferentes puntos de vista, desde apuntar a un 100% de cobertura de pruebas hasta no hacer pruebas en absoluto.

♪♪♪ Hola a todos. Muchas gracias, Nathaniel. Esa fue sinceramente una introducción muy, muy amable. Me siento humilde. Vamos. Bueno, los chistes de papá no caen muy bien aquí. Bueno saberlo. Bien, de acuerdo. Así que hoy estoy muy emocionado de estar en Berlín con todos ustedes. Es mi primera vez en la ciudad, y es tan estéticamente agradable. Las vibraciones son sinceramente impecables, especialmente con la nieve. Estoy muy emocionado de hablar sobre este concepto de vistas humildes. Vamos a ver cómo puedes arquitecturar tus aplicaciones de React y React Native para, con suerte, facilitar un poco las pruebas y también hacer que tus aplicaciones sean más escalables.

Un poco sobre mí. Como mencionó Nathaniel, mi nombre es Mo. Dirijo el equipo móvil en el Reino Unido para Theodo. Así que Theodo es una consultoría global con más de 700 expertos digitales, 150 de los cuales hacen React Native y React. Así que hemos estado haciendo React y React Native desde los primeros días de su aparición. Y como resultado, hemos pasado por fases de evolución y hemos visto diferentes bases de código y hemos visto diferentes patrones e intentado encontrar los que duran mucho tiempo y son escalables y esperamos poder compartir algo de eso con ustedes hoy.

Así que las pruebas son un tema polémico. La gente suele caer en dos campos. Si sigues la ruta del artesano del software, te encuentras con gente como Bob Martin, que cree firmemente que debes apuntar a un 100% de cobertura de pruebas, que una alta cobertura de pruebas es la piedra angular de una buena base de código. Así que esta es la visión tradicional, y esta es la visión que te dirá el artesano del software. Más recientemente, por otro lado, tienes a los influencers de YouTube en el espacio de la codificación que te dirán, ¿sabes qué? No he estado probando durante años y he sido muy rápido, nunca podrás alcanzarme. Trabajé en Twitch, confía en mí, hermano. Y entonces obtienes estos diferentes puntos de vista y tienes gente que está vehementemente en contra de las pruebas y tienes gente que está muy, muy a favor de las pruebas. Y así, como con muchas cosas en la vida estos días, las cosas se polarizan al extremo. A la izquierda, tienes a la gente que dice, no pruebes. Y si pruebas, nunca más me hables. Y luego a la derecha, tienes gente que dice, tu código es malo, deberías estar probando cada parte de él.

2. Desafíos con las Pruebas del Escáner de Códigos de Barras

Short description:

Tienes esta tierra de nadie de pruebas en el medio donde se pierde toda la sutileza. Mi objetivo es molestar a ambas partes con una charla. Permíteme establecer el escenario: un proyecto de React Native en la industria de la moda. Un desarrollador quería probar el escáner de códigos de barras pero se encontró con desafíos en la configuración. Se requerían múltiples contextos y simulacros para las pruebas.

Y realmente, lo que sucede es que tienes esta tierra de nadie de testing en el medio donde se pierde toda la sutileza. Y a veces se lanzan tomates desde ambos lados. Pero realmente, no se tienen muchas conversaciones matizadas en torno a un enfoque pragmático de testing. Y me considero un poco centrista. No defiendo nada. Así que mi objetivo es molestar a ambas partes con una charla. Veremos cómo va esto.

Permíteme establecer un poco el escenario. Así que hace un par de años, estaba trabajando en un proyecto de React Native en la industria de la moda. La aplicación iba a ser utilizada en almacenes donde iban a escanear artículos de ropa con un escáner de códigos de barras dentro de la aplicación. Y almacenaría alguna información. Podrían introducir información sobre el artículo de ropa. Y estaba siendo utilizado por la oficina de atrás, efectivamente. Había una desarrolladora en mi equipo que estaba trabajando mucho en las cosas de front end. Y en un momento me dijo, estoy intentando escribir una prueba para el escáner de códigos de barras. Básicamente, lo que quiero probar es que cada código de barras tiene un checksum. Los últimos dígitos serán una suma de algunos de los valores en el medio en alguna fórmula matemática. Así que quiero probar eso. Pero el desafío que encontró fue que necesitaba hacer mucha configuración antes de que pudiera realmente probar eso al renderizar la pantalla. ¿Y a qué me refiero con eso? De hecho, extraje el código y verás lo horroroso que es en solo un segundo. Pero esta pantalla inicialmente tenía un montón de contextos diferentes. Y realmente no los necesitábamos para la pantalla en sí. Pero necesitaba ser simulado para que pudieran seguir adelante y probarlo. Genial. Así que eso es un montón de simulacros. Luego, algunos de los clientes necesitaban ser simulados para las solicitudes de fetch. El escáner de códigos de barras de Expo, que era una biblioteca externa que utiliza el dispositivo nativo, también necesitaba ser simulado porque no tienes acceso a eso en las pruebas unitarias. Tu marco de navegación en la capa nativa necesitaba ser simulado. Bien. Eso es más simulacros.

3. La Violación de la Separación de Preocupaciones por React

Short description:

Después, queríamos espiar alert, que es la funcionalidad de alerta nativa dentro de React Native. Y entonces ella me hizo una muy buena pregunta, que fue, ¿siempre tiene que ser tan difícil? Y me hizo pensar en la arquitectura general de nuestro código, ¿verdad? La arquitectura son las decisiones que desearías poder acertar al principio de un proyecto. Uno de los conceptos fundamentales que aprenderás dentro de la arquitectura de software es esta idea de separación de preocupaciones, ¿verdad? Ahora estamos en el mundo de React, y React está un poco en desacuerdo con la separación de preocupaciones. El punto de venta fundamental de React y la premisa de JSX se basan realmente en violar la separación de preocupaciones. Es esta idea de que puedes traer tu marcado a tu capa de interactividad, comenzar a escribir sintaxis similar a HTML para representar tu interfaz de usuario dentro de JavaScript. Así que estamos juntando todas estas cosas. Y esto es genial, por cierto. No estoy negando el hecho de que esto es en realidad una gran adición para tener como marco, porque hace las cosas mucho más rápidas y mucho más fáciles de entender con esta mentalidad basada en componentes. Lo que significa es que puedes poner todo en un solo lugar y todo simplemente funciona. Así que tengo el ejemplo de contador más básico que puedes pensar. Está en React Native, pero es lo mismo con React. Tienes en la parte superior tu interactividad. Pero en la parte inferior tienes tu capa de presentación, así que tienes tu marcado y tu estilo. Y si añades un marco de estilo como Tailwind a ello, básicamente tienes tu estilo, tu marcado, así que tu estructura de interfaz de usuario así como tu interactividad todo en un solo archivo. Así que la separación de preocupaciones se vuelve un poco más confusa allí.

Después, queríamos espiar alert, que es la funcionalidad de alerta nativa dentro de React Native. Otra funcionalidad. Y luego simplemente continuó una y otra vez. Es como tantos simulacros antes de que realmente pruebes lo que fundamentalmente querías probar, que es la lógica de negocio central, ¿verdad? Realmente no es un buen estado del arte cuando estás testing de esta manera.

Y entonces ella me hizo una muy buena pregunta, que fue, ¿siempre tiene que ser tan difícil? Y me hizo pensar en la arquitectura general de nuestro código, ¿verdad? Y conduce a una muy buena pregunta, que es, ¿qué es la arquitectura de código? Y realmente me gusta esta definición. Así que la arquitectura son las decisiones que desearías poder acertar al principio de un proyecto. Es una cita de Ralph Johnson, que es profesor de ciencias de la computación en los Estados Unidos. Ha escrito varios libros sobre buena arquitectura de software.

Y uno de los conceptos fundamentales que aprenderás dentro de la arquitectura de software es esta idea de separación de preocupaciones, ¿verdad? Así que esta idea con la separación de preocupaciones es que puedes tomar diferentes componentes dentro de tu aplicación y tratas de dividirlos en modules o trozos individuales que son cada uno individualmente responsable de un solo trabajo distinto. Y pueden hacer eso independientemente de todas las demás partes. Esa es la teoría. Así que los ejemplos que obtienes es como la división de HTML, CSS, JavaScript en la web tradicional o la pila IP, que está en casi todos los libros de texto de ciencias de la computación, que es como, tienes todas estas capas en la pila de red, y luego puedes sacar una y reemplazar con algo más. Y en teoría, el resto del sistema debería funcionar bien.

Ahora estamos en el mundo de React, y React está un poco en desacuerdo con la separación de preocupaciones. ¿Qué quiero decir con eso? Así que el punto de venta fundamental de React y la premisa de JSX se basan realmente en violar la separación de preocupaciones. Es esta idea de que puedes traer tu marcado a tu capa de interactividad, empezar a escribir sintaxis similar a HTML para representar tu interfaz de usuario dentro de JavaScript. Así que viola esa antigua mentalidad tradicional de separación de preocupaciones, que tu HTML hace tu marcado, tu JavaScript hace tu interactividad, y tu CSS hace tu estilo. Y el resto del ecosystem sigue el ejemplo. Tienes bibliotecas como componentes de estilo, que te permiten hacer tu estilo dentro de tu JavaScript también, este concepto completo de CSS y JS. Así que estamos juntando todas estas cosas. Y esto es genial, por cierto. No estoy negando el hecho de que esto es en realidad una gran adición para tener como marco, porque hace las cosas mucho más rápidas y mucho más fáciles de entender con esta mentalidad basada en componentes. Lo que significa es que puedes poner todo en un solo lugar y todo simplemente funciona. Así que tengo el ejemplo de contador más básico que puedes pensar. Está en React Native, pero es lo mismo con React. Tienes en la parte superior tu interactividad. Así que son los estados usados que tienes, las devoluciones de llamada que tienes para incrementar el contador. Pero en la parte inferior tienes tu capa de presentación, así que tienes tu marcado y tu estilo. Y si añades un marco de estilo como Tailwind a ello, básicamente tienes tu estilo, tu marcado, así que tu estructura de interfaz de usuario así como tu interactividad todo en un solo archivo. Así que la separación de preocupaciones se vuelve un poco más confusa allí.

4. Desafíos de React con Componentes Grandes

Short description:

React no te impide crear componentes grandes que no están modularizados correctamente. Los archivos de React masivos con cientos o miles de líneas se convierten en un infierno para probar. Otros patrones arquitectónicos como Modelo-Vista-Controlador y HumbleObject pueden abordar estos problemas. Vamos a centrarnos en el modelo HumbleObject. Un componente típico de React puede tener código de infraestructura, lógica de negocio, estado y lógica de la interfaz de usuario, y JSX con estilo.

Tómalo... No se supone que debas leer este código, por cierto. No lo intentes. No tiene sentido. Pero la idea aquí es que si añades un poco más de funcionalidad y la mantienes dentro del mismo componente, solo con buscar el nombre de un artículo y tener el botón para volver a buscar, estos archivos se vuelven cada vez más y más grandes. A medida que empiezas a hacer estos componentes más y más complejos, las testing también se vuelven más difíciles porque estás añadiendo todas estas diferentes dependencias en un solo componente o una sola pantalla. Y este es, con mucho, el mayor desafío que la gente enfrenta, creo, cuando están diseñando su architecture. Y es que React en realidad no te impide crear estos grandes componentes que no están correctamente modularizados. Terminas, de alguna manera, pintándote a ti mismo en un rincón si no estás pensando conscientemente en cómo divides tus límites de componentes dentro de React.

Así que vamos a quemar esto y ver a dónde va realmente. Un síntoma habitual que he visto en los códigos, y hemos estado yendo a muchos diferentes códigos brownfield que ves en la naturaleza, es que tienes estos archivos masivos de React con cientos o en algunos casos extremos incluso miles de líneas. Y en la mayoría de los casos, estos componentes también resultan infernales para probar. Así que esto no es un problema nuevo. La gente ha estado construyendo GUIs desde la década de 1980, ¿verdad? ¿Cómo lidiaron con esto cuando las testing eran un desafío? Si volvemos al tablero de dibujo y damos un paso fuera del mundo de JavaScript, ha habido mucho trabajo realizado por personas en otros lenguajes y otros frameworks para mirar el espacio arquitectónico y abordar algunos de estos problemas. Así que podrías haber oído términos como Modelo-Vista-Controlador, podrías haber oído el término llamado HumbleObject, en el que vamos a profundizar un poco más hoy. El Modelo-Vista-Presentador, su primo muy cercano, el Modelo-Vista-ViewModel, todos estos grandes nombres, ¿verdad? Te encantará este. ¡Mira eso! El View-Interactor-Presenter-Entity, es muy pegadizo. Viper, para abreviar. Ahora no vamos a entrar en todos estos, vamos a profundizar en dos patrones arquitectónicos patterns que creo que son realmente útiles en el espacio de React. Comencemos con el modelo HumbleObject.

Así que digamos que tenemos un componente y quieres probar realmente este componente. Un componente típico de React puede tener muchas cosas dentro de él. En un nivel, puedes tener código de infraestructura. ¿Qué queremos decir con eso? Está buscando cosas. Son servicios externos. Quizás estás llamando a Sentry, quizás estás llamando a Google Analytics, todos pueden vivir dentro de un componente y a veces encontrarás que lo hacen en la naturaleza. Puedes tener lógica de negocio, cosas como Transformadores, reglas que puedes tener en tu código, diferentes flujos de lógica. Puedes tener estado de la interfaz de usuario y lógica que está inherentemente relacionada con la renderización. Así que esos son tus campos de formulario, tus reglas de validation, y así sucesivamente, quizás alguna interactividad que entra en juego. Y por último, tienes el JSX real y el estilo.

5. El Modelo HumbleObject y la Configuración de la Aplicación

Short description:

El modelo HumbleObject separa la lógica de negocio del componente, haciendo las pruebas más simples y menos dolorosas. Un ejemplo de codificación demuestra el antes y el después. La configuración de la aplicación incluye una página de pago con varias lógicas, como descuentos basados en el total, costos de envío cambiantes y fecha de entrega estimada basada en el tamaño de la cesta.

El modelo HumbleObject intenta ayudar con este problema que puedes tener, que es cuando intentas probar este componente en su totalidad, es realmente bastante complejo. Porque necesitas simular un montón de cosas, simular tus dependencias externas, y tal vez no quieras probar todo esto. Si pensamos en lo que realmente nos importa testing a nivel básico y fundamental, realmente queremos probar la lógica de negocio más que cualquier otra cosa. En el caso de nuestro escáner de códigos de barras, lo que nos importa testing es asegurarnos de que la función de suma de comprobación funciona bien. Que si hay un duplicado, y dos códigos de barras coinciden entre sí, lanzamos una excepción y lanzamos una regla de validation.

Entonces, lo que dice el modelo HumbleObject es, saca eso del componente y sepáralo en su propio módulo o archivo o lo que sea. Y coloca tu lógica de negocio, coloca las partes importantes de tu lógica dentro de eso. Y en lugar de testing el componente real directamente, puedes probar el HumbleObject. Y cuando lo pruebas, es mucho más simple y hay mucho menos dolor asociado a ello. Así que vamos a ver un ejemplo de codificación para esto. Y ver un antes y un después.

Genial. Muy bien. Así que tenemos una configuración de aplicación muy básica aquí. Es una página de pago de preparación de comidas. No está muy bien diseñada, pero básicamente tienes una página de pago y tiene alguna lógica añadida. Así que tienes algún nivel de descuentos. Si tu total acaba siendo más de $50, obtienes un descuento. Así que puedes ver que una vez que caigo por debajo de $50 y estoy en $37, los descuentos desaparecen. Y puedes buscar y añadir más artículos si todavía tienes hambre y quieres añadir más artículos. Otras partes de la lógica que son interesantes aquí es que tus costos de envío subirán y bajarán dependiendo de tu total. Así que si estás obteniendo menos de $20, creo que terminas incurriendo en un costo de envío de $5. Y también verás que la fecha de entrega estimada cambia dependiendo de cuán grande es tu cesta. Así que tenemos un poco de lógica de front-end que vive aquí. Vamos a echar un vistazo al código. Así que si empezamos aquí, es una configuración muy básica. Dentro de app.jsx, puedes ver un componente que ni siquiera es tan largo comparado con lo que podrías ver en un rato. Son unas 110 líneas. Se suma si te enfrentas regularmente a componentes que rondan las 100 líneas en React. 200 líneas.

6. Pruebas de la Lógica Central del Negocio con un Objeto Humilde

Short description:

Vale, tenemos un ganador. Muy bien. 600 es la referencia. Tienes una función isTomorrow, una función para obtener la fecha de entrega, y una generate delivery label. Debajo, está el componente del carrito de compras con estado, efectos, y un reductor para el total. Hay funciones para manejar la eliminación y adición de artículos. En la parte inferior, está la lógica de renderizado con JSX. Probar esta lógica central del negocio requiere simular fetch y verificar si se aplica un descuento. Un objeto humilde puede simplificar las pruebas y mejorar la limpieza del código.

600. Vale, tenemos un ganador. Muy bien. 600 es la referencia. Genial. Así que hay mucho que está pasando aquí. Vamos a repasar rápidamente. Tienes una función isTomorrow. Estas son algunas funciones de ayuda, sus utils. Tienes una función para obtener la fecha de entrega dependiendo del número de artículos en el carrito. Tienes un generate delivery label. Entonces, lo que hace es verificar si la fecha es mañana? Si es mañana, simplemente di mañana. De lo contrario, lo que quiero que hagas es renderizar la fecha en un formato muy específico. Y luego tienes el componente React real debajo de él. Tienes shopping cart, que mantiene en estado los artículos del carrito. Tienes que usar efectos para obtener la cesta inicial. Y luego, tienes un reductor para verificar cuál es el total. Y luego puedes descontar artículos dependiendo de si el total es más de $50, y así sucesivamente. Y luego tienes funciones para manejar la eliminación de un artículo y manejar la adición de un artículo, que realiza otra llamada a la API. Y en la parte inferior, tenemos la solitaria lógica de renderizado, que tiene el actual JSX, ¿verdad?

Ahora, mucho de esto es realmente la lógica central del negocio. Entonces, si quieres probar esto, y vamos a entrar en nuestro app.test.jsx, que es solo una prueba VTest aquí. Permíteme acercar un poco. Olvidé preguntar, ¿todos pueden ver y leer claramente el código? ¿Verdad? Genial, gracias. Entonces, lo que hemos tenido que hacer en el nivel más alto aquí es que hemos tenido que simular el fetch. Y luego, la forma en que, digamos que queríamos probar si se aplica o no un descuento por más de $50 de cesta, porque esa es la lógica central que estamos testing aquí. Lo que hemos hecho es renderizar el carrito de compras. Y luego, estamos haciendo un query selector para verificar, ¿hay texto que tiene un tachado aplicado a él que dice $10, que es el primer elemento en nuestro precio simulado, y luego lo estamos testing. Entonces, de una manera extraña, lo que realmente nos importaba testing es muy diferente a lo que realmente hemos probado, que es que hemos probado la UI con el objetivo de validar que nuestra lógica de negocio funciona, ¿verdad? Es un poco contraintuitivo. Pero lo que realmente podemos hacer bastante fácilmente es que podemos tomar mucho de eso y convertirlo en un objeto humilde.

7. Pruebas Simplificadas con el Modelo de Objeto Humilde

Short description:

Y verás que las pruebas son mucho más fáciles, pero también el código se ve mucho más limpio. Tenemos un módulo de pagos con simples funciones de JavaScript para aplicar descuentos, calcular totales y costos de envío. En el archivo app.jsx, llamamos a estas funciones desde nuestro servicio de pagos. Probar la lógica central del negocio se vuelve simple y no requiere lidiar con comportamientos asíncronos o ciclos de vida del componente. Podemos pasar menos tiempo escribiendo pruebas y centrarnos en verificar la lógica del negocio.

Y verás que las pruebas son mucho más fáciles, pero también el código se ve mucho más limpio. Así que vamos aquí y veremos el carrito de compras ahora. Así que no tenemos ninguna de esas funciones de ayuda arriba, pero tenemos un módulo de pagos que seguimos llamando para hacer la transformación de la lógica del negocio. Así que echemos un vistazo a payments.js y veamos qué hay allí. Puedes ver que son solo un montón de simples funciones de JavaScript. Tenemos un apply discount que toma los artículos. Tienes un calculate total que toma los artículos y ejecuta un reductor en ellos. Tienes un calculate shipping cost, que es solo un ternario muy simple dentro de él. Todo se ha vuelto muy funcional, pequeños bits de lógica de negocio que hemos incluido aquí. Y luego al final, simplemente devolvemos eso como un módulo en sí. Y si volvemos a app.jsx, lo que podemos ver es que todo lo que hacemos en nuestro componente de React es simplemente empezar a llamar a estas funciones que viven en nuestro servicio de pagos. Y eso es prácticamente todo. Y luego en la parte inferior, tenemos nuestro JSX real que se está renderizando. Y cuando entras en el archivo de pruebas, verás que es muy básico el testing ahora. Estás testing JavaScript. No tienes que preocuparte por los comportamientos asíncronos, o no tienes que preocuparte por los ciclos de vida del componente. No necesitas usar la biblioteca de testing para probar la lógica central del negocio que tienes. Es muy simple. Así que lo que eso significa finalmente es que pasas menos tiempo escribiendo las pruebas, y puedes escribir pruebas más efectivas porque estás comprobando directamente la lógica del negocio. Así que tenemos apply a discount for more than $50. Es muy simple. Le pasas un array de artículos, y te devuelve los artículos con un atributo añadido para el precio con descuento. Y luego algunas cosas más sobre no hay descuento por menos de $50. Y la prueba de la etiqueta de entrega, realmente solo estamos comprobando la función que toma los artículos y devuelve la cadena de lo que va a ser la etiqueta. Así que estamos testing lo que realmente es fundamentalmente importante para nosotros. Genial. Necesito dejar de reflejar. Genial. Así que eso es el modelo de objeto humilde. Veamos el modelo vista presentador.

8. Arquitectura tipo MVC y el Modelo MVP

Short description:

Esta es una arquitectura tipo MVC que utilizan las bibliotecas de interfaz gráfica de usuario. La vista es una vista pasiva que se renderiza en función de los valores de entrada. Se coloca un presentador entre el modelo y la vista para manejar el estado de la interfaz de usuario y convertir los datos del modelo. El estado y la lógica de la interfaz de usuario se trasladan fuera del componente a un hook llamado useComponent. Las pruebas se pueden realizar en el hook o en el componente de la interfaz de usuario. La regla de un hook por pantalla abstrae el estado y la lógica de la interfaz de usuario en un hook funcional. El ejemplo de codificación evoluciona para usar el modelo MVP con el objeto de pago.

Esta es una arquitectura tipo MVC que utilizan las bibliotecas de interfaz gráfica de usuario. Y básicamente está separando partes de tu interfaz gráfica de usuario. Tienes el modelo, que contiene la lógica de negocio, contiene la obtención de data, y luego tienes la vista. Ahora, lo que hacemos aquí es hacer de la vista una vista pasiva. Lo que significa es que la vista en sí no tiene ninguno de su estado o lógica de interfaz de usuario. Todo lo que hace es que es como una función. Toma una entrada con ciertos valores, y se renderiza en consecuencia. Es muy funcional en el enfoque que hace.

Y en el medio, entre el modelo y la vista, lo que insertas es un presentador. La idea con este presentador es que este presentador contendrá todo tu estado de interfaz de usuario. Manejará la conversión del estado de la interfaz de usuario. Manejará la conversión de los datos del modelo a un formato y una forma que coincida con lo que quieres renderizar en la vista. Entonces, ¿qué significa eso en la práctica? Si miramos nuestro ejemplo aquí de nuevo, hemos tomado todo y lo hemos puesto en un objeto humilde. Lo que esto también significa es que vamos a tomar el infracódigo, y también el estado y la lógica de la interfaz de usuario, y también sacar eso del componente. Y lo que vamos a hacer es que vamos a ponerlo dentro de un hook que vive fuera del componente en sí. Y esto va a ser useComponent, como se llame tu componente. Y contendrá el infracódigo, pero también tu estado de interfaz de usuario y tu lógica. Y también hará las referencias a tu objeto humilde también. Y ahora en este punto, realmente queda a tu discreción lo que quieras probar. Podrías probar el hook. O podrías probar el componente de interfaz de usuario real si realmente quisieras asegurarte de que la interfaz de usuario se comporta de cierta manera. Una forma sencilla de hablar de esto, especialmente con el resto del equipo, es una simplificación para decir que tienes una regla de un hook por pantalla. Lo que eso significa es que cada componente de pantalla solo debería estar llamando a un solo hook en cualquier momento. Y abstraes todo tu estado y lógica de interfaz de usuario en ese hook. Y realmente lo hace funcional. Y veremos cómo evoluciona nuestro ejemplo de codificación para manejar esto.

Genial. Misma aplicación exacta. Pero vamos a ver realmente el modelo MVP. Así que hemos abstraído nuestro objeto humilde en payment.

9. Hook de la App y Pruebas Simplificadas

Short description:

Volvamos a la app ahora y veamos cómo se ve. Hemos creado un hook llamado shoppingCart.hook.js, llamado useShoppingCart, que ha movido la parte difícil del componente. El app.jsx ha bajado a unas 38 líneas. Todavía tenemos nuestras pruebas de pago y hemos probado toda la lógica de negocio. Al abstraer todo en un hook, solo necesitamos un mock, simplificando las pruebas porque no tenemos que preocuparnos por simular todas las dependencias.

Volvamos a la app ahora y veamos cómo se ve. Lo que hemos hecho es que hemos creado un hook llamado shoppingCart.hook.js. Se llama useShoppingCart. Esa es la página que tenemos. Y toda la parte difícil del componente realmente ha sido trasladada aquí. Así que tenemos nuestro use state aquí, el useEffect para poblar los valores. Las llamadas al servicio de pago se han movido aquí también, así que al objeto humilde. Y luego nuestras callbacks para eliminar y añadir items. Y luego hemos calculado el costo de envío. Y lo que hacemos es que devolvemos un objeto en este hook, en este hook personalizado, que tiene los items transformados. Tiene el total y todo lo demás que necesitamos en la UI para renderizar correctamente.

Y volveremos a nuestro app.jsx. Y en realidad ha bajado a unas 38 líneas. Y todo lo que hace es que llama a este hook y obtiene los data que se requieren para renderizar desde el hook. Y luego simplemente lo renderiza de manera muy sencilla. Es muy funcional. Está saliendo. Y eso es todo lo que hace. Y lo que eso significa fundamentalmente es que todavía tenemos nuestras pruebas de pago. Hemos probado toda la lógica de negocio. Pero aparte de eso, si queríamos probar cómo se ve la UI, tal vez realmente queríamos asegurarnos de que el tachado se renderizaba cuando los precios originales ya no son aplicables y tienes un descuento. Lo que podemos hacer es que solo necesitamos un mock aquí. Y esto es realmente fundamentalmente importante cuando empiezas a tener estos componentes complejos que necesitan analíticas y sentry y así sucesivamente añadidos. Tienes muchas cosas para simular. Y al abstraer todo en un hook, siempre tienes como máximo un mock, que es el hook real que estás pasando a ese componente específico. Y lo que le decimos es, en este caso, simplemente devuelve esto como la salida del hook. Estos son los data que quiero que mi pantalla obtenga. Y luego todo lo que estoy haciendo es que estoy renderizando la app y luego comprobando muy rápidamente para ver si este elemento existe dentro del DOM. ¿Correcto? Así que es mucho más sencillo probarlo porque no tienes que preocuparte por simular todas las dependencias. Es solo aquí está el hook y aquí está el valor que el hook va a devolver.

10. El Pozo del Éxito

Short description:

La idea es alentar a tu equipo y a los desarrolladores a caer en el pozo del éxito, donde los sistemas bien diseñados facilitan seguir buenos patrones y tener éxito.

Genial. ¿Por qué es esto importante? La idea con esto es que quieres alentar a tu equipo y a tus desarrolladores a caer en el pozo del éxito. Así que hay este gran artículo que recomendaría mucho leer que se llama Cae En el Pozo del Éxito. Es del cofundador de Strack Overflow. Y habla de cómo C++ es básicamente un pozo de fracaso o un pozo de perdición. Si cometes un error en una aplicación C++, las consecuencias son enormemente graves y no hace nada para salvaguardarte o protegerte de caer en el pozo de la perdición. Mientras que un buen lenguaje de programación o un buen marco de trabajo o una buena architecture, una buena base de código te preparará para el pozo del éxito. La idea es que creas estos sistemas bien diseñados que hacen que sea realmente fácil caer en buenos patterns. Todavía puedes permitir que las personas escapen de esos buenos patterns, pero lo haces bastante difícil para hacerlo. Así que animas a las personas a caer en el pozo del éxito. Se vuelve muy fácil para ellos tener éxito.

11. Resumen e Importancia de Enseñar Principios

Short description:

Fomentar el código limpio y la arquitectura puede reducir el desperdicio en las pruebas y mejorar la organización y escalabilidad del código. Aislar la lógica de negocio en objetos humildes simplifica las pruebas de componentes críticos. Usar una capa de presentador permite vistas pasivas fácilmente comprobables. Enseñar estos principios a tu equipo los prepara para el éxito en las pruebas de componentes complejos.

Genial. Así que hagamos un resumen y mi tiempo se ha terminado. Los cuatro puntos principales son, en primer lugar, quieres fomentar el código limpio y la architecture y realmente puede ayudarte a reducir el desperdicio en tu testing junto con todos los beneficios que te brinda en términos de organización de tu base de código y scalability. Si aíslas la lógica de negocio importante en objetos humildes, puedes hacerlo muy fácil para probar los componentes críticos de tu aplicación muy rápidamente. Usar una capa de presentador puede hacer vistas pasivas fácilmente comprobables. Otro nombre para estas vistas son las vistas pasivas y puedes hacerlo realmente fácil para probarlas porque no tienen ninguna dependencia de data. Y por último, y creo que esta es la parte clave, habrá muchos desarrolladores más experimentados aquí. Todos ustedes conocen estos conceptos. Estas son cosas fundamentales que aprendes a lo largo de los años al convertirte en ingeniero de software, pero en realidad enseñar estos principios a tu equipo y hablar explícitamente sobre ellos con tu equipo te ayudará a prepararlos para el pozo del éxito y, con suerte, hacerlo menos intimidante para ellos al probar, especialmente cuando se trata de componentes complejos.

12. Pruebas de Hooks de Componentes Utilizados

Short description:

Probar un hook de componente utilizado puede ser desafiante y puede requerir aislar partes difíciles de probar dentro del hook. El blog de Martin Fowler sugiere probar los bits importantes de forma aislada y usar pruebas de extremo a extremo o pruebas de humo para asegurar las conexiones y el cableado adecuados. Aunque esta parte puede ser más difícil de probar, combinarla con un marco de pruebas robusto puede proporcionar cobertura de código.

Muchas gracias a todos por escuchar. Ese es mi Twitter y LinkedIn en caso de que quieras mantenerte conectado. Y sí, agradezco todo su tiempo. Una de mis cosas favoritas de ser un MC es que siempre puedo hacer la primera pregunta. Siempre. Una de las cosas que amo es que he hecho la architecture o patrón de componente utilizado antes. Pero, ¿cómo pruebas un hook de componente utilizado? Con mucho dolor. Solo sangre, sudor y lágrimas. Sí, sí, sinceramente. No lo intentes. No. Bueno, puedes probar el hook. Obviamente, has aislado muchas de tus partes difíciles de probar dentro del hook. Hay diferentes opciones y realmente depende. Sé que esa es la respuesta evasiva. Parte de la teoría que leerás si vas al blog de Martin Fowler sobre objetos humildes es que estás testing los bits importantes de forma aislada y luego usando algún tipo de pruebas de extremo a extremo o algún tipo de prueba de humo, lo que puedes hacer es asegurarte de que todas las conexiones y el cableado debajo del capó funcionen bien. Así que combínalo con un buen marco de pruebas de extremo a extremo y puedes asegurarte de que tu código esté cubierto. Pero sí, tienes esa parte, que es mucho más difícil de probar, ¿verdad? Por supuesto. Por supuesto.

QnA

Importancia de la Regla de Un Hook por Componente

Short description:

Muchas preguntas giran en torno a la regla de un hook por componente. Es una pieza de enseñanza para hacer que la gente piense en ello, especialmente para los desarrolladores junior. La regla es simple: no añadir más de un hook para cada pantalla o componente. Es una forma de introducir el modelo MVP y crear un pozo de éxito.

Y así tenemos un par de preguntas. Muchas de ellas son sobre la regla de un hook por componente. Así que voy a agruparlas todas si eso está bien, que es en primer lugar, ¿por qué es importante? ¿Y luego tienes algún método para crear reglas de linter para hacerla cumplir? Esa es una buena pregunta. De hecho, hemos hablado de las reglas del linter. No tenemos una regla de linting. Simplemente usamos el proceso de revisión de código para asegurarnos de que nos adherimos a ella. Pero creo que sería muy valioso tener una regla de linting para ello. Simplemente no hemos invertido el tiempo para hacerlo. ¿Por qué la regla es tan importante? Creo que no es la regla en sí. Es una regla que empieza a hacer que la gente piense en ello. Es una regla muy simple para dar a un desarrollador junior que no tiene mucha experiencia. Para decirles, no añadas más de un hook para cada pantalla o para cada componente. Es una forma muy simple de empezar a tener esta conversación. Así que creo que es más una pieza de enseñanza que cualquier otra cosa. No es una regla estricta y rápida per se, sino simplemente una pieza de enseñanza. Es una bonita forma de formular este concepto del modelo MVP. Es un pozo de éxito. Un pozo de éxito. Muchas gracias.

Siguiendo Patrones y Estandarización

Short description:

Intentamos seguir estos patrones en proyectos Greenfield y apuntamos a ir en esa dirección en proyectos existentes. La estandarización de patrones facilita que las personas trabajen en múltiples proyectos y ayuda con la formación. Definitivamente ayuda.

Vale. Y alguien preguntó, y supongo que la respuesta a esto es sí, ¿sigues estos patterns tú mismo? No, soy un hipócrita. Intentamos hacerlo, especialmente en proyectos Greenfield, definitivamente intentamos seguir estos patterns cuando estamos configurando la base de código. En proyectos que ya existen y en los que entramos, es un poco más difícil obviamente porque tienen sus propias configuraciones. Pero eventualmente lo que intentamos hacer es ir en esa dirección. Y a veces es más difícil. A veces es más fácil. Realmente depende de lo que ya existe. Pero sí, realmente intentamos hacer esto. Lo que eso también significa para nuestro caso, especialmente como consultoría, es que las personas trabajarán en, en un solo año, tal vez trabajarán en 12 proyectos diferentes, ¿verdad? A veces la rotación de proyectos es rápida. Algunos de ellos son más largos, pero muchos de ellos serán de corta duración. Y a medida que estandarizas estos patterns, las personas tendrán un tiempo mucho más fácil para entrar y salir de los proyectos. Y eso es genial para nuestros clientes también porque significa que es muy fácil capacitar a las personas porque tienes reglas y tienes marcos de pensamiento consistentes, mentalidades y todo alrededor de ello. Así que creo que definitivamente ayuda. No, tiene sentido. Tiene sentido.

Evitando la Burocracia y Fomentando la Educación

Short description:

Como líder técnico, es importante empoderar y educar a otros en la implementación de patrones y buenas prácticas. Evitar la burocracia implica encontrar un equilibrio entre hacer cumplir las reglas y utilizar la educación como herramienta de formación. La sabiduría colectiva del equipo nos guía hacia el mantenimiento de una buena base de código.

Entonces, has hablado un poco sobre esto, especialmente porque no solo lo estás haciendo para ti mismo. Eres un líder técnico. Estás empoderando a otros, educando a otros para implementar estos patterns y muchas otras cosas en la escala. ¿Y cómo evitas la burocracia con esto? Como que muchas personas diferentes tienen muchas opiniones diferentes. A menudo también ves en las preguntas, ¿cómo evitas esa burocracia? Es una pregunta interesante. Porque sí, hay una línea fina entre hacer estos mandatos que son como, tener este porcentaje de cobertura de pruebas. Sabes, como un ejemplo, o estas son las reglas dentro de nuestra base de código y vamos a apegarnos a ellas sin importar qué. Y hay otra cosa, enseñar a las personas sobre buenas prácticas y luego usarlo más como una pieza educativa. Y creo que la actitud que tenemos es que es una pieza educativa. Es una pieza de formación más que reglas impuestas. Así que sabes, nadie recibe un golpe en la muñeca si no usan, si tienen dos hooks en sus componentes o cualquier cosa. Es muy orientado a la formación. Está muy orientado hacia el aprendizaje y la enseñanza. Y es más que la sabiduría colectiva nos guiará hacia ese ideal de tener una buena base de código.

Uso de Hooks Personalizados y Compartiendo Lógica de Negocio

Short description:

Como líder, es importante tener la habilidad de asegurarse de que solo se use un hook. Puedes lograr esto creando un hook personalizado que llama a los demás. Este patrón de React mejora la legibilidad y reutilización del código. Es especialmente beneficioso en una estructura de monorepo, donde la misma lógica de negocio central puede ser compartida entre aplicaciones separadas de React Native y React. Herramientas como TurboRepo o NX te permiten usar la misma lógica exacta sin duplicar el código. La abstracción de los hooks en módulos separados proporciona beneficios adicionales.

Sí, eso tiene mucho sentido. Totalmente tiene sentido. Creo que especialmente como líder, esa es una buena habilidad para tener. Y la siguiente pregunta vuelve al ejemplo de un solo hook. Entonces, ¿cómo te aseguras de que solo tienes un hook? ¿Creas un hook que llama a los demás? Sí. Es un hook personalizado que llama a los demás. Definitivamente échale un vistazo si tal vez este es un patrón de React que es nuevo para ti. Es bastante genial y hace que tu código sea mucho más legible y reutilizable. Así que personalmente también lo recomendaría. Una de las cosas interesantes con esto es que si trabajas en una estructura de monorepo, digamos que tienes una aplicación de React Native y una aplicación de React que son totalmente separadas entre sí. A menudo, la lógica de negocio central va a ser la misma. Y si empiezas a tomar estos y los conviertes en hooks personalizados, lo que puedes hacer con una herramienta útil como TurboRepo o NX es en realidad usar la misma lógica de negocio exacta para tus aplicaciones web y tus mobile apps sin tener que codificarlo dos veces. Así que hay otros beneficios al abstractarlos y ponerlos en sus propios modules también, que son subproductos de tener una regla como esta.

Señales y Conceptos de Ingeniería de Software

Short description:

¿Podrías usar señales en lugar de...? No en React, no podrías porque las señales no tienen soporte oficial en React. Pero estos conceptos son como conceptos fundamentales de ingeniería de software. No creo que sean solo aplicables al código de React. Creo que son particularmente relevantes cuando hablas de React porque es este modelo basado en componentes en el que puedes meter todo en un componente.

Bien, bien. La siguiente pregunta con la gente que ama a React aquí, la gente está muy informada sobre él. Y esta es también una pregunta de React. ¿Podrías usar señales en lugar de...? No en React, no podrías porque las señales no tienen soporte oficial en React. Pero estos conceptos son como conceptos fundamentales de ingeniería de software. No creo que sean solo aplicables al código de React. Creo que son particularmente relevantes cuando hablas de React porque es este modelo basado en componentes en el que puedes meter todo en un componente. Pero otros frameworks podrían tener patrones un poco más opinados. Si te adentras en Angular, obtendrás un modelo MBC por defecto, al menos cuando usé Angular en el pasado. Y por lo tanto, es mucho más opinado y te guía en esos patterns. Estoy seguro de que puedes implementar algo como esto con Svelte o con Solid o lo que sea que tengas. Depende de la respuesta para la sesión, ¿verdad? Siempre hay una. Y creo que esto es una de las cosas interesantes cuando vienes a las charlas. Porque una persona te habla sobre una tecnología y tal vez te cuenta un caso de uso específico. Pero necesitas un poco de todo. Y hablaste de esto, como React, React Native. Y estás dando esta charla específicamente desde la perspectiva de alguien que está preparando pruebas y aplicaciones para encajar en ambos mundos. Y eso no necesariamente puede ser lo mismo para ti. Así que definitivamente conocer todas las opciones en la mesa también es bastante útil.

El Peligro de Múltiples Hooks

Short description:

Tener más de un hook por componente agrega más dependencias y dificulta seguir un patrón. Se recomienda aislar múltiples hooks personalizados en una sola capa para simplificar la base de código.

Pasemos al siguiente. Esto es, de nuevo, sobre un hooks. ¿Cuál es el peligro de tener más de un hook por componente? Bueno, de nuevo, estás empezando a agregar más dependencias. Puedes dividir los hooks en diferentes hooks. Digamos que tienes dos hooks personalizados que usan diferentes cosas. Pero es solo este concepto de crearlo simple para seguir un patrón dentro de la base de código. Y si tienes múltiples hooks personalizados que necesitan referirse entre sí, yo los aislaría en una sola capa. Simplemente porque lo hace mucho más fácil. Es muy claro. Hay un solo punto de entrada para todos los data en tu componente. Y luego simplemente se alimenta en el JSX, y se renderiza allí. Así que incluso si necesitas múltiples hooks, simplemente ponlos todos en una capa de un hook personalizado, diría yo.

Herramientas de IA y Aplicación de Conceptos a Otros Marcos

Short description:

Las herramientas de IA como Copilot y GPT pueden ser útiles para refactorizar el código y separar la lógica de negocio del JSX. Pueden ayudar en el proceso de revisión de código y automatizar partes mecánicas de nuestro trabajo. Aunque estas herramientas aún están en desarrollo, tienen el potencial de hacer nuestro trabajo menos intensivo en tiempo. Los conceptos discutidos en esta charla pueden aplicarse a otros marcos basados en componentes, como SwiftUI, pero pueden no ser tan aplicables a marcos de UI imperativos como UIKit.

Genial. Entonces, a partir de ahora, si quieres hacer una pregunta sobre un hook, lo que voy a hacer es decirte que consultes a Mo en el Discord en la sala de discusión de los ponentes después. Pero tenemos un montón de otras preguntas. Como una, específicamente, esto es algo sobre empoderar a tu otro equipo, y todas estas personas, tal vez personas que están al principio de su career como desarrolladores. Y entonces esta persona ha preguntado, ¿has usado Copilot o GPT para ayudar a todos a adherirse a estos patterns? ¿O para autoverificar que tienen estos patterns? ¿Y has encontrado alguna utilidad en ello? No en la etapa de revisión de código, o en mí mismo para la etapa de redacción real. Pero ha sido útil para las refactorizaciones, en realidad. Así que si entras en un código base, y tienes estos componentes, y a veces se convierte en algo mecánico refactorizarlos en estas reglas de un hook por pantalla, ChatGPT puede ser bastante bueno en tomarlo y separar la lógica de negocio del JSX para ti de una manera bastante automatizada porque es bastante simple y directo hacer eso. Es muy mecánico una vez que aprendes a hacerlo. Y esto se siente como algo muy nuevo, porque todas estas herramientas de IA son bastante nuevas. Aunque están siendo adoptadas muy, muy rápidamente, ¿ves algo cambiando en el futuro con la forma en que usamos las herramientas de IA para ayudar a refactorizar, o algo así como autoverificar estas? Creo que realmente pueden ayudar con el proceso de revisión de código. Así que tengo un colega, su nombre es Matt. Ha estado trabajando en esta biblioteca de GitHub llamada Code Review GPT. Puedes buscarla si estás interesado. Es algo así como la idea de, ¿podemos añadirla al proceso de revisión? Todavía está muy en proceso. No está perfeccionado, pero creo que va a ser realmente bueno en el aspecto de que no va a reemplazar lo que hacemos día a día, pero esperemos que pueda señalar algunas de las partes más mecánicas y metódicas de nuestro trabajo, hacer eso un poco menos intensivo en tiempo, y automatizar esa parte de él.

Genial. Muy bien. Tenemos tiempo para una pregunta más. La pregunta es, eres un especialista en React, React Native, pero aquí la gente, tal vez ellos trabajan en otros frameworks. ¿Cómo pueden tomar algunos de estos patterns y cosas de las que has hablado, y luego hablaste sobre, especialmente cuando hablamos de la pregunta de las señales, pero tal vez cuáles son algunos de los conceptos que dirías, estas son las cosas que necesitas recordar y aplicar en tu marco? Y tal vez podemos emparejarlo con la siguiente pregunta es, ¿por qué esta charla es una React Native y no solo React y Amigos? Eso se debe a mi pobre marketing y a no pensar en cómo esto puede ser aplicable a otras cosas. Pero en términos de cómo aplicas estos a otros frameworks, ¿o los aplicaría? Creo que sí. Sí. Y definitivamente tiene un gran lugar en estas bibliotecas de UI basadas en componentes, como React. Creo que puedes llevar esto fácilmente a otros frameworks que están basados en componentes. Si te metes en pilas front-end más opinadas, como si, digamos, quisieras escribir un componente dentro de, digamos, SwiftUI, creo que SwiftUI también puede tomar muchos de estos conceptos y aplicarlos a ellos, porque está muy basado en la mentalidad de React, y se inspiró en eso. Pero digamos que entraste en algo como una aplicación de UI kit en una aplicación iOS. Es un poco más difícil hacer eso, porque todo el encuadre de cómo design las UI es muy diferente. Es imperativo. No se comporta de la misma manera. Así que creo que es realmente aplicable a otros frameworks basados en componentes. Gracias. Sabes, es una gran charla cuando las preguntas se ramifican en tantas otras posibilidades. Gracias por mostrarnos todas estas posibilidades. ¡Demos un gran aplauso a Mo!

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

TestJS Summit 2021TestJS Summit 2021
31 min
Test Effective Development
Developers want to sleep tight knowing they didn't break production. Companies want to be efficient in order to meet their customer needs faster and to gain competitive advantage sooner. We ALL want to be cost effective... or shall I say... TEST EFFECTIVE!But how do we do that?Are the "unit" and "integration" terminology serves us right?Or is it time for a change? When should we use either strategy to maximize our "test effectiveness"?In this talk I'll show you a brand new way to think about cost effective testing with new strategies and new testing terms!It’s time to go DEEPER!
TestJS Summit 2023TestJS Summit 2023
29 min
Component Testing With Vitest
Testing is important. Proper unit tests can eliminate the chance for bugs to appear. But which testing framework will be suitable? Let’s explore how we can develop a reliable and efficient strategy for component development and testing with Vitest
TestJS Summit 2021TestJS Summit 2021
20 min
It's a (Testing) Trap! - Common Testing Pitfalls and How to Solve Them
It’s a trap” - a call or feeling we all might be familiar with, not only when it comes to Star Wars. It’s signalizing a sudden moment of noticing imminent danger. This situation is an excellent allegory for an unpleasant realization in testing. Imagine having the best intentions when it comes to testing but still ending up with tests failing to deliver you any value at all? Tests who are feeling like a pain to deal with?
When writing frontend tests, there are lots of pitfalls on the way. In sum, they can lead to lousy maintainability, slow execution time, and - in the worst-case - tests you cannot trust. But it doesn’t have to be that way. In this session, I will talk about developers’ common mistakes (including mine), at least from my experience. And, of course, on how to avoid them. Testing doesn’t need to be painful, after all.
TestJS Summit 2021TestJS Summit 2021
8 min
Who is Testing the Tests?
Have you ever wondered: "who's testing the tests"? Of course, tests are only valuable if they catch bugs, but how would one validate that? Well, let me tell you about mutation testing!
Mutation testing is the act of testing your test verifying that they catch bugs. Of course, you can do this manually inserting bugs and running the tests, but a mutation testing framework can do this for you!
Join me and learn the basics of mutation testing and how to use StrykerJS, the mutation testing framework for JavaScript or TypeScript.At the end of this talk, you'll be the one that is testing your tests, and it won't even cost you much time!
TestJS Summit 2022TestJS Summit 2022
11 min
Using Tests for What?!
In the talk I will explain the pains and problems of form validation Then I will explain the mental model of unit tests, and compare it to how we think about form validations.I will introduce vest with a bit of live coding showing its unit testing syntax.