Probando React Hooks con Confianza

Rate this content
Bookmark

La charla se presentará como una historia de refactorización: comenzará desde el componente desordenado e inprobable, lo cubrirá con una prueba de humo frágil y luego mostrará cómo mover toda la lógica del componente React a un hook personalizado y probar este hook. Se presentarán patrones para probar cosas como useState, efectos y Apollo.

7 min
15 Jun, 2021

Video Summary and Transcription

La charla trata sobre la prueba de hooks en una aplicación de React. El orador comienza mostrando una aplicación de React no probada y comienza a probarla con una prueba de marcador de posición simple. Se enfatiza la importancia de refactorizar y probar hooks personalizados, con la recomendación de usar la biblioteca de hooks de React y lograr una cobertura de prueba completa. Las pruebas unitarias de los componentes de React pueden no ser valiosas, ya que la complejidad radica en el código del hook. En su lugar, se recomienda realizar pruebas de extremo a extremo con herramientas como Cypress.

Available in English

1. Introducción a la Prueba de Hooks

Short description:

Hola a todos. Mi nombre es Radoslav Stankov. Hoy vamos a hablar sobre la prueba de hooks con confianza. Voy a mostrarles esta aplicación de React sin probar. Podemos comenzar con una prueba simple y pequeña. Esta es solo una prueba de marcador de posición para asegurarnos de que cuando refactorizamos, no rompamos algo.

Hola a todos. Mi nombre es Radoslav Stankov. Pueden encontrarme en línea aquí. Soy el jefe de ingeniería en Product Hunt y actualmente me encuentro en Bulgaria. Si quieren ver mis presentaciones, están aquí. Todas las diapositivas y el código están vinculados a esta página para que puedan revisarlos más tarde.

Hoy vamos a hablar sobre la prueba de hooks con confianza. Existe una gran división entre el desarrollo impulsado por pruebas y la prueba automatizada, como podrán ver durante esta presentación. En mi charla, solo mencionaré cómo automatizar la prueba. No me adentraré en el desarrollo impulsado por pruebas y cosas relacionadas. Nuevamente, las palabras son baratas y no tengo muchas, así que les mostraré algo de código.

Les voy a mostrar esta aplicación de React sin probar. Es solo una pequeña aplicación de calculadora. Este es el código de la aplicación. Si se fijan, hay mucho código. Es una aplicación bastante simple, pero hay mucho código. ¿Cómo lo probamos? ¿Cómo sabemos que funciona? Podemos comenzar con una prueba simple y pequeña. Para la prueba pequeña, podemos agregar esos atributos de datos de prueba, para que podamos seleccionar los elementos, podemos usar la biblioteca de pruebas de React y podemos crear esta prueba simple y pequeña donde obtenemos la biblioteca de pruebas de React. Por lo general, cuando hago pruebas, me gusta tener esos ayudantes porque en general odio escribir cinco funciones una tras otra. Así que simplemente digo, ok, haz clic en este ID de datos. Y para mi prueba, este es otro pequeño truco que hago si necesito cambiar el nombre del componente y quiero volver y cambiar el nombre de la prueba. Así que aquí acabo de crear una prueba simple y pequeña. Simplemente funciona. Así que solo estoy probando, ceros vacíos, haciendo clic en más uno, uno, más dos, eliminar dos, evaluar y reiniciar. Básicamente, asegurándome de que este componente funcione. Esto es algo que haría normalmente para probar si las cosas funcionan manualmente. Esta es solo una prueba de marcador de posición. No es una prueba realmente buena. Como, la voy a eliminar al final, pero esto me asegura de que cuando refactorizo, no rompo algo. No es una prueba muy buena porque no sigue las cuatro fases de una buena prueba.

2. Refactorización y Prueba de Hooks Personalizados

Short description:

Entonces, ¿por dónde deberíamos empezar ahora? Lo primero que podemos hacer es limpiar el código a través de la refactorización. Podemos extraer la lógica grande y pesada en un hook simple y probarlo usando la biblioteca de hooks de React. Después de una prueba exhaustiva, podemos refactorizar el hook para usar useReducer y lograr una cobertura de prueba completa. Las pruebas unitarias de los componentes de React pueden no ser valiosas, ya que la complejidad radica en el código del hook. En su lugar, se recomienda realizar pruebas de extremo a extremo con herramientas como Cypress.

Entonces, ¿por dónde deberíamos empezar ahora? Lo primero que podemos hacer es limpiar el código. Lo que podemos hacer es una refactorización. Me gusta llamarlo extracción de hooks personalizados. Esta es una de mis características favoritas de los hooks, que es que puedes realmente arrancar hooks desde otros hooks y crear estas interfaces muy agradables.

Así que aquí toda esta lógica grande y pesada puede ser extraída en un simple hook, y este hook puede darte, ok, esto es lo que se guarda en la memoria de la calculadora y cuáles son las acciones. Y nuevamente, el código del hook es simplemente copiar y pegar, funciona. Entonces, ¿cómo vamos a probar este hook personalizado? Este es el siguiente paso que debemos hacer.

Para testing este hook personalizado, existe esta buena biblioteca llamada biblioteca de pruebas de React hooks, que te permite probar fácilmente el hook y lo que me gusta hacer es tener una función llamada emit hook, que básicamente oculta la configuración de boilerplate del hook. Y por ejemplo, quiero probar la acción de agregar. Entonces, para la acción de agregar, simplemente configuramos el hook, agregamos un valor y verificamos que después de que se recargue el hook, hemos actualizado nuestro valor y podemos básicamente probar, ok, si tengo dos dígitos, se suman, y puedes hacer todas las pruebas para eso, para eliminar es muy similar. Configuras el hook, simplemente lo llamas, tienes esta bonita función de llamada donde encapsulas esto y tienes todo esto. Y nuevamente, es un poco largo y te proporcionaré el enlace a las diapositivas al final para que puedas profundizar más.

Y ahora que tenemos esta prueba, que prueba muy a fondo nuestro hook con todos sus casos límite, con todas sus soluciones, podemos comenzar a refactorizar este hook. Lo que vamos a terminar al final de este gran montón de código es básicamente refactorizar este hook para usar solo un simple useReducer donde decimos, ok, tenemos una función reductora y al final tenemos las mismas acciones: agregar, eliminar, reiniciar, evaluar. Y esto es nuevamente el alcance del reductor. Es un poco más complejo. Es un poco más dividido, pero esto realmente prueba nuestra calculadora y realmente tenemos una cobertura de prueba completa. Y nuevamente, el código de esta presentación está en esta dirección para que puedas hacer clic y ver los detalles. Lo he dividido en pasos para que puedas ver todos los pasos de refactorización. Y un par de notas finales que quiero mencionar aquí es que al final, en realidad elimino todo ese código de la prueba de humo. No lo necesito. Lo que he encontrado en la práctica es que generalmente, cuando escribo componentes de React, son o muy simples, como obtienen algunos data y renderizan cosas, por lo que no hay mucho valor agregado en probarlos como una prueba unitaria. O la mayor lógica y la mayor parte de mis pruebas está en el código del hook. Por lo general, ese es el lugar donde se encuentra gran parte de la complejidad de mi sistema. Así que generalmente dejé de hacer pruebas unitarias de React. Y lo que intento hacer a nivel de pruebas unitarias es simplemente probar la función simple, como por ejemplo, podría probar solo el reductor, puedo probar solo el hook por sí mismo y no probar los componentes de React. La forma en que estoy seguro de que los componentes de React funcionan es a través de pruebas de extremo a extremo con algo como Cypress o algo como Capybara, que prueba realmente todo mi flujo de trabajo porque rara vez he encontrado errores en mi sistema que se refieran solo al componente de React en sí. Por lo general, los errores provienen de hooks muy complejos o cuando tenemos componentes de clase. Así que sí, eso es básicamente lo que quería compartir con ustedes hoy. Gracias por acompañarme.

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
Top Content
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
32 min
The Art of ‘Humble Views’: Testing React Native Apps the Smart Way
In this talk, we explore the divisive world of testing, where developers often find themselves torn between writing no tests and striving for 100% test coverage. Learn how to navigate these polarizing positions and adopt a more nuanced strategy that makes testing efficient and effective.We'll dive into the concept of 'Humble Views,' where we minimize untestable objects by extracting logic from UI elements into test-friendly parts of the codebase. This approach simplifies testing, focusing on business logic instead of UI complexities. Discover how the Model-View-Presenter (MVP) architecture helps achieve this, with presenters serving as a logical layer for testing and hooks aiding in separating logic from UI components.Throughout the talk, we'll discuss the trade-offs of this approach, the role of End-to-End (E2E) tests, and how to strike the perfect balance between too much and too little testing. Join us as we delve into the art of creating 'Humble Views,' ensuring that our React Native apps are scalable, maintainable, and effectively tested!
Vue.js Live 2024Vue.js Live 2024
26 min
We May Not Need Component Testing
Testings are mandatory and unit tests are the foundation for building a good testing system for our project. But for front end projects which involve components, how many unit tests are considered efficient and not overkill? Should we use additional libraries like Testing Library or Vue Test Utils with Vitest to test a component, when we can perform the same with just Playwright? Whether a component test using an E2E framework like Playwright is really a kill for? Let's find out in my talk.
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.