Pruebas automatizadas de regresión de rendimiento con Reassure

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

Como desarrolladores, nos encanta sumergirnos en métricas de rendimiento, comparar soluciones y realizar pruebas de rendimiento. Aunque no siempre nos guste, a menudo nos vemos obligados a solucionar problemas de rendimiento en nuestras aplicaciones de React y React Native. Pero este proceso no es sostenible y propenso a regresiones, especialmente a medida que la aplicación y el equipo crecen. Lo peor de todo es que estos problemas a menudo son descubiertos por los usuarios, lo que hace que su experiencia sea miserable. En mi charla te presentaré Reassure, una biblioteca de pruebas de regresión de rendimiento para React y React Native, que resulta ser una pieza faltante en nuestras suites de pruebas automatizadas y rendimiento. Detectando problemas antes de que lleguen a producción.

This talk has been presented at React Advanced 2022, check out the latest edition of this React Conference.

FAQ

ReaSure es una herramienta de pruebas de regresión de rendimiento para aplicaciones de React y React Native, diseñada para integrarse con sistemas de CI y mejorar el proceso de revisión de código en GitHub. Ayuda a detectar y prevenir regresiones de rendimiento al medir tiempos de renderizado y contar re-renderizaciones de forma confiable.

ReaSure fue desarrollado en colaboración entre Callstack y Intane, uno de los grandes grupos de apuestas y juegos. El desarrollo está liderado por Michał Pieszchala y su equipo en Callstack.

ReaSure se ejecuta en un entorno de servidor remoto, usa Jest para pruebas de rendimiento, y el perfilador de React para medidas confiables. Además, genera informes en JSON y Markdown y se integra con Danger.js para enriquecer las revisiones de código en GitHub.

ReaSure se integra con GitHub y utiliza Danger.js como backend de bot para proporcionar comentarios automáticos en las revisiones de código, lo que ayuda a identificar y mitigar problemas de rendimiento antes de que se integren en la base de código principal.

Medir el rendimiento es crucial para prevenir la degradación del mismo a lo largo del tiempo, especialmente en entornos dinámicos de desarrollo donde nuevas funciones y cambios pueden introducir regresiones inadvertidamente.

ReaSure utiliza el perfilador de React para obtener medidas precisas y realiza pruebas en condiciones controladas para minimizar la variabilidad, ejecutando pruebas repetitivas y utilizando análisis estadísticos para validar la significancia de los resultados.

Sí, ReaSure es una herramienta de código abierto. Los interesados pueden acceder al repositorio, seguir las actualizaciones y contribuir a su desarrollo.

Michał Pierzchała
Michał Pierzchała
16 min
24 Oct, 2022

Comments

Sign in or register to post your comment.
Video Summary and Transcription
La charla de hoy presenta Reacher, una herramienta de monitoreo de rendimiento para bases de código de React y React Native. Destaca la necesidad de detectar regresiones de rendimiento temprano en el proceso de desarrollo e identifica el mal uso de JavaScript como una fuente común de problemas de rendimiento. ReaSure, desarrollado por Covstack, se presenta como una biblioteca prometedora que se integra con los ecosistemas existentes y proporciona mediciones confiables de tiempo de renderizado y conocimientos útiles para la revisión de código. Se discuten consideraciones para operar en un VM de JavaScript, incluyendo JIT, recolección de basura y caché de resolución de módulos. Se menciona el análisis estadístico utilizando el z-score como un método para determinar la importancia de los resultados de las mediciones.

1. Introduction to Performance Monitoring

Short description:

Hoy voy a hablar sobre el monitoreo del rendimiento en los codebases de React y React Native con Reacher. La entropía es el aumento del desorden, que distingue el pasado del futuro. Como desarrolladores, luchamos contra la entropía siguiendo un ciclo de desarrollo y solucionando errores. Sin embargo, incluso con un flujo de trabajo bien diseñado, pueden aparecer críticas negativas.

Hola, hoy voy a hablar sobre el monitoreo del rendimiento y cómo hacerlo en tus codebases de React y React Native con Reacher. Me llamo Michał Pieszchala, soy el Jefe de Tecnología en Callstack, responsable de nuestra investigación y desarrollo y esfuerzos de código abierto. También soy un colaborador principal en una serie de bibliotecas, actualmente manteniendo el React Native CLI y la biblioteca de pruebas de React Native.

Comencemos con algo de inspiración, ¿de acuerdo? ¿Alguien ha oído hablar de la entropía? No realmente esta. La entropía del mundo real, descrita por la física de esta manera. O cómo lo enmarcó Stephen Hawking. Puedes ver una taza de té caerse de una mesa y romperse en pedazos en el suelo, pero nunca verás que la taza se reúna y salte de nuevo a la mesa. El aumento del desorden, o esta entropía, es lo que distingue el pasado del futuro, dándole una dirección al tiempo. O en otras palabras, las cosas eventualmente se desmoronarán si no se les presta atención.

Pero no nos pongamos demasiado deprimidos o cómodos con las cosas que se convierten en caos, porque podemos y debemos luchar contra ello. Podemos hacer esfuerzos para crear tipos útiles de energía y orden, lo suficientemente resistentes como para resistir la implacable atracción de la entropía al gastar esta energía. Cuando desarrollamos software, sentimos que la entropía es algo real. Es por eso que generalmente hacemos un esfuerzo adicional y seguimos algún tipo de ciclo de desarrollo. Por ejemplo, comenzamos agregando una nueva función. Durante el desarrollo, la acompañamos con una serie de pruebas. Cuando terminamos, la enviamos a QA. QA la mejora y promueve nuestro código para su lanzamiento en el canal de producción. Y volvemos a agregar otra función. Pero eso es una versión bastante simplificada de lo que generalmente hacemos. Complicémoslo un poco. Entre otras cosas, no tenemos en cuenta que los errores pueden aparecer repentinamente. Ahora nuestro círculo se convierte en un grafo, pero está bien porque sabemos qué hacer. Necesitamos identificar la causa raíz, agregar una prueba de regresión para que nunca vuelva a romperse, enviarla a QA una vez más, enviarla y volver a agregar nuevas funciones.

Entonces estamos contentos con nuestro flujo de trabajo. Funciona bastante bien. Agregamos función tras función, nuestra versión de la aplicación está tan bien diseñada que incluso agregar 10 nuevos desarrolladores no nos ralentiza. Y luego echamos un vistazo a las reseñas de nuestra aplicación para ver qué piensan las personas. Y aparece una reseña salvaje de una estrella. Y luego llega otra más.

Read also

2. Challenges with Performance Monitoring

Short description:

Nuestro flujo de trabajo perfecto no es resistente a las regresiones de rendimiento. Necesitamos una forma de detectarlas antes de que afecten a nuestros usuarios. Tratar los problemas de rendimiento como errores nos permite detectar las regresiones temprano en el proceso de desarrollo. Para encontrar la mejor herramienta para las pruebas de rendimiento, debemos considerar el impacto y enfocarnos en las regresiones más probables. La mayoría de los problemas de rendimiento se originan en el lado de JavaScript, particularmente por un mal uso de React. Estimamos que alrededor del 80% del tiempo dedicado a solucionar problemas de rendimiento se encuentra en el ámbito de JavaScript. Encontramos una prometedora biblioteca de pruebas de rendimiento para React que vale la pena explorar.

Y simplemente... siguen llegando. Y empezamos a darnos cuenta de que nuestro flujo de trabajo perfecto basado en la ciencia, nuestras experiencias y las mejores prácticas, que se suponía que evitaría que nuestra aplicación se desmoronara, no es resistente a un tipo particular de errores. Regresiones de rendimiento. Nuestro código no tiene las herramientas para combatir esto. Sabemos cómo solucionar los problemas una vez que los detectamos, pero no tenemos forma de detectarlos antes de que afecten a nuestros usuarios.

Entonces, ¿cómo era de nuevo? O... El rendimiento se desmoronará eventualmente cuando no se haya previsto. Así que si no hago nada para optimizar mi aplicación mientras agrego nuevo código y dejo que el tiempo pase, se volverá más lenta. Y no sabemos cuándo sucederá. Tal vez mañana, tal vez en una semana, o en un año. Y si solo hubiera una forma establecida de detectar al menos algunas de las regresiones temprano en el proceso de desarrollo, antes de que nuestros usuarios se den cuenta. ¡Espera un minuto, la hay! Si comenzamos a tratar los problemas de rendimiento como errores, ni siquiera necesitamos interrumpir nuestro flujo de trabajo de desarrollo. Las pruebas de regresión se ejecutan en un entorno remoto, en cada cambio de código, así que solo necesitamos encontrar una forma de incluir las pruebas de rendimiento allí, ¿verdad?

Pero antes de salir a buscar la mejor herramienta, demos un paso atrás y pensemos en el impacto y en lo que vale la pena probar. Al igual que con cualquier cobertura de pruebas, hay una proporción saludable a la que aspiramos, para proporcionarnos el mejor valor con el menor esfuerzo. Queremos asegurarnos de enfocarnos en las regresiones que es más probable que afecten a nuestros usuarios. Y al parecer, estamos desarrollando una aplicación reactivada. Por cierto, ¿sabías que hay una fuente llamada Impact? Y probablemente la hayas visto en memes. De todos modos, echemos un vistazo a los problemas típicos de rendimiento con los que los desarrolladores se enfrentan a diario. Listas e imágenes lentas, SVG, mal uso del contexto de React, re-renderizaciones, TCI lento, solo por mencionar algunos. Si observamos esta lista desde el punto de vista del origen del problema, notaremos que la gran mayoría de ellos provienen del lado de JavaScript. Ahora, veamos la frecuencia relativa. Y lo que emerge es bastante revelador. Estimamos que la mayor parte del tiempo que nuestros desarrolladores dedican a solucionar problemas de rendimiento, alrededor del 80%, proviene del ámbito de JavaScript, especialmente por un mal uso de React. Solo el resto es la sobrecarga de comunicación entre puentes y el código nativo, como la renderización de imágenes o las operaciones de la base de datos que funcionan de manera ineficiente. Pero no soy partidario de reinventar la rueda, así que he buscado en Google una biblioteca de pruebas de rendimiento para React, y encontré esto. Este paquete. Parece prometedor. Veamos qué hay dentro. No es muy popular, pero está bien. La última versión se lanzó hace 9 meses.

3. Introduction to ReaSure

Short description:

Necesitamos una nueva biblioteca que se integre con nuestro ecosistema existente, mida los tiempos de renderizado de manera confiable, proporcione un ejecutor de CI, genere informes legibles y analizables, y ofrezca información útil para la revisión de código. Les presento ReaSure, un compañero de pruebas de regresión de rendimiento para aplicaciones de React y React Native. Desarrollado por Covstack en colaboración con Intane, ReaSure mejora el proceso de revisión de código al integrarse con GitHub. Ejecuta Jest a través de código Node con parches especiales para aumentar la estabilidad y utiliza el perfilador de React para manejar las mediciones de manera confiable. ReaSure compara los resultados de las pruebas entre ramas y proporciona un resumen de los resultados categorizados estadísticamente. Abrazar la estabilidad y evitar la inestabilidad es clave para los puntos de referencia cognitivos, especialmente en Node.js.

Está bien. ¿Qué más? Parchea React. Eso no está bien. También utiliza internamente React. Eso es decepcionante. No se ajusta a nuestro caso de uso y no parece una base sólida para construir.

Pero, ¿qué necesitamos realmente de una biblioteca como esta? Idealmente, debería integrarse con el ecosistema existente de bibliotecas que estamos utilizando. Debería medir los tiempos de renderizado y contar de manera confiable, tener un ejecutor de CI, generar informes legibles y analizables, proporcionar información útil para la revisión de código y, según nuestra biblioteca de Google, tener un diseño estable. Y dado que no hay nada como esto disponible, necesitamos una nueva biblioteca.

Y me gustaría presentarles ReaSure, un compañero de pruebas de regresión de rendimiento para aplicaciones de React y React Native. Se desarrolla en Covstack en colaboración con Intane, uno de los grupos de apuestas y juegos más grandes del mundo. ReaSure se basa en su configuración existente y la complementa con una API de medición de rendimiento discreta. Está diseñado para ejecutarse en un entorno de servidor remoto como parte de su integración continua. Para aumentar la estabilidad de los resultados y reducir la inestabilidad, ReaSure ejecutará sus pruebas una vez para la rama actual y otra vez para la rama base. Una experiencia de desarrollo agradable es fundamental en nuestro diseño de ingeniería. Es por eso que ReaSure se integra con GitHub para mejorar el proceso de revisión de código. Actualmente, aprovechamos Danger.js como nuestro backend de bot, pero en el futuro nos gustaría preparar una acción de GitHub plug-and-play.

Ahora, veamos qué hace. ReaSure ejecuta Jest a través de código Node con parches especiales para aumentar la estabilidad. La función measureRender que proporcionamos utiliza el perfilador de React para manejar las mediciones de manera confiable, lo que nos permite evitar el parcheo de React. Después de completar la primera ejecución, cambiamos a la rama base y ejecutamos las pruebas nuevamente. Una vez que se completan ambas ejecuciones de pruebas, la herramienta compara los resultados y presenta el resumen, mostrando resultados categorizados estadísticamente en los que se puede actuar. Volvamos a nuestro ejemplo. Observa cómo creamos un nuevo archivo con la extensión .perf-test-.dsx, que reutiliza nuestra prueba de componente regular de la biblioteca React en una función de escenario. Luego, el método measurePerformance de ReaSure utiliza el escenario para renderizar nuestro componente contador, en este caso, 20 veces. Bajo el capó, el perfilador de React mide los tiempos de renderizado y la cantidad de veces que se renderiza, que luego escribimos en el sistema de archivos. Y eso es generalmente todo lo que tienes que escribir. Copia y pega tus pruebas existentes, ajústalas y disfruta. Los puntos de referencia cognitivos no son pan comido, incluso en entornos que no son de JS. Pero es particularmente complicado con Node.js. La clave es abrazar la estabilidad y evitar la inestabilidad.

4. Consideraciones para JavaScript VM

Short description:

Al operar en un JavaScript VM, debemos tener en cuenta el JIT, la recolección de basura y el almacenamiento en caché de resolución de módulos. El análisis estadístico requiere ejecutar las mediciones varias veces. El z-score se utiliza para determinar la significancia estadística de los resultados.

Al operar en un JavaScript VM, debemos tener en cuenta el JIT, la recolección de basura y el almacenamiento en caché de resolución de módulos. Tenemos un costo de concurrencia que nuestro ejecutor de pruebas asume para una ejecución rápida. Necesitamos decidir qué promediar y qué percentil tomar. Y mucho más. Por ejemplo, para realizar un análisis estadístico. Para asegurarnos de que nuestros resultados de medición tengan sentido matemáticamente, no es suficiente ejecutarlos una o dos veces. Teniendo en cuenta otras cosas, hemos determinado que diez veces es una buena referencia. Luego, para determinar la probabilidad de que el resultado sea estadísticamente significativo, necesitamos calcular el z-score, que requiere el valor medio o la divergencia promedio y la desviación estándar. Esto me trae recuerdos de la universidad, así que no voy a profundizar aquí. Ahora, el almacenamiento en caché de resolución de módulos es algo que es genial para las aplicaciones de Node.js, pero nos causó problemas al desarrollar la biblioteca. Resultó que la ejecución posterior del mismo componente a menudo resultaba en ejecuciones incluso diez veces más lentas. Como puedes imaginar, promediar eso haría que los resultados no fueran confiables. Por lo tanto, descartamos la prueba más lenta, ya que probablemente está limitada por la falta de caché. Con todos esos datos, podemos presentar los tiempos de duración de renderizado como estadísticamente significativos o sin sentido. Además de los tiempos de renderizado, otra métrica útil que puede degradarse fácilmente son los recuentos de renderizado, que obtenemos de forma gratuita del Profiler de React. Toda esta información se almacena en formato JSON para su análisis posterior y en Markdown para su legibilidad. Utilizamos la salida de Markdown como fuente para el bot de comentarios de GitHub, impulsado por Danger.js. Esta es, con mucho, nuestra forma favorita y recomendada de usar ReaSure, ya que enriquece el proceso de revisión de código y nos permite mitigar la inestabilidad de la CI que estamos utilizando. Permíteme compartir lo que hemos aprendido hasta ahora al usar esta biblioteca. Debes cubrir los escenarios de usuario más importantes. Incluso si no tienes problemas de rendimiento ahora, los detectarás si aparecen. Prueba pantallas completas o incluso secuencias de pantallas. Las pruebas a nivel de componente son posibles, pero a menudo requieren más ejecuciones de pruebas. Puedes reutilizar tus pruebas de bibliotecas de React Native y Testing si las tienes, y se aplican todas las prácticas establecidas de la biblioteca de pruebas. Haz que tus pruebas se parezcan al comportamiento del usuario y evita simular cualquier cosa que no sea IOH. Debido a sus características, parece que las pruebas de rendimiento frontend se asemejan a las pruebas de extremo a extremo para nuestras aplicaciones. Tiene sentido tratarlas como tal en lugar de en nuestras Trophies o Pirámides de Testing. Recuerda que el rendimiento no es un objetivo, es un camino. Recórrelo con confianza. Hacia EARNED, ReaSure no existiría si no fuera por mis colegas Maciej Jastrzębski, quien es el cerebro detrás de la biblioteca, y un increíble equipo de desarrollo formado por Tomasz y Jakub. Asegúrate de seguir su trabajo. ReaSure es de código abierto. El código QR te redirigirá al repositorio. Dale una estrella si te gusta y avísame si tienes algún problema al adoptarlo. Estaré encantado de ayudarte. Y eso es todo, amigos. Puedes encontrarme en Twitter o GitHub con este nombre de usuario. Que tengas una gran conferencia y gracias.

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

Una Guía del Comportamiento de Renderizado de React
React Advanced 2022React Advanced 2022
25 min
Una Guía del Comportamiento de Renderizado de React
Top Content
This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.
Acelerando tu aplicación React con menos JavaScript
React Summit 2023React Summit 2023
32 min
Acelerando tu aplicación React con menos JavaScript
Top Content
Mishko, the creator of Angular and AngularJS, discusses the challenges of website performance and JavaScript hydration. He explains the differences between client-side and server-side rendering and introduces Quik as a solution for efficient component hydration. Mishko demonstrates examples of state management and intercommunication using Quik. He highlights the performance benefits of using Quik with React and emphasizes the importance of reducing JavaScript size for better performance. Finally, he mentions the use of QUIC in both MPA and SPA applications for improved startup performance.
Solicitudes de Red con Cypress
TestJS Summit 2021TestJS Summit 2021
33 min
Solicitudes de Red con Cypress
Top Content
Cecilia Martinez, a technical account manager at Cypress, discusses network requests in Cypress and demonstrates commands like cydot request and SCI.INTERCEPT. She also explains dynamic matching and aliasing, network stubbing, and the pros and cons of using real server responses versus stubbing. The talk covers logging request responses, testing front-end and backend API, handling list length and DOM traversal, lazy loading, and provides resources for beginners to learn Cypress.
Concurrencia en React, Explicada
React Summit 2023React Summit 2023
23 min
Concurrencia en React, Explicada
Top Content
React 18's concurrent rendering, specifically the useTransition hook, optimizes app performance by allowing non-urgent updates to be processed without freezing the UI. However, there are drawbacks such as longer processing time for non-urgent updates and increased CPU usage. The useTransition hook works similarly to throttling or bouncing, making it useful for addressing performance issues caused by multiple small components. Libraries like React Query may require the use of alternative APIs to handle urgent and non-urgent updates effectively.
How React Compiler Performs on Real Code
React Advanced 2024React Advanced 2024
31 min
How React Compiler Performs on Real Code
Top Content
I'm Nadia, a developer experienced in performance, re-renders, and React. The React team released the React compiler, which eliminates the need for memoization. The compiler optimizes code by automatically memoizing components, props, and hook dependencies. It shows promise in managing changing references and improving performance. Real app testing and synthetic examples have been used to evaluate its effectiveness. The impact on initial load performance is minimal, but further investigation is needed for interactions performance. The React query library simplifies data fetching and caching. The compiler has limitations and may not catch every re-render, especially with external libraries. Enabling the compiler can improve performance but manual memorization is still necessary for optimal results. There are risks of overreliance and messy code, but the compiler can be used file by file or folder by folder with thorough testing. Practice makes incredible cats. Thank you, Nadia!

Workshops on related topic

Masterclass de Depuración de Rendimiento de React
React Summit 2023React Summit 2023
170 min
Masterclass de Depuración de Rendimiento de React
Top Content
Featured Workshop
Ivan Akulov
Ivan Akulov
Los primeros intentos de Ivan en la depuración de rendimiento fueron caóticos. Vería una interacción lenta, intentaría una optimización aleatoria, vería que no ayudaba, y seguiría intentando otras optimizaciones hasta que encontraba la correcta (o se rendía).
En aquel entonces, Ivan no sabía cómo usar bien las herramientas de rendimiento. Haría una grabación en Chrome DevTools o React Profiler, la examinaría, intentaría hacer clic en cosas aleatorias, y luego la cerraría frustrado unos minutos después. Ahora, Ivan sabe exactamente dónde y qué buscar. Y en esta masterclass, Ivan te enseñará eso también.
Así es como va a funcionar. Tomaremos una aplicación lenta → la depuraremos (usando herramientas como Chrome DevTools, React Profiler, y why-did-you-render) → identificaremos el cuello de botella → y luego repetiremos, varias veces más. No hablaremos de las soluciones (en el 90% de los casos, es simplemente el viejo y regular useMemo() o memo()). Pero hablaremos de todo lo que viene antes - y aprenderemos a analizar cualquier problema de rendimiento de React, paso a paso.
(Nota: Esta masterclass es más adecuada para ingenieros que ya están familiarizados con cómo funcionan useMemo() y memo() - pero quieren mejorar en el uso de las herramientas de rendimiento alrededor de React. Además, estaremos cubriendo el rendimiento de la interacción, no la velocidad de carga, por lo que no escucharás una palabra sobre Lighthouse 🤐)
Presentando FlashList: Construyamos juntos una lista performante en React Native
React Advanced 2022React Advanced 2022
81 min
Presentando FlashList: Construyamos juntos una lista performante en React Native
Top Content
Featured Workshop
David Cortés Fulla
Marek Fořt
Talha Naqvi
3 authors
En esta masterclass aprenderás por qué creamos FlashList en Shopify y cómo puedes usarlo en tu código hoy. Te mostraremos cómo tomar una lista que no es performante en FlatList y hacerla performante usando FlashList con mínimo esfuerzo. Usaremos herramientas como Flipper, nuestro propio código de benchmarking, y te enseñaremos cómo la API de FlashList puede cubrir casos de uso más complejos y aún así mantener un rendimiento de primera categoría.Sabrás:- Breve presentación sobre qué es FlashList, por qué lo construimos, etc.- Migrando de FlatList a FlashList- Enseñando cómo escribir una lista performante- Utilizando las herramientas proporcionadas por la biblioteca FlashList (principalmente el hook useBenchmark)- Usando los plugins de Flipper (gráfico de llamas, nuestro perfilador de listas, perfilador de UI & JS FPS, etc.)- Optimizando el rendimiento de FlashList utilizando props más avanzados como `getType`- 5-6 tareas de muestra donde descubriremos y solucionaremos problemas juntos- Preguntas y respuestas con el equipo de Shopify
Diseñando Pruebas Efectivas con la Biblioteca de Pruebas de React
React Summit 2023React Summit 2023
151 min
Diseñando Pruebas Efectivas con la Biblioteca de Pruebas de React
Top Content
Featured Workshop
Josh Justice
Josh Justice
La Biblioteca de Pruebas de React es un gran marco para las pruebas de componentes de React porque responde muchas preguntas por ti, por lo que no necesitas preocuparte por esas preguntas. Pero eso no significa que las pruebas sean fáciles. Todavía hay muchas preguntas que tienes que resolver por ti mismo: ¿Cuántas pruebas de componentes debes escribir vs pruebas de extremo a extremo o pruebas de unidad de nivel inferior? ¿Cómo puedes probar una cierta línea de código que es difícil de probar? ¿Y qué se supone que debes hacer con esa persistente advertencia de act()?
En esta masterclass de tres horas, presentaremos la Biblioteca de Pruebas de React junto con un modelo mental de cómo pensar en el diseño de tus pruebas de componentes. Este modelo mental te ayudará a ver cómo probar cada bit de lógica, si debes o no simular dependencias, y ayudará a mejorar el diseño de tus componentes. Te irás con las herramientas, técnicas y principios que necesitas para implementar pruebas de componentes de bajo costo y alto valor.
Tabla de contenidos- Los diferentes tipos de pruebas de aplicaciones de React, y dónde encajan las pruebas de componentes- Un modelo mental para pensar en las entradas y salidas de los componentes que pruebas- Opciones para seleccionar elementos DOM para verificar e interactuar con ellos- El valor de los mocks y por qué no deben evitarse- Los desafíos con la asincronía en las pruebas de RTL y cómo manejarlos
Requisitos previos- Familiaridad con la construcción de aplicaciones con React- Experiencia básica escribiendo pruebas automatizadas con Jest u otro marco de pruebas unitarias- No necesitas ninguna experiencia con la Biblioteca de Pruebas de React- Configuración de la máquina: Node LTS, Yarn
Detox 101: Cómo escribir pruebas de extremo a extremo estables para su aplicación React Native
React Summit 2022React Summit 2022
117 min
Detox 101: Cómo escribir pruebas de extremo a extremo estables para su aplicación React Native
Top Content
Workshop
Yevheniia Hlovatska
Yevheniia Hlovatska
A diferencia de las pruebas unitarias, las pruebas de extremo a extremo buscan interactuar con su aplicación tal como lo haría un usuario real. Y como todos sabemos, puede ser bastante desafiante. Especialmente cuando hablamos de aplicaciones móviles.
Las pruebas dependen de muchas condiciones y se consideran lentas e inestables. Por otro lado, las pruebas de extremo a extremo pueden dar la mayor confianza de que su aplicación está funcionando. Y si se hace correctamente, puede convertirse en una herramienta increíble para aumentar la velocidad del desarrollador.
Detox es un marco de pruebas de extremo a extremo en caja gris para aplicaciones móviles. Desarrollado por Wix para resolver el problema de la lentitud e inestabilidad y utilizado por React Native en sí como su herramienta de pruebas E2E.
Únete a mí en esta masterclass para aprender cómo hacer que tus pruebas de extremo a extremo móviles con Detox sean excelentes.
Prerrequisitos- iOS/Android: MacOS Catalina o más reciente- Solo Android: Linux- Instalar antes de la masterclass
Next.js 13: Estrategias de Obtención de Datos
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Estrategias de Obtención de Datos
Top Content
Workshop
Alice De Mauro
Alice De Mauro
- Introducción- Prerrequisitos para la masterclass- Estrategias de obtención: fundamentos- Estrategias de obtención – práctica: API de obtención, caché (estática VS dinámica), revalidar, suspense (obtención de datos en paralelo)- Prueba tu construcción y sírvela en Vercel- Futuro: Componentes de servidor VS Componentes de cliente- Huevo de pascua de la masterclass (no relacionado con el tema, destacando la accesibilidad)- Conclusión
Masterclass de Pruebas de API con Postman
TestJS Summit 2023TestJS Summit 2023
48 min
Masterclass de Pruebas de API con Postman
Top Content
WorkshopFree
Pooja Mistry
Pooja Mistry
En el panorama siempre en evolución del desarrollo de software, garantizar la fiabilidad y funcionalidad de las API se ha vuelto primordial. "Pruebas de API con Postman" es una masterclass completa diseñada para equipar a los participantes con los conocimientos y habilidades necesarios para sobresalir en las pruebas de API utilizando Postman, una herramienta poderosa ampliamente adoptada por profesionales en el campo. Esta masterclass profundiza en los fundamentos de las pruebas de API, avanza a técnicas de prueba avanzadas y explora la automatización, las pruebas de rendimiento y el soporte multiprotocolo, proporcionando a los asistentes una comprensión holística de las pruebas de API con Postman.
Únete a nosotros para esta masterclass para desbloquear todo el potencial de Postman para las pruebas de API, agilizar tus procesos de prueba y mejorar la calidad y fiabilidad de tu software. Ya seas un principiante o un probador experimentado, esta masterclass te equipará con las habilidades necesarias para sobresalir en las pruebas de API con Postman.