Medir y Mejorar el Rendimiento del Frontend Utilizando la Automatización de Pruebas
From Author:
Las pruebas de rendimiento automatizadas pueden ayudar a detectar los efectos perjudiciales de los cambios de código en el rendimiento de la aplicación. Aprenda a utilizar herramientas como Lighthouse y Web Core Vitals en su CI y establezca umbrales de rendimiento para mantener un rendimiento óptimo del frontend en esta sesión.
This talk has been presented at TestJS Summit 2023, check out the latest edition of this JavaScript Conference.
FAQ
Ramona trabaja como Developer Advocate en Offs Zero, es Google Developer Expert en tecnología web y embajador de Cypress.
Ramona se centró en el tema de 'performance' dentro del contexto de pruebas de software, abordando cómo la información y la automatización son clave en este ámbito.
La automatización es crucial para apoyar los tres aspectos esenciales de las aplicaciones: hacer que funcionen correctamente, mantenerlas bien y optimizar su rendimiento.
Las tres métricas principales son: la Pintura de Contenido Más Grande (LCP), el Primer Retraso de Entrada (FID), y el Cambio de Layout Acumulativo (CLS).
Ramona propone usar las pruebas de extremo a extremo para capturar métricas de rendimiento significativas y utilizar herramientas como Lighthouse y Cypress para evaluar y mejorar la performance de las aplicaciones.
Ramona menciona varias herramientas como phpStan, ESlearnStyle, y otras herramientas de análisis estático que pueden ayudar a mejorar la calidad del código y facilitar las pruebas.
Integrar la automatización de pruebas permite no solo verificar la funcionalidad y la calidad del código, sino también monitorear y mejorar el rendimiento de la aplicación, haciendo más eficiente el proceso de desarrollo.
Video Transcription
1. Introducción a las Pruebas e Información
Hola a todos en TestJS Summit esta vez. Estoy muy contento de estar aquí de nuevo. Hoy, vuelvo a casa con un descubrimiento interesante sobre el rendimiento. Me apasionan las pruebas y creo que la información es rey. Recopilar información es importante para construir buenas aplicaciones. Hazlo funcionar, hazlo bien, hazlo rápido: el orden de construir buenas aplicaciones.
Hola a todos en TestJS Summit esta vez. Estoy muy contento de estar aquí de nuevo porque la cumbre TestJS fue una de las primeras conferencias en las que tuve el honor de ser orador. Es como volver a casa hoy.
Hoy, en realidad, vuelvo aquí con un pequeño descubrimiento interesante que quiero mostrar cuando se trata de mi experiencia en testing. Si ya lo habías adivinado, es sobre performance. Bueno, antes de eso, rápido, mi nombre es Ramona. Trabajo como Developer Advocate en Offs Zero. Aparte de eso, soy Google Developer Expert en tecnología web y embajador de Cypress. Como habrás adivinado, creo que, sí, al menos me apasiona cuando se trata de testing. Sí, no debería ser una sorpresa que esté aquí para hablar de testing hoy.
Entonces, especialmente cuando se trata de testing, hay algunas cosas que son realmente importantes. Y sí, esta pequeña cosa, el contenido es rey, que espero tener suficiente para estos 20 minutos. Fue hecho por Steve Bommer, creo. Hace muchas citas que son memorables. Pero bueno, cambiemos un poco esta cita. Porque, si el contenido es rey, la información es rey, como el doble o incluso más. Y no es solo porque me gusta jugar videojuegos y este es el título de una misión de World of Warcraft. Pero yo, bueno, lo encuentro interesante. Al menos me gustan esas pequeñas misiones secundarias donde, por ejemplo en este caso, un vendedor goblin llamado Goodskitch quiere tener un poco de piel de Krukal a cambio de información. Entonces, no solo en videojuegos la información es realmente importante. Recopilar información, tener una buena idea de lo que sucede dentro de tu aplicación, es realmente importante. No solo en los juegos, sino también cuando se trata de testing.
Entonces, bueno, supongo que esto debería estar claro la mayor parte del tiempo. Pero, ¿por qué necesitamos tener información sobre nuestra aplicación? Porque queremos construir buenas aplicaciones, ¿verdad? Entonces, podrías haber tropezado con esta cita de Comeback, que dice, hazlo funcionar, hazlo bien, hazlo rápido, en ese orden particular. Entonces, solo para profundizar un poco, hacer que funcione es autoexplicativo. Intenta resolver un problema a mano, que podría construir una buena aplicación. Entonces, solo haz que funcione cuando se trata de tus requisitos. Si puedes hacer eso, haz la segunda cosa, hazlo mantenible, hazlo bien. Entonces, intenta tener en cuenta los requisitos no funcionales. Ten en cuenta el código limpio, por ejemplo, para hacerlo no solo funcionar, sino funcionar de la manera correcta y funcionar de la manera en que todavía quieres trabajar con tu aplicación, digamos, un año a partir de ahora.
2. Uso de la Automatización de Pruebas para el Monitoreo del Rendimiento
Y por último, pero no menos importante, haz que funcione, hazlo rápido, haz que el usuario no se sienta molesto al usar tu aplicación. Podemos usar la automatización para apoyarnos en estos tres puntos, incluso en el rendimiento. La automatización de pruebas se puede utilizar para monitorear el rendimiento y recopilar información. El registro es el arte de mantener un registro o una lista de eventos que ocurren en tu sistema informático, como problemas, errores o simplemente información en las operaciones actuales.
Y por último, pero no menos importante, haz que funcione, hazlo rápido, haz que el usuario no se sienta molesto al usar tu aplicación. Y sí, por supuesto, el primer punto, hacer que funcione es bastante fácil de lograr con testing. Entonces, si pruebas tu aplicación, sabes que está funcionando como se esperaba. El segundo punto, hacerlo bien, puede ser apoyado por tooling, por ejemplo, si tuviéramos buenas pruebas, facilitaría la escritura de un buen código. Y no quiero empezar con todos los linches, todas las herramientas de análisis estático que puedes ejecutar, como phpStan, ESlearnStyle y lo que sea. Pero, bueno, tenemos un buen soporte cuando se trata de primero, hacer que funcione, hacerlo bien. Pero ¿qué pasa con el tercer punto, hacerlo rápido y hacerlo funcionar y básicamente hacer que se sienta impecable? Bueno, hacer que tu aplicación funcione parece realmente desalentador, porque como dije, no tienes tanto soporte de herramientas todavía. Y bueno, incluso el punto, los pasos para acelerar tu código de aplicación es realmente difícil, porque podrías preguntar, como, ¿quién tiene tiempo para eso, quién tiene el poder para hacer eso? Y puede ser por presión de los clientes, pero especialmente el espacio mental dentro de ti mismo. ¿Y tenemos tiempo para mejorar el performance o mantenerlo? Porque incluso obtener toda la información que necesitas sobre tu aplicación para monitorear el performance, hacer todas esas medidas localmente lleva mucho tiempo. Y todo esto junto parece realmente desalentador. Entonces, ¿qué pasaría si te dijera un punto interesante de que no necesitamos sentirnos perdidos? No necesitamos sentirnos tan agotados o asustados. ¿Qué pasaría si te dijera que podemos usar la automation para apoyarnos en todos esos tres puntos? Incluso el performance. No solo trabajar, no solo hacerlo bien, hacerlo funcionar. ¿Qué pasaría si te dijera que puedes usar la automatización de pruebas para eso? No solo intentar aprender GitHub Actions para implementar algunas herramientas que nos ayuden a monitorear el performance, sino usar todo lo que ya tenemos. La automatización de pruebas que ya tenemos para nuestro proyecto. Bueno, lo sé, lo sé, es un poco como mal usar el testing, ¿verdad? Entonces, bueno, todavía es bueno porque puedes usar tus conocimientos que ya tienes para ello. No necesitas aprender nuevas herramientas. Puedes usar tu CI bien conocido y familiar. Por ejemplo, si no quieres usar GitHub Actions, que puede dártelo, o si una acción de GitHub estandarizada no es suficiente para satisfacer tus necesidades. Entonces, en mi mente creo que es interesante usar las pruebas de extremo a extremo para medir el performance porque la pila de aplicaciones AppStack está completamente ahí, y existente. Entonces podemos hacer más de ello, que solo cuando se trata de pruebas unitarias. Y estamos cerca del usuario que se molestaría por los problemas de performance, ¿verdad? Pero, si queremos pensar en usar la automatización de pruebas para monitorear el performance y recopilar, monitorear y recolectar información sobre nuestro performance, retrocedamos un paso y veamos cómo medimos o recopilamos información sobre nuestra automatización de pruebas para empezar. Bueno, como esta charla se llama Medición, comencemos con los valores predeterminados para arrojar algo de luz sobre ello.
Muchos piensan en la forma más interesante o más normal de ver la información de tus pipelines de automatización de pruebas. Por ejemplo, si quieres ver por qué algo falla, mirarás los registros. El registro es en realidad el arte de mantener un registro o una lista de eventos que ocurren en tu sistema informático, como problemas, errores o simplemente información en las operaciones actuales. Podría ser testing, por ejemplo, en este sentido. Registra todo lo que sucede dentro de tus pruebas.
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
Workshops on related topic
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 🤐)
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
QwikCity es un nuevo meta-framework que te permite construir aplicaciones a gran escala con un rendimiento de inicio constante. Veremos cómo construir una aplicación QwikCity y qué la hace única. El masterclass te mostrará cómo configurar un proyecto QwikCity. Cómo funciona el enrutamiento con el diseño. La aplicación de demostración obtendrá datos y los presentará al usuario en un formulario editable. Y finalmente, cómo se puede utilizar la autenticación. Todas las partes básicas para cualquier aplicación a gran escala.
En el camino, también veremos qué hace que Qwik sea único y cómo la capacidad de reanudación permite un rendimiento de inicio constante sin importar la complejidad de la aplicación.
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
Comments