Mockear o no mockear - Esa es la pregunta

Rate this content
Bookmark

Mockear o no mockear, esa es la pregunta. Si es más noble para el código de los programadores involucrarse con espías y stubs en pruebas extravagantes, o tomar los componentes reales contra un mar de tiempos de espera, y soportar, para validar su código: comprometerse, hacer push.

25 min
25 Oct, 2021

Video Summary and Transcription

Esta Charla discute el enfoque de SDC para el desarrollo de software utilizando metodologías ágiles y programación extrema. Se destacan los beneficios de la programación en pareja y el uso del diseño atómico en los componentes de React. Se enfatiza la importancia del desarrollo impulsado por pruebas y la biblioteca de pruebas de React, junto con la implementación de código, navegación y validación de formularios utilizando Formik y Yup. La charla también aborda las capas de abstracción en el desarrollo de software y las pruebas de los recorridos de usuario y la accesibilidad en la aplicación BookKeeper.

Available in English

1. Introducción a SDC y Desarrollo Ágil

Short description:

En esta charla, intentaremos responder a la pregunta de si hacer una simulación o no. Soy Rita, una apasionada de la tecnología, viviendo en Lisboa y trabajando en SDC. SDC es un centro de desarrollo de software establecido en 2018. Desarrollamos productos utilizando programación extrema, un marco ágil basado en la comunicación, simplicidad, retroalimentación, valentía y respeto. Trabajamos en equipos equilibrados, que incluyen diseñadores, gerentes de producto y desarrolladores. Realizamos desarrollo impulsado por pruebas.

♪ Hola, bienvenidos a esta charla. En ella, intentaremos responder una pregunta, que es, ¿hacer una simulación o no? Comencemos.

Mi nombre es Rita. Soy una apasionada de la tecnología. Vivo en Lisboa con mi hermosa familia. Mi hijo tiene casi tres años, así que es un poco travieso. Pero cuando no estoy ocupada con mi familia, probablemente estaré jugando, o estaré en SDC, el lugar donde trabajo. Trabajo con estas personas increíbles. Y actualmente, soy parte del Equipo Falcon, y las cosas están volviendo lentamente a la normalidad aquí en la oficina.

¿Dónde está la oficina? Es un centro de desarrollo de software aquí en Lisboa, y está justo en el centro de la ciudad. Se estableció en 2018. Fue el primer centro de desarrollo de software que Volkswagen abrió fuera de Alemania. Y hasta ahora, las cosas han ido muy, muy bien.

¿Qué hacemos aquí? Entonces, desarrollamos productos utilizando programación extrema. En pocas palabras, es un marco ágil que nos permite producir y entregar software de alta calidad a un ritmo muy rápido con una buena calidad de vida para nosotros, los desarrolladores, o para todo el equipo de desarrollo. Fue creado por Kent Beck en 1996. Así que es algo antiguo, pero los valores fundamentales en los que se basa, aún se mantienen. Comunicación, simplicidad, retroalimentación, valentía y respeto. Estos cinco pilares, también están grabados en el espíritu de SDC. Así que es una combinación perfecta.

¿Qué más puedo contarles sobre SDC? Entonces, trabajamos en equipos equilibrados, lo que significa que un equipo está compuesto por diseñadores, gerentes de producto y nosotros, los desarrolladores. Un equipo, permítanme también enfatizar esto, un equipo de producto, porque el equipo es más grande que solo los equipos de producto. Los diseñadores, ¿qué hacen? Entonces, mantienen contacto con los usuarios. Exploran, investigan, investigan posibles soluciones para los problemas de los usuarios. Los gerentes de producto traducirán estas necesidades de los usuarios en historias, y también mantendrán contacto con el negocio y verán si un producto es o no viable para ser desarrollado desde el punto de vista del negocio. Y nosotros, los desarrolladores, nos encargaremos de la viabilidad en términos de tecnología. Seremos los responsables de ver si algo se puede integrar con sistemas heredados, si algo se puede hacer utilizando tecnología de vanguardia. Si se trata de tecnología, ese es nuestro ámbito. En el medio de estos tres roles muy diferentes, es donde realmente sucede la magia y donde nacen buenos productos.

Entonces, ¿qué hacemos y cómo lo hacemos? Entonces, nosotros los desarrolladores, hacemos desarrollo impulsado por pruebas.

2. Beneficios de la Programación en Pareja

Short description:

En la programación en pareja, dos desarrolladores trabajan juntos en el mismo código simultáneamente. Esta práctica permite una revisión de código en tiempo real y una resolución inmediata de problemas, eliminando obstáculos y fomentando una colaboración eficiente.

Lo que significa que primero escribimos algunas pruebas, ejecutamos las pruebas, esperamos ver que las pruebas fallen. Pero si las pruebas pasan, las pruebas pasan. No, no deberían pasar. Tal vez hubo un error en la prueba, lo más probable. Entonces, para minimizar este tipo de situaciones, también participamos en la programación en pareja. Lo que significa que siempre tienes dos pares de ojos mirando el mismo código. Tenemos una computadora, dos teclados, dos ratones, dos pantallas, y así es como desarrollamos. No es necesario hacer revisiones de código porque el código se revisa en vivo a medida que avanzas. No te quedas bloqueado porque si te quedas bloqueado siempre habrá alguien contigo. Podrás expresar tus pensamientos, participar en una conversación de manera rápida y eficiente, podrás desbloquear el hilo de pensamiento que tienes. Así que funciona muy bien, tengo que admitirlo. Y no podría hacerlo de ninguna otra manera.

3. Books and Technological Solutions

Short description:

Voy a hablarles un poco sobre los libros. Los libros pueden llevarte a cualquier lugar y contarte historias que nunca podrás ver en la vida real. Tenemos una biblioteca en el SDC y es hora de llevarla al siglo XXI. Obtengamos una solución tecnológica para el bibliotecario y hagamos un par de bocetos para visualizar nuestros objetivos.

Entonces, yendo al núcleo de la presentación. Voy a hablarles un poco sobre los libros. Libros, ¿por qué? Bueno, los libros pueden llevarte a cualquier lugar. Pueden llevarte a lugares y contarte historias que nunca podrás ver en la vida real. Así que, también tenemos un poco de biblioteca aquí en el SDC. En realidad, son dos estanterías con libros, pero es una biblioteca. Así que podemos sacar libros de ella. Por lo tanto, tiene un sistema de gestión. ¿De qué está compuesto? Es un bloc de notas. Es un bloc de notas en el que escribimos nuestro nombre, el libro que tomamos y cuando lo devolvemos, lo tachamos. Así que, sí, un poco. Así que llevemos esto al siglo XXI, ¿de acuerdo? ¿Qué tal si cavamos en nuestras propias metodologías? En lugar de tener el bloc de notas, intentemos obtener una solución tecnológica para el bibliotecario. Así que hablemos con las personas que solicitan y desarrollan los libros y entregan los libros a las personas encargadas de mantener la biblioteca. Y hagamos un par de bocetos. Así es como visualmente intentaríamos lograr y cumplir. Fue un punto de partida.

4. MVP, Atomic Design, and Coding

Short description:

Entonces, obtengamos un MVP, un MVP adecuado. Necesitamos agregar libros, tomar prestados libros y devolver libros a la biblioteca. Utilizaremos el diseño atómico para organizar nuestros componentes de React, comenzando con átomos, moléculas, organismos y plantillas. Nos desviaremos de la metodología original al permitir que los organismos tengan plantillas. Comenzaremos a codificar con un lienzo en blanco y apuntaremos a lograr el desarrollo impulsado por pruebas al desarrollar la página para agregar un nuevo libro y seguir el flujo del usuario para agregar un libro a la biblioteca.

Entonces, obtengamos un MVP, un MVP adecuado.

Y de la investigación que hicimos, las cosas valiosas y las cosas que planteaban los problemas más relevantes para los usuarios eran poder agregar libros a la biblioteca, poder tomar prestados libros de la biblioteca y devolver libros de forma natural. Así que podemos agregar libros. Habrá una página para ellos. Sin embargo, dado que las personas tienden a ser un poco impacientes en el teclado, también tengamos alguna validación para asegurarnos de que todo esté correcto antes de enviarlo. Tengamos una página separada en la que podamos ver qué libros están disponibles en la biblioteca. Tengamos la posibilidad de tomar prestado un libro. Veamos qué libros hay en el mundo. Y tengamos la posibilidad de devolverlos a la biblioteca.

Estos son los bocetos que tenemos. Entonces, ¿qué sigue? ¿Cómo pasamos de estos bocetos a los componentes de React que desarrollaremos? Obviamente, desarrollaremos esto utilizando React. Entonces, ¿cómo pasamos de los bocetos a React y a nuestros componentes de React? Bueno, aquí entra en juego el diseño atómico. El diseño atómico es una forma de organizar tus componentes y tus elementos visuales como un sistema de diseño, muy probablemente. Y está estructurado de una manera muy sencilla y creciente o aumentando en complejidad. Tienes átomos, tienes moléculas, donde los átomos son los más simples, las moléculas son grupos de átomos unidos, los organismos son grupos de moléculas y átomos unidos, las plantillas serán el lienzo donde dices, ok, quiero tener esto aquí, esto allá, esto justo aquí abajo, y luego las páginas cuando instancias las plantillas. Así es como Brad Frost definió el diseño atómico en 2013. Sin embargo, hicimos algunos ajustes para nuestro propio uso. Así que nos quedamos con los átomos, sí, bien. A partir de nuestros diseños, los átomos también serán botones, algo muy simple. Las moléculas son grupos de átomos unidos o más de una etiqueta HTML juntas. Los organismos, como una tarjeta de libro o una plantilla para las páginas de las estanterías de libros, obtienes una plantilla y cuando instancias esa plantilla, cuando instancias la plantilla, terminas con las páginas de las estanterías de libros. Sin embargo, este es el momento en el que rompimos con la metodología original porque dijimos, ok, pero los organismos también pueden tener plantillas, lo cual es bastante genial, y como tal, tenemos nuestra desviación.

Ok, así que empecemos y comencemos a codificar. ¿Dónde? Podrás tener el repositorio que he utilizado para esta presentación disponible aquí, y comienza con algo muy simple, un lienzo en blanco con un encabezado, un contenido principal y luego el pie de página. ¿Qué queremos lograr con esto? Ok, estaremos haciendo desarrollo impulsado por pruebas. Desarrollaremos la página para agregar un nuevo libro y seguiremos el flujo del usuario para agregar un nuevo libro a la biblioteca. Todo bien. Empecemos.

5. Test-driven Development and UI Improvement

Short description:

El desarrollo impulsado por pruebas es crucial, y elegimos usar la biblioteca de pruebas de React para escribir pruebas que se asemejen a la forma en que se utiliza nuestro software. Comenzando con la página de nuevo libro, renderizamos los componentes y nos aseguramos de que el formulario tenga todos los elementos, incluido un botón de guardar deshabilitado. Inicialmente, las pruebas fallan debido a la falta de código de producción. Al corregir errores de ortografía y usar regex, nos aseguramos de que las pruebas pasen. Sin embargo, la interfaz de usuario aún necesita mejoras. Para abordar esto, escribimos pruebas adicionales y ajustamos la biblioteca de pruebas de React para simular y llamar a los componentes necesarios.

El desarrollo impulsado por pruebas, lo que significa que tendremos que escribir pruebas. Para escribir pruebas y tener al usuario en el centro de todo, hemos elegido usar la biblioteca de pruebas de React porque, como dijo Kenti Dodds de una manera muy elegante, cuanto más se parezcan tus pruebas a la forma en que se utiliza tu software, más confianza te brindarán. Y esto es algo con lo que nos identificamos y creemos que es una buena manera de seguir el desarrollo impulsado por pruebas.

Entonces, usaremos la biblioteca de pruebas de React para esto. Comencemos con la página de nuevo libro. ¿Qué tenemos aquí? Bueno, tenemos el formulario que contendrá el botón de guardar deshabilitado. Renderizaremos solo los componentes, o en este caso, la página, para tener lo mejor. Será el componente. El componente para tener el formulario para escribir un nuevo libro con todos los elementos, el encabezado, las diferentes secciones de entrada, los botones y, idealmente, tener el botón deshabilitado. Prueba sencilla.

Por supuesto, falla porque no hay nada, no hay nada. El componente está limpio. No hemos hecho ningún código de producción. Así que pongámonos manos a la obra. Cuando agregas algo de código de producción, vuelves a ejecutar las pruebas y tus pruebas siguen fallando. ¿Por qué fallan? Porque fuimos un poco permisivos con la prueba y la persona que implementó el código se retrasó un poco con la escritura. En lugar de tener 'author' correctamente escrito, fuimos algo creativos. ¿Por qué? Porque la prueba usaba regex, lo que nos permitió ser un poco flexibles con la definición de la cadena. Si lo corriges para la ortografía correcta, tu prueba pasa. Genial, ¿no? Pero somos desarrolladores front-end, así que siempre nos gusta ver cómo quedan las cosas.

Y así es como se ven las cosas, ¿no es genial? Entonces intentemos arreglarlo. ¿Cómo podemos arreglarlo? Podemos escribir otra prueba. Y en lugar de usar la biblioteca de pruebas de React tal como está destinada a usarse, ajustémosla un poco. ¿Recuerdas la molécula de entrada? Digamos que queremos llamarla. Simulémosla y digamos que queremos llamarla con los parámetros que esperamos ver. Hagamos lo mismo para los botones OK y Cancelar como molécula y sigamos adelante. Sí, lo sabemos. Obviamente no se llama. Así que llamémoslo.

6. Implementando Código, Navegación y Formic con YUP

Short description:

Cuando implementas el código, tu prueba pasa. Fácil. Misión cumplida. Y como bonificación, cuando ves cómo se ve, ta-da. Sí, esto es lo que queremos. Estamos avanzando. Además, cuando hacemos clic en el botón Cancelar, la investigación mostró que nos gustaría volver a la página de inicio. Para eso, usemos React Router DOM para poder navegar entre nuestras páginas. Te he mostrado dos formas diferentes de hacer esto para este componente simple, este formulario simple. Pros y contras. Cuando tienes formularios, mi consejo es que uses Formic en combinación con YUP para su validación. Está mejor probado, es increíble, debo decirlo, y es bastante fácil de familiarizarse con. Así que pongámonos manos a la obra con Formic y YUP.

Cuando implementas el código, tu prueba pasa. Fácil. Misión cumplida. Y como bonificación, cuando ves cómo se ve, ta-da. Sí, esto es lo que queremos. Estamos avanzando.

Además, cuando hacemos clic en el botón Cancelar, la investigación mostró que nos gustaría volver a la página de inicio. Para eso, usemos React Router DOM para poder navegar entre nuestras páginas. Así que esperemos que se haya llamado a history push. Realmente no se ha llamado, así que sí, sabemos que no se ha llamado, así que llamémoslo. Cuando lo llamamos, ambos sabemos que cuando lo llamamos en el callback para Uncancel, nuestra prueba se vuelve verde y todo está bien. Súper fácil. Muy fácil.

Te he mostrado dos formas diferentes de hacer esto para este componente simple, este formulario simple. Pros y contras. Cuando haces mock de los componentes, es fácil pasar de los diseños a los componentes que estás usando, lo cual es genial. No puedes hacer trampa con los componentes que usas, porque si quieres usar nuestro botón, usarás nuestro botón, no usarás la etiqueta HTML para el botón. Cuando renderizas tu componente, lo haces en un entorno controlado, por lo que puedes simular la navegación hacia atrás y hacia adelante o hacia donde quieras ir sin muchos problemas. Sin embargo, la desventaja es que tienes algunas representaciones superficiales, lo cual sé que va en contra de lo que representa la biblioteca de pruebas de React, pero nuevamente, pros y contras. Eventualmente, es posible que termines con algunas pruebas duplicadas aquí y allá. Lo cual está bien, y tienes un acoplamiento estrecho con los detalles de implementación. Dijimos que queremos usar React Router DOM. Eso es lo que vamos a usar para la navegación. Pros y contras. No hay una respuesta correcta o incorrecta aquí.

Continuando. Cuando tienes formularios, si esto es nuevo para ti, mi consejo es que uses Formic en combinación con YUP para su validación. Está mejor probado, es increíble, debo decirlo, y es bastante fácil de familiarizarse con. Así que pongámonos manos a la obra con Formic y YUP.

7. Formic Testing and Service Documentation

Short description:

En las pruebas, simulamos Formic y esperamos que se haya llamado. Sin embargo, decidimos usar Formic tal cual, sin simularlo. Nos enfocamos en la parte en la que vamos a enviar y probar el servicio para agregar un libro, que llama al endpoint slash-API slash books con los datos proporcionados.

En las pruebas, ¿cómo te aseguras de que estás usando Formic? Lo simulamos y esperamos que se haya llamado. Fácil. No se llama, sí, obviamente no se llama. Por supuesto que no, porque acabamos de introducirlo. Lo llamamos así, y la prueba pasa. Pero si solo fuera tan simple. Tal vez deberíamos leer un poco más sobre Formic. Entonces, en Formic obtienes el ejemplo básico, y a partir de ahí puedes ver fácilmente que necesitamos proporcionar más información a Formic, como los valores iniciales y lo que queremos hacer cuando enviemos el formulario, y hablando de enviar, eso es lo que queremos hacer. Pero el botón está desactivado. Queremos hacer clic en él. ¿Cómo lo hacemos, cómo habilitamos los botones? Bueno, investigando más, descubrimos que existe esta propiedad válida que va junto con dirty, y luego tendremos que ver cómo podemos usarla en los forms, pero espera. ¿Qué queremos hacer? ¿Queremos pasar tiempo aprendiendo a simular esta biblioteca de terceros? ¿O queremos pasar tiempo usándola? La respuesta es bastante simple, lo que significa que hablemos de ello. Necesitamos decidir qué queremos hacer. Y como equipo, hemos decidido que queremos usar Formic tal cual, sin simularlo. Vamos a por ello de manera justa y directa, y así lo hacemos. Entonces, en lugar de tener todos los forms, nos enfocamos en la parte en la que vamos a enviar. Entonces, cuando vayamos a enviar, tendremos un servicio para agregar el libro, y esperaremos que se haya llamado, pero obviamente no se llama. Entonces, si vamos al formulario que ya está completado con más cosas de Formic, llamamos a add book. Y tenemos una prueba verde que pasa. Así de fácil. No hay problema. Pero, ¿qué es esto? ¿Qué es este servicio? Este servicio está documentado a través de las pruebas. Así que es otra ventaja del desarrollo guiado por pruebas. Las pruebas son tu documentación. Serán tu referencia para las cosas y la información que necesitas extraer. Entonces, el servicio para agregar un libro es simplemente un servicio que llama al endpoint slash-API slash books con los datos proporcionados. Solo eso, no mucho. Ahí lo tienes. Llama al fetch que proviene de un servicio de fetch que a su vez es algo que tenemos en BookKeeper que encapsula la API de fetch. Así que hay un par de capas aquí.

8. Layers and Abstraction in Software Development

Short description:

Pero Trek nos dijo que las capas son buenas. Las capas son geniales. ¿Por qué tenemos capas? Cuando tienes capas en este caso, obtienes mucha abstracción. Puedes ignorar las bibliotecas o APIs específicas que estás utilizando y centrarte en el servicio de fetch. Simular el servicio facilita las pruebas, pero es posible que necesites investigar para comprender los servicios y sus ubicaciones.

Pero Trek nos dijo que las capas son buenas. Las capas son geniales. ¿Por qué tenemos capas? Procon. Cuando tienes capas en este caso, obtienes mucha abstracción aquí. Por lo tanto, puedes ignorar si estás utilizando la API de fetch, axios, node fetch, una biblioteca que hayas creado tú mismo. Realmente no nos importa. Está oculto, escondido debajo del servicio de fetch que se utiliza en toda la aplicación. Y estás bien con eso. Y también estás bien simulándolo. Entonces, en lugar de intentar simular todos los lugares donde utilizas la biblioteca, simplemente puedes simular la llamada al servicio. Esto facilita mucho las pruebas. Sin embargo, terminarás investigando que necesitarás hacer si quieres entender cuáles son los servicios y dónde se encuentran.

9. Testing User Journey and Accessibility

Short description:

Ahora podemos centrarnos en todo el recorrido de Bob utilizando la aplicación BookKeeper. Renderiza toda la aplicación sin simular, excepto Global Fetch. Al centrarte en el recorrido del usuario, puedes probar los componentes de React y la navegación. Este enfoque te permite simular una prueba de extremo a extremo sin necesidad de un backend en ejecución. También puedes priorizar la accesibilidad y probar la aplicación desde la perspectiva del usuario.

Para resumir, ahora podemos centrarnos en todo el recorrido de Bob. Bob quiere usar BookKeeper. Quiere usar BookKeeper, que es el nombre de nuestra aplicación, si no te has dado cuenta. Renderiza toda la aplicación, todo. Sin simulación alguna, excepto Global Fetch, que es la parte más importante de tu aplicación, cuando simulas esta parte más importante. Puedes enfocarte mucho, mucho en el recorrido del usuario. Recórrelo con fluidez a través de las bibliotecas de pruebas de React, y por supuesto, la prueba fallará debido al desarrollo basado en pruebas. Recuerda, comenzamos con un lienzo en blanco en BookKeeper. Así que agreguemos cosas. Agreguemos la navegación con React RouterDOM, cambiando entre la página de inicio, la página para agregar nuevos libros, y eventualmente la página para tomar prestados libros. Las cosas pasarían. Pros y contras en este enfoque. Probablemente puedas decir que, sí, eso se parece mucho a una prueba de extremo a extremo, y podríamos hacer esto usando Cypress en lugar de la biblioteca de pruebas de React en el desarrollo front-end. Sí, podrías. Pero si lo haces así, en realidad puedes enfocarte en el recorrido del usuario, algo que también podrías hacer en la prueba de extremo a extremo. Justo. Pero en este caso, no tienes que preocuparte por tener un backend en funcionamiento. Solo necesitas tener en cuenta cuáles son los puntos finales, y cuál es la interfaz que tu backend te proporciona. Luego simplemente puedes simular las respuestas que deseas tener. También puedes centrarte en la accesibilidad. Puedes probar toda tu aplicación a través de los ojos del usuario, cómo percibe tu aplicación, y eso es algo realmente valioso. Los contras de esta parte... Realmente no encontré ninguno, así que, lo siento. Para resumir, comenzamos haciendo la pregunta, ¿debemos simular o no? Me gustaría poder decirte que tengo una respuesta, pero la realidad honesta es que no lo sé. Hay casos en los que es mejor simular, hay casos en los que es mejor usar el verdadero. Depende de ti encontrar tu equilibrio, ver qué funciona mejor para ti y para tu equipo, y luego hacer lo que te parezca correcto. No hay una respuesta correcta o incorrecta, solo encuentra tus equilibrios, seguro. Hay casos en los que es más beneficioso simular, hay casos en los que es más beneficioso no simular, pero eso surge de la experiencia, y es algo que solo tú puedes descubrir. Así que eso sería todo. Muchas gracias por escuchar. Si tienes preguntas, adelante. ¡Adiós!

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

React Advanced Conference 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Top Content
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Top Content
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Advanced Conference 2021React Advanced Conference 2021
47 min
Design Systems: Walking the Line Between Flexibility and Consistency
Top Content
Design systems aim to bring consistency to a brand's design and make the UI development productive. Component libraries with well-thought API can make this a breeze. But, sometimes an API choice can accidentally overstep and slow the team down! There's a balance there... somewhere. Let's explore some of the problems and possible creative solutions.
TestJS Summit 2021TestJS Summit 2021
33 min
Network Requests with Cypress
Top Content
Whether you're testing your UI or API, Cypress gives you all the tools needed to work with and manage network requests. This intermediate-level task demonstrates how to use the cy.request and cy.intercept commands to execute, spy on, and stub network requests while testing your application in the browser. Learn how the commands work as well as use cases for each, including best practices for testing and mocking your network requests.
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar
TestJS Summit 2021TestJS Summit 2021
38 min
Testing Pyramid Makes Little Sense, What We Can Use Instead
Top Content
Featured Video
The testing pyramid - the canonical shape of tests that defined what types of tests we need to write to make sure the app works - is ... obsolete. In this presentation, Roman Sandler and Gleb Bahmutov argue what the testing shape works better for today's web applications.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
TestJS Summit 2022TestJS Summit 2022
146 min
How to Start With Cypress
Featured WorkshopFree
The web has evolved. Finally, testing has also. Cypress is a modern testing tool that answers the testing needs of modern web applications. It has been gaining a lot of traction in the last couple of years, gaining worldwide popularity. If you have been waiting to learn Cypress, wait no more! Filip Hric will guide you through the first steps on how to start using Cypress and set up a project on your own. The good news is, learning Cypress is incredibly easy. You'll write your first test in no time, and then you'll discover how to write a full end-to-end test for a modern web application. You'll learn the core concepts like retry-ability. Discover how to work and interact with your application and learn how to combine API and UI tests. Throughout this whole workshop, we will write code and do practical exercises. You will leave with a hands-on experience that you can translate to your own project.
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Top Content
WorkshopFree
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up