Cómo probamos Storybook en sí

Rate this content
Bookmark

Storybook es un proyecto OSS complejo, que se integra con una amplia gama de stacks y es utilizado de diversas formas por millones de desarrolladores. ¿Cómo es mantener un proyecto así? ¿Cómo nos aseguramos de que no se rompa?

30 min
07 Dec, 2023

AI Generated Video Summary

Esta charla discute el uso de TypeScript y Storybook en el desarrollo de software. Cubre la premisa de los componentes y la complejidad de probar Storybook. Se explica el proceso de configuración para Next.js y Storybook, junto con el flujo de trabajo de pruebas e integración de CI. La charla también toca el tema de la caché, los informes de errores y el proceso de lanzamiento. Se discute la gestión de la documentación y la mejora del tiempo de ejecución de las pruebas, así como la prueba de las banderas de características y el uso móvil.

1. Introducción a TypeScript y Storybook

Short description:

Vamos a hablar de cómo puedes usar TypeScript para escribir JavaScript con TypeScript. Este es más bien un estudio de caso. Storybook es una herramienta que puedes usar para construir mejores componentes. Porque el principio fundamental de Storybook es que puedes trabajar en ellos de forma aislada. Puedes catalogar todos esos componentes y todos sus estados, todas las variantes. Y puedes probarlos muy importante. Storybook es bastante popular, lo cual es muy humilde para mí. Pero a menudo, aprendes cómo se ejecuta el código y cómo funciona por cómo se usa.

Vamos a hablar de cómo puedes usar TypeScript para escribir JavaScript con TypeScript. Hablaremos de cómo puedes usar TypeScript para escribir JavaScript con TypeScript. Hablaremos de cómo puedes usar TypeScript para escribir JavaScript con TypeScript. Hablaremos de cómo puedes usar TypeScript para escribir JavaScript con TypeScript. Hablaremos de cómo puedes usar TypeScript para escribir JavaScript con TypeScript.

No es perfecto. Y este es un tipo de charla que nunca he dado antes. Así que antes, siempre daba una charla sobre, oh, deberías hacer esto nuevo ahora mismo. Este es más bien un estudio de caso. Y por lo tanto, hay muchos detalles interesantes para mí. Espero que también sean interesantes para ti.

Soy de los Países Bajos. Y como se introdujo, trabajo para una empresa llamada Chromatic. Pero mi trabajo a tiempo completo es mantener Storybook. Así que tengo que sacar esto del camino antes de poder hablar de lo que hace funcionar y trabajar a Storybook internamente.

¿Qué es Storybook? Storybook es una herramienta que puedes usar para construir mejores componentes. Porque el principio fundamental de Storybook es que puedes trabajar en ellos de forma aislada. En lugar de trabajar en tus componentes de arriba a abajo, básicamente puedes empezar a trabajar en cualquier componente primero. Puedes catalogar todos esos componentes y todos sus estados, todas las variantes. Y puedes probarlos muy importante. Eso es de lo que trata esta conferencia, ¿verdad? Y entonces definitivamente quieres compartir esos componentes con tus stakeholders. Storybook es bastante popular, lo cual es muy humilde para mí. Todas estas empresas están usando Storybook. Y la razón es que en algún momento cuando estás construyendo aplicaciones, podrías empezar con algunos componentes fáciles. Y todo parece super fácil. Pero en algún momento, alcanzas un nivel de componentes que es simplemente complejo. He visto componentes de como 5,000 líneas de código. Y todo está contenido dentro del archivo. Como si pudieras entender todo, podrías. Pero a menudo, aprendes cómo se ejecuta el código y cómo funciona por cómo se usa.

2. La Premisa de los Componentes y Storybook

Short description:

La premisa de los componentes es que puedes usarlos en todas partes. Storybook reúne diferentes casos extremos y te permite visualizarlos. Estos casos extremos pueden ser combinatorios, combinando varios estados e idiomas.

La premisa de los componentes es que puedes usarlos en todas partes. Entonces, si un componente que es complejo tiene todas estas diferentes variaciones y variaciones en la aplicación, bueno, no vas a buscar en toda la aplicación y buscar todos esos casos de uso. Así que eso es realmente de lo que se trata Storybook. Está reuniendo todos esos diferentes casos extremos extraños que quizás ni siquiera encuentres normalmente en tu aplicación y los reúne para que puedas visualizarlos allí.

A menudo se pasa por alto que estos casos extremos extraños pueden ser combinatorios. Entonces, un estado de carga y un estado no autenticado y un idioma diferente pueden unirse todos juntos.

3. Complejidad y Pruebas de Storybook

Short description:

Storybook es una aplicación web compleja que funciona junto a tu propia aplicación web. Trata con múltiples constructores, frameworks, gestores de paquetes y soporta tanto TypeScript como JavaScript. Hacemos que Storybook sea altamente configurable con banderas de características y modularizamos nuestro conjunto de características en complementos. La compatibilidad hacia atrás es un desafío, pero proporcionamos guías de migración claras. Probar Storybook implica un monorepo con más de 80 paquetes.

Muy bien. Con eso fuera del camino, puedo empezar a hablar de mi presentación actual, ¿verdad? Así que Storybook es, por sí mismo, bastante complejo. Y eso es por lo que hacemos. Storybook es como una aplicación web que arrancas junto a tu propia aplicación web. Y entonces tenemos que lidiar con lo que tu aplicación web hizo porque estamos mirando el mismo código fuente que tu aplicación web.

Así que tenemos que lidiar con múltiples constructores, Webpack y Vite. Tenemos que lidiar con múltiples frameworks como React, Vue, Angular, Svelte, etc. Y luego están los meta frameworks superpuestos a esos, como Next.js y SvelteKit. Tenemos que lidiar con múltiples gestores de paquetes, npm, yarn, pnp y pnpm. A algunas personas les encanta TypeScript, incluyéndome. Pero luego algunas personas sienten que, no, no quiero una capa de traducción entre escribir mi código y ejecutar mi código, lo cual también es válido. Y así que apoyamos ambos lenguajes. Y tratamos de apoyarlos a ambos por igual.

Y algo acaba de salir mal con las diapositivas. Y luego, encima de eso, todas esas cosas están fuera de nuestro control. Pero también nos complicamos la vida añadiendo más banderas de características y haciendo que Storybook sea muy configurable. Porque queremos que cualquiera pueda usar nuestra herramienta, pero eso significa que muchas personas se convierten en muchas opiniones. Y hacer feliz a todo el mundo significa que debes añadir configurabilidad. Intentamos modularizar nuestro conjunto de características en complementos. Y queremos permitir que cualquier otra persona cree tales conjuntos de características también. Así que en realidad tenemos una API de complementos de la comunidad que cualquiera puede usar. Y luego el elefante en la habitación, honestamente, es la compatibilidad hacia atrás. Así que Storybooks ha existido durante unos 7 a 8 años. Y así nuestra base de código ha cambiado mucho. Nuestra mentalidad, nuestras ideas de lo que los Storybooks deberían hacer, en realidad ha cambiado mucho. Pero al mismo tiempo, no queremos decir a los usuarios, como, lo que has estado haciendo durante los últimos N años, simplemente deséchalo, y haz esta otra cosa en su lugar. O cuando tenemos que hacer algo así, queremos darles guías de migración claras, o incluso auto-migraciones.

Muy bien, así que pruebas Storybook, y pruebas toda esa complejidad. Saquemos de en medio las cosas fáciles. Tenemos un monorepo con más de 80 paquetes.

4. Pruebas e Interfaz de Usuario de Storybook

Short description:

Usamos TypeScript para asegurar la interconexión del código y aumentar la confianza. ESLint ayuda con los errores sutiles, y las pruebas unitarias cubren las traducciones fáciles. Storybook tiene su propia interfaz de usuario, con componentes e historias dentro de Storybook.

Sí, eso es parte de lo fácil. Usamos TypeScript en toda nuestra base de código para asegurarnos de que todos estos paquetes diferentes y todas estas rutas de código, se interconectan correctamente. TypeScript es un factor enorme de cuánta confianza tenemos en nuestro código. Usamos ESLint para cuidar algunos de los errores sutiles que podrías encontrar. Y luego, obviamente, tenemos un montón de pruebas unitarias para todos los pequeños fragmentos de código individualmente. Cualquier cosa que sea una traducción fácil de A a B, tenemos pruebas unitarias para ello. Y luego, curiosamente, Storybook tiene algo de su propia interfaz de usuario, que está escrita en React. Y así tenemos un Storybook para Storybook. Tenemos un montón de componentes de interfaz de usuario que tienen historias que componen Storybook. Y luego puede ser bastante meta donde ves una pieza de Storybook dentro de Storybook.

5. Pruebas de Storybook y Rendimiento

Short description:

Si alguien añade Storybook a su proyecto, necesita asegurarse de que todavía funciona y puede crear una compilación. También se deben probar los complementos y los cambios de configuración. El rendimiento y el tamaño de la instalación son factores importantes, y la fusión de PRs no debería impactar negativamente en ellos. También se debe monitorear el tamaño de la versión estática de Storybook.

Muy bien. Lo difícil. Porque esto es realmente algo que nos mantendría despiertos por la noche si no lo tuviéramos. Si alguien añade Storybook a su proyecto, ¿funciona? Después de haberlo añadido, ¿Storybook sigue funcionando? ¿Y puede crear una compilación? Si añaden complementos, ¿funcionan? Si cambian algunas configuraciones, ¿esas configuraciones hacen lo que se supone que deben hacer? Muchas de nuestras configuraciones en realidad se convierten en la configuración de algunas otras herramientas. Si configuras Storybook para soportar MDX, en realidad configuramos Webpack para que soporte MDX. Así que nuestras pruebas también prueban muchas cosas como los gigantes en los que nos apoyamos. Y otra parte importante para Storybook, muy importante para nosotros, algo en lo que nos hemos enfocado mucho en el último año y medio es el rendimiento y el tamaño de la instalación. Y para nosotros, es realmente importante saber que cuando fusionamos PRs, ¿es el rendimiento el mismo o es mejor? ¿Es peor? ¿Es un intercambio aceptable para hacer? Y lo mismo para el tamaño de la instalación y ¿qué tan grande es cuando creas una versión estática de tu Storybook? ¿Qué tan grande es eso? ¿Está aumentando con este PR? ¿Sí o no?

6. Configuración de Next.js y Storybook con NPM Proxy

Short description:

Simplemente hacemos el triple A: organizar, actuar y afirmar. Configurar un nuevo proyecto Next.js y añadir Storybook no es fácil. La CLI de Storybook hace diferentes cosas basándose en el directorio existente del proyecto. Necesitamos un proxy NPM para probar el código de nuestro repositorio. Descargamos y compilamos paquetes locales, configuramos el proxy NPM y publicamos los paquetes. Luego podemos configurar el proyecto, añadir Storybook y hacer modificaciones clave en la configuración de Storybook. Realizar estas comprobaciones lleva tiempo.

Entonces, testing es súper fácil. Simplemente hacemos el triple A. Tenemos un organizar. Simplemente configurar un proyecto Next.js. Fácil. Y luego actuar, simplemente añadir Storybook a él. Súper fácil. Y luego la afirmación, supongo que simplemente abrir el Storybook.

Bueno, no queremos hacer esto manualmente todo el tiempo, ¿verdad? Como definitivamente no. Y estos pasos no son súper fáciles porque configurar un nuevo proyecto Next.js necesita una conexión a Internet activa. Necesita hablar con NPM. Añadir Storybook también invoca una CLI que normalmente invocarías a través de algo como NPX. Y luego va y habla con NPM de nuevo para descargar los paquetes correctos basándose en el archivo o carpeta en el que se encuentra.

Así que la CLI de Storybook hace diferentes cosas basándose en lo que ya está en el directorio en el que la estás ejecutando. Así que si tienes un proyecto de vista, la CLI de Storybook añadirá Storybook para vista a él. Si estás usando React, añadirá Storybook para React a él, etc. Así que en esta prueba, si fuéramos a escribirla tal como está, hay otro factor de complicación porque, bueno, no queremos probar cosas que ya están en NPM, ¿verdad? Eso sería un poco tarde.

Así que queremos probar el código que está en nuestro repositorio, pero entonces la CLI viene de NPM. Y va a hablar con NPM para descargar el código. Así que lo que necesitamos es como un proxy NPM delante de todo esto. Y ese proxy NPM necesita estar lleno de cosas, ¿verdad? Y así, para llenar ese proxy con los paquetes que vienen de nuestro repositorio, necesitamos ir y conseguir ese repositorio. Necesitamos descargar todos los paquetes para hacer que eso funcione. Necesitamos compilar todos esos paquetes locales, luego configurar el proxy Ferdacho NPM y publicar los paquetes. Y luego podemos configurar el proyecto. Luego podemos añadir Storybook a él. Y en realidad podríamos querer hacer algunas modificaciones clave en la configuración de Storybook porque podríamos querer probar esas. Y luego podemos simplemente realizar esas comprobaciones.

Bien, casi estamos allí. No queremos hacer todo esto de una vez por cada línea de código que cambiamos. Eso sería horrendo. Esto lleva algún tiempo para ejecutar todo esto.

7. Flujo de Trabajo de Pruebas e Integración con CI

Short description:

Para garantizar pruebas eficientes y soporte para diversas configuraciones, compilamos y publicamos 80 paquetes, configuramos Storybook en 50 proyectos, realizamos 5 modificaciones y ejecutamos 8 pruebas. Aunque ejecutar estas tareas en paralelo en CI ayuda, es crucial considerar el flujo de trabajo para los mantenedores diarios de Storybook. Para proporcionar una retroalimentación rápida, hemos creado un script que permite pruebas dirigidas y maneja el estado del repositorio y la caché. El script es el mismo para las ejecuciones en CI y locales, y los trabajos fallidos de CI proporcionan un comando simple para reproducir el problema.

Esto lleva algún tiempo ejecutar todo esto. Entonces, si queremos hacer esto más a menudo que dos veces al día, necesitamos todo tipo de capas de caché en medio. Pero el alcance es aún mucho mayor que eso. Solo te mostré un proyecto, ¿verdad? Pero, de nuevo, apoyamos muchos tipos diferentes de proyectos. Apoyamos proyectos generados por Vue CLI. Apoyamos CRA. Apoyamos Next.js y Vite CLI. Muchos de estos generadores tienen todo tipo de banderas para generar con diferentes idiomas, etc. Y, como dije, queremos apoyar y probar la multitud de configuraciones que permitimos a los usuarios establecer. Y no solo tenemos una rápida comprobación de si Storybook funciona, sino que queremos comprobar varias cosas. Queremos comprobar si el corredor de pruebas funciona. Queremos probar si la construcción estática funciona, etc. Entonces, el escenario real se ve más o menos así. 80 paquetes para compilar, 80 paquetes para publicar, 50 proyectos diferentes para configurar, a los que necesitamos agregar Storybook, y 5 modificaciones diferentes para hacer, y luego unas 8 pruebas para ejecutar.

Ahora, afortunadamente, el CI, si estamos ejecutando esto en un CI, podemos hacer muchas de estas cosas en paralelo. Y por lo tanto, no tiene que llevar mucho tiempo, pero aún así lleva algún tiempo. Pero es muy importante no pensar solo en CI. Es importante para lo que este flujo de trabajo y todas estas pruebas significan para el mantenedor promedio de Storybook día a día. ¿Cómo te aseguras de que el PR en el que estás trabajando funciona? Bueno, podrías simplemente subirlo a GitHub y esperar al CI, pero definitivamente quieres poder hacerlo localmente también y obtener un ciclo de retroalimentación decentemente rápido. Entonces, lo que hemos hecho es que hemos creado un script que cualquiera en el repositorio puede invocar con una prueba o paso objetivo específico en mente. Entonces, quiero probar si una prueba de extremo a extremo después de una construcción estática, si eso funciona. Entonces puedes apuntar a esa prueba específica. Y luego el script simplemente averigua exactamente cuál es el estado del repositorio en este momento en toda su caché que hacemos. Y luego puede comenzar desde el lugar correcto en el tiempo. Y luego, lo importante es que el script es el mismo en el CI que cuando se ejecuta localmente, lo que significa que cuando un trabajo de CI falla, que es más o menos el punto de un trabajo de CI, ¿verdad? Un trabajo de CI debería decirte cuando algo está mal. Si un trabajo de CI nunca falla, entonces algo está realmente mal. Entonces, definitivamente estamos bien allí. Nuestros trabajos de CI fallan mucho. Pero lo importante es que cuando el trabajo de CI falla, entonces al final solo dice ejecuta esta única línea de código en tu línea de comandos y podrás reproducirlo.

8. Tarea Yarn y Plantillas

Short description:

Creo que es muy descriptivo. Tarea Yarn end-to-end-dev. Opcionalmente puedes decirle por dónde empezar. Tenemos una larga lista de plantillas que Storybook soporta. La gente real ejecuta Yarn, crea una aplicación Next todos los días. Nuestra configuración de CI implica configuración, creación de sandbox, construcción y pruebas. Tenemos un trabajo diario que ejecuta generadores de proyectos y almacena en caché las salidas.

Y esta línea de código no es super compleja. Creo que es muy descriptiva. Y esto es lo que parece. Tarea Yarn end-to-end-dev. Y luego puedes decirle opcionalmente por dónde empezar. En este caso, digo auto. Y luego especificamos una plantilla.

Y esto me lleva a lo que son las plantillas. Y tenemos una lista bastante larga dentro de nuestro monorepositorio describiendo todo tipo de plantillas que Storybook soporta oficialmente. Y oficialmente tenemos todas estas pruebas para. Y simulan lo que los usuarios hacen en el mundo real. La gente real ejecuta Yarn, crea una aplicación Next todos los días. Y crean su próxima aplicación de esa manera. Y luego pueden elegir opcionalmente el dash dash JavaScript como hice aquí. Y luego básicamente describimos en el mundo real, hay estos proyectos que Storybook soporta. Y son los proyectos que usamos para construir todas estas pruebas.

Y así es como se ve nuestra configuración de CI. Tenemos algo de configuración que hacer. Así que esta construcción tarda poco más de tres minutos. Y luego creamos todos estos sandbox. Y luego los construimos todos. Y luego los probamos todos. Y si tuviera que acercarme a los sandbox de construcción aquí. Estos están ejecutando muchos, muchos proyectos todos al mismo tiempo. Lo cual no es barato. Pero funciona. Así que todos estos proyectos se están ejecutando en paralelo completo. Y si uno de ellos falla, lo sabremos. Algo que nos dimos cuenta es que estos proyectos, estos sandbox, en los que arrancamos Storybook, en realidad no cambian tan a menudo. Así que tenemos un trabajo diario que ejecuta estos generadores de proyectos. Y luego almacena estas salidas en un repositorio.

9. Caché, Plantillas e Informes de Errores

Short description:

El caché es útil para acelerar la clonación del repositorio y rastrear los cambios en la salida del generador de Next.js con el tiempo. Nos ayuda a adaptarnos a las nuevas versiones y a pedir a los usuarios que creen reproducciones de problemas. Los usuarios pueden elegir plantillas en storybook.new, iniciar un proyecto con Storybook inicializado y presentar informes de errores sin comprobar nada.

Y resulta que este caché es súper útil. No solo para nosotros, sino también para otros. Así que clonar un repositorio es mucho más rápido que ejecutar este generador normalmente. Pero también es importante, podemos ver cuál es la salida del generador de Next.js con el tiempo. Así que podemos ver cuál es la salida a medida que cambia. Y esto nos da pistas para si Storybook falla al inicializarse en una nueva versión de Next.js, por ejemplo. Como qué cambios internos hicieron. Para que podamos adaptarnos a ello y mantenernos compatibles con el futuro pero también con versiones anteriores. Y también podemos usar este caché para pedir a los usuarios que creen reproducciones de problemas. Así que esto está en realidad vinculado a StackBlitz. Y si usas storybook.new, puedes elegir una de estas plantillas. Y empezar un proyecto y obtener Storybook inicializado encima de él. Y puedes presentar un problema que esté demostrando el error. Sin tener que comprobar nada.

10. Pruebas, Rendimiento y Publicación

Short description:

Inyectamos más componentes e historias en Storybook para mejorar la cobertura. Probamos la construcción de la caja de arena, el modo de desarrollo y ejecutamos pruebas con diferentes herramientas. Monitoreamos el rendimiento de Storybook con el tiempo y lo comparamos con futuros PRs. Nuestra cadencia de lanzamiento es cada 4 a 6 semanas, con versiones principales una o dos veces al año. Podemos hacer lanzamientos alfa con frecuencia y crear fácilmente lanzamientos canarios. Los lanzamientos escalonados permiten la fusión continua de PRs en la rama de desarrollo. La automatización ayuda a crear registros de cambios.

Bueno, hemos hecho toda esta organización. Ahora actuemos. ¿Qué es lo que realmente probamos? Así que cuando inicializas Storybook tú mismo como usuario final, solo obtienes como tres historias y tres componentes. Eso obviamente no es suficiente para obtener una buena cobertura. Así que inyectamos un montón de más componentes e historias. Comprobamos si cada caja de arena puede ser construida estáticamente. Y si el modo de desarrollo funciona. Lo probamos usando el corredor de pruebas. Y lo probamos con los dramaturgos. Y también lo probamos de manera importante con chromatic. De lo cual mi colega Ruben hablará más en una charla posterior.

También nos aseguramos de que Storybook se vuelva más rápido y pequeño con el tiempo. Porque tomamos data de todos estos pasos de caché y lo ponemos en una database. Y podemos ver cuánto tiempo tardaron estos pasos. Así que cuando estamos construyendo la versión estática de Storybook. Para luego ejecutar una prueba de extremo a extremo en ella. Tomamos ese tiempo en cuánto tiempo tomó. Y podemos compararlo con futuros PRs.

Bien, también quiero decir algo sobre la publicación. Nuestra cadencia de lanzamiento es cada 4 a 6 semanas. Intentamos hacer una versión principal aproximadamente una o dos veces al año. Podemos hacer lanzamientos alfa bastante a menudo. A menudo varias veces a la semana. Y podemos tomar cualquier PR y hacer un lanzamiento canario con unos pocos clics del botón. Hacemos lanzamientos escalonados. Lo que significa que podemos obtener PRs fusionados en nuestra rama de desarrollo prácticamente constantemente. No necesitamos esperar. Y luego tenemos una forma muy fácil de crear un PR que está representando efectivamente. Si fusionamos esto hacemos un lanzamiento. Y hay un montón de automation para crear el registro de cambios automáticamente allí también.

11. Gestión de la Documentación de Storybook

Short description:

Tenemos documentación para todas las versiones de Storybook, lo que permite a los usuarios acceder a la información relevante incluso cuando utilizan versiones antiguas. La documentación se gestiona en el monorepo y se almacena en Git para el control de versiones. El front end del sitio web de documentación recupera el contenido de GitHub en función de la versión deseada.

Un aspecto a menudo pasado por alto para un proyecto como este. Es que también tenemos documentation. Y esta documentation no es solo para una versión. Sino para todas las versiones que hemos publicado. Porque alguien que está usando Storybook 7.x. Todavía quieren poder leer cómo deben hacer las cosas. Aunque hayamos lanzado Storybook 8.

12. Gestión de Documentación y Desafíos de CI

Short description:

Tenemos un front end para el sitio web de documentación gestionado en el monorepo, lo que nos permite agregar documentación junto con las características. Git se utiliza para mantener el contenido en el historial. Nuestro mayor error fue equivocarnos en la paralelización, lo que provocó que una plantilla afectara el fallo de las demás. Almacenar y restaurar el espacio de trabajo lleva la mayor parte del tiempo en nuestro CI. Se espera que algunos entornos de pruebas fallen, lo cual es problemático para las versiones alfa. Me he pasado bastante de tiempo.

Entonces, la forma en que funciona es que tenemos un front end para el sitio web de documentation en otro lugar. Pero luego el contenido del sitio web de documentation se gestiona en el monorepo. Lo que te permite cuando estás añadiendo características. También añadir la documentation junto con ella. Lo cual es genial. Y luego Git es simplemente una forma perfecta de mantener ese contenido en un historial también.

Así que el front end hace solicitudes a GitHub. Para extraer el contenido de la versión correcta que la gente quiere mostrar. Aprendimos un montón de lecciones escribiendo todo esto y haciendo todo esto. Diría que nuestro mayor error fue equivocarnos en la paralelización. Así que la separación de preocupaciones, supongo. Así que cuando te mostré ese gráfico de nuestro CI. Observa cómo la construcción de entornos de pruebas es una cosa. Que todos se ejecutan en paralelo. Pero eso significa que si la cosa next.js o Vue CLI se rompe. Entonces ese trabajo de CI simplemente se detiene. Y no ejecutamos nada más. Así que estamos constantemente corriendo para asegurarnos de que todo funciona. Y así una plantilla puede afectar el fallo de las demás.

También notamos que almacenar y restaurar el espacio de trabajo. Que es una característica de CircleCI de la que dependemos mucho. Lleva mucho tiempo. De hecho, está tomando la mayor parte del tiempo en todo nuestro CI. También notamos más tarde que no todos los entornos de pruebas son igual de importantes. Lo que significa que tenemos algunos entornos de pruebas que esperamos que fallen a veces. Lo cual es realmente malo debido al error anterior que hemos cometido. Porque algunos de estos entornos de pruebas son para versiones alfa de cosas que queremos apoyar. Pero entonces esos no son estables en sí mismos. Y esa es mi charla. Creo que me he pasado bastante de tiempo.

13. Mejorando el Tiempo de Ejecución de las Pruebas y la Experiencia del Desarrollador

Short description:

Hice un fork de Storybook el verano pasado y ejecuté la prueba. Estábamos probando replay con él. Tarda unos 16 minutos para que un PR pase de iniciar la construcción de CI a ponerse en verde. Los desarrolladores tienden a depender del CI para su primer PR. Es un equilibrio entre la confianza en las pruebas y la experiencia del desarrollador. El objetivo es invertir la paralelización para mejorar el tiempo de ejecución.

Pero muchas gracias por escuchar. Sí, eso fue super interesante. De hecho, hice un fork de Storybook el verano pasado y ejecuté la prueba. Estábamos probando replay con él. Y es obviamente una base de pruebas muy robusta y madura. Así que fue genial ver esos detalles allí.

Una de las preguntas que tenemos aquí es ¿cuánto tiempo lleva ejecutar todas las pruebas en CI? ¿Y se siente productivo para ti en tu día a día? Definitivamente se puede mejorar. Es una cuestión de qué es lo suficientemente rápido para la cantidad de presión que tienes. Así que si tienes un desarrollo tranquilo entonces puedes tomar un poco más de tiempo. Si tienes muchas tareas pequeñas en las que trabajar está bien esperar. Pero para responder a la pregunta creo que tarda unos 16 minutos más o menos para que un PR pase de simplemente iniciar la construcción de CI a ponerse en verde.

Vale, sí y sé que mencionaste hablar sobre esa experiencia de prueba del desarrollador también. Y hacer eso localmente. ¿Encuentras que los desarrolladores tienden a hacer eso antes de pasarlo a CI con bastante frecuencia? Creo que difiere entre un colaborador o un contribuyente que acaba de abrir su primer PR. Creo que es más probable que dependan del CI porque leer la documentación de contribución es mucho trabajo. Así que creo que eso también está bien. Sí, como dijiste siempre es un equilibrio ¿verdad? Entre la confianza y la seguridad que obtienes de la prueba y cuánto tiempo tardan en ejecutarse. Y cómo eso podría impactar potencialmente la experiencia del desarrollador versus la experiencia del usuario final.

Ahora mencionaste que hay algunas cosas que podrías haber hecho hasta ahora para mejorar ese tiempo de ejecución. ¿Puedes hablar un poco más sobre cuáles son? ¿Podrías aclarar la pregunta? Sí, lo siento. Así que mencionaste que hay cosas que podrías hacer para hacer que el tiempo de ejecución sea un poco más rápido. Pero que has trabajado en eso hasta ahora. ¿Qué has encontrado que ha mejorado ese tiempo de ejecución? Así que lo que realmente quiero hacer pero simplemente no he encontrado el tiempo para hacerlo todavía es invertir esa paralización de la que estaba hablando. De manera que efectivamente decimos que cada sandbox tiene su propio carril. Y así una cosa que no se siente como que está perdiendo mucho tiempo. Pero si tenemos como 40 sandboxes y uno tarda como medio minuto en completarse y el otro tarda cuatro. Bueno, la prueba de extremo a extremo para ese primero que sólo tardó como 30 segundos no se iniciará hasta que el otro haya terminado. Y así de nuevo no se siente como mucho tiempo pero siento que probablemente hay bastante tiempo en la mesa. No para obtener la marca de verificación verde final en el PR. Pero a menudo sólo estás esperando una cosa específica que podría ser mucho más rápida.

14. Pruebas de Flags de Características y Uso Móvil

Short description:

En lugar de esperar la verificación final, encontrar cuellos de botella en el camino puede ser útil. Storybook utiliza flags de características, y los sandboxes permiten sobrescribir la configuración. Actualmente, las pruebas móviles no son una prioridad, ya que Storybook se utiliza principalmente como una aplicación de escritorio. Se planean mejoras para la interfaz de usuario móvil en Storybook 8.

En lugar de esperar la verificación final. Sí, siempre es encontrar esos pequeños cuellos de botella en el camino que pueden ayudar mucho. Entonces mencionaste que obviamente Storybook es muy configurable y usas flags de características para eso. ¿Cómo prueba Storybook esos flags de características? Entonces, cuando configuramos esos sandboxes podemos sobrescribir parte de la configuración. Y forzar de alguna manera que el archivo de configuración main.ts de Storybook sea editado. Así que podemos poner eso en el objeto de plantilla. Lo que son esas modificaciones. Y así simplemente tenemos más plantillas que muestran el Storybook con cada modificación.

Muy bien, genial. Sí, veo muchas preguntas. Tenemos tiempo para quizás una o dos más. Pero empecemos con ¿cómo pruebas en móvil? No tenemos pruebas para móvil en este momento. Tenemos pruebas de Playwright en todos esos sandboxes. Y también tenemos pruebas de Chromatic en todos esos sandboxes. Pero no creo que ninguna de esas se pruebe actualmente en una vista de puerto móvil. Definitivamente no en un dispositivo real. No estoy seguro si vale la pena para nosotros desde una perspectiva de costos hacerlo. Porque Storybook se siente como una aplicación de escritorio para mucha gente. Y más como una referencia rápida en un móvil. Así que para nosotros simplemente no es una preocupación de alta prioridad.

Sí, esa iba a ser mi pregunta de seguimiento. ¿Con qué frecuencia ves a la gente usando Storybook en móvil? Y me imagino que probablemente no muy a menudo al menos todavía. Quiero decir que es un poco un problema de huevo y gallina. Donde si Storybook no funciona muy bien en un teléfono, la gente está menos inclinada a usarlo. Y luego estamos menos inclinados a hacerlo un producto muy agradable. Creo que deberíamos invertir el tiempo. Veremos en Storybook 8 que la interfaz de usuario móvil va a ser mucho mejor. Sí, y si alguien está usando Storybook en móvil supongo que asegúrate de que... ¡Estarán felices! Sí, avísale a Norbert y ve cómo todos pueden ayudar con eso. Así que genial. Bueno, creo que eso es todo el tiempo que tenemos. Pero si tienes alguna pregunta adicional para Norbert, de nuevo asegúrate de unirte a él en la sesión de preguntas y respuestas con el ponente. Y nos vemos allí y en la conferencia. Así que muchas gracias. 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

React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
TestJS Summit 2021TestJS Summit 2021
33 min
Network Requests with Cypress
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
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.
JSNation 2022JSNation 2022
21 min
The Future of Performance Tooling
Our understanding of performance & user-experience has heavily evolved over the years. Web Developer Tooling needs to similarly evolve to make sure it is user-centric, actionable and contextual where modern experiences are concerned. In this talk, Addy will walk you through Chrome and others have been thinking about this problem and what updates they've been making to performance tools to lower the friction for building great experiences on the web.

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 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
JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
Featured WorkshopFree
Building instant-on web applications at scale have been elusive. Real-world sites need tracking, analytics, and complex user interfaces and interactions. We always start with the best intentions but end up with a less-than-ideal site.
QwikCity is a new meta-framework that allows you to build large-scale applications with constant startup-up performance. We will look at how to build a QwikCity application and what makes it unique. The workshop will show you how to set up a QwikCitp project. How routing works with layout. The demo application will fetch data and present it to the user in an editable form. And finally, how one can use authentication. All of the basic parts for any large-scale applications.
Along the way, we will also look at what makes Qwik unique, and how resumability enables constant startup performance no matter the application complexity.
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
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
React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
WorkshopFree
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop