Cómo pruebo un millón de estados de UI con cada combinación: Pruebas visuales con Storybook

¿Qué tal, todos? ¿Cómo están hoy? Bien. Está bien. Está bien. Necesito más café. Hombre, mi vuelo hasta aquí, estoy trabajando con solo un par de horas de sueño, así que pido disculpas si las cosas están un poco difíciles hoy. Pero estoy súper emocionado de estar aquí, súper emocionado de pasar tiempo contigo. Estoy un poco preocupado por el tiempo porque, como en 20 minutos, quiero decir, puedo hablar sobre las diferencias sutiles entre los lápices número dos durante 20 minutos. Así que no sé cuánto de esto podremos cubrir a fondo, pero estoy emocionado de cubrir tanto como sea posible.

Ahora, mi objetivo hoy es convencerte de que solo las capturas de pantalla no son suficientes para lo que estamos haciendo hoy y que necesitamos herramientas más robustas para probar nuestra interfaz de usuario. Así que vamos a hablar de eso. Mi nombre es Chan, Michael Chan, Chantastic, como te sientas cómodo. Así es como puedes encontrarme en línea. A principios de este año, di una charla llamada Domando el Multiverso de la UI, que fue un poco más como una versión emotiva de esta charla. Vamos a tomar un pequeño fragmento de eso y luego pasar a un poco más de código. Pero, si quieres más cosas que hablen sobre la sensación del desarrollo de la interfaz de usuario, lo difícil que es y algunos de los desafíos que sentimos pero de los que no hablamos mucho veces, esta será una buena charla de seguimiento para ti.

Así que pasemos directamente a lo que estamos hablando hoy, ¿quién aquí está familiarizado con el testing trophy en React? Ok, solo unos pocos. Ok, ok, las manos están empezando a subir lentamente. Así que creo que probablemente la mitad de ustedes. La idea detrás del testing trophy es más o menos una forma de cuántas pruebas deberíamos escribir en cualquier aspecto, y la más grande de ellas es en esa porción de integración del pastel. Esta es más o menos una distribución de los tipos de herramientas que usamos para los diferentes tipos de testing. Pero se supone que la integración es la parte más grande de eso. Ahora propongo que hay esta gran parte de pruebas de integración que en realidad no hemos integrado en nuestros flujos de trabajo de desarrollo, que es la testing visual. Así que de eso vamos a hablar hoy. Y las herramientas que he estado usando para esto son Storybook con Chromatic. Esas son las herramientas de las que vamos a hablar. Ahora, ambas herramientas derivan de esta mentalidad de ser basadas en componentes. Entonces, ¿cuál es la idea de basada en componentes? ¿Cómo funciona con la testing visual? Bueno, la idea detrás de esto se reduce a cuánto valor podemos extraer de un componente. Tenemos este fragmento de interfaz de usuario realmente genial y aislado. ¿Cómo podemos, supongo que para tomar una metáfora violenta, cuántos pájaros podemos matar con la piedra de un componente? Lo siento, si amas a los pájaros. Yo amo a los pájaros. De hecho, tuve un podcast por un tiempo donde solo revisábamos canciones de pájaros.

Un poco diferente a un podcast de React. Una de las cosas que no hemos explorado mucho es cómo integrar componentes con los navegadores en aislamiento. Hasta este punto, las pruebas visuales a menudo implican llevar toda la pila de nuestra aplicación al navegador y probarla. Y eso puede ser realmente difícil de probar, asegurarse de que los entornos sean correctos, asegurarse de que todas las personas sean correctas. Los componentes te permiten simplemente inyectar un estado y avanzar rápidamente.

Así que quiero describir un poco el problema, y lo llamo el multiverso de la UI. Y es una descripción del desafío multidimensional que tenemos cuando construimos interfaces de usuario. Y sí, como todos nosotros, estaba viendo mucho Marvel en el momento en que estaba pensando en esto. También lo llamo las 10-ish dimensiones de la UI web, o 35,000 estados perfectos. Entonces, cada interfaz de usuario comienza con la cosa que todos creen que están construyendo, la visión muy clara de lo que vamos a hacer. Pero todos sabemos como desarrolladores web modernos que cualquier vista potencialmente tiene tres vistas, un estado de error , un estado de carga y luego el estado de carga exitoso. Y luego va aún más lejos, porque tenemos diferentes variantes de esas Podríamos tener un spinner, podríamos tener un esqueleto, los errores podrían ser un 404, que es claramente diferente de un 500. Y luego para nuestras vistas exitosas, como se multiplican como conejos, ¿verdad? Porque tal vez tengamos 6 puntos de quiebre o algo así en los que realmente pensamos y nos importan. Pero podríamos estar soportando cualquier número de puntos de quiebre en realidad. Esto se complica un poco más multiplicado por la cantidad de motores de navegadores que tienes que soportar. Desafortunadamente, estos mejoran año tras año, pero todavía hay diferencias sutiles. Ahora, argumentaría que las diferencias sutiles no son necesariamente importantes para tener en cuenta siempre y cuando tengas una experiencia consistente dentro de esos motores de navegadores. Y luego tenemos la usabilidad, ¿verdad? ¿Estás usando, como, el tacto, estás usando la vista, estás usando tus oídos? En Estados Unidos, los CDC sugieren que al menos el 4.6% de los estadounidenses tienen ceguera o baja visión. Ahora, es realmente interesante porque he pasado una gran cantidad de tiempo testing y rehaciendo vistas en Internet Explorer para salvar nuestra aplicación para, como, el 1.5, 2% de los usuarios, pero dedicamos tan poco tiempo al 4.6% más de usuarios que no pueden usar nuestros sitios con sus ojos. Y también tenemos, como, las capacidades de los dispositivos. No voy a hablar mucho de eso, pero es parte de la dimensionalidad del desarrollo de UI. Y luego estas vistas se multiplican por toda la complejidad en nuestras aplicaciones. Podría ser solo, como, autorización, eso es una métrica, pero luego tienes, como, todos sabemos lo rápido que los props y el estado y la autorización de una aplicación realmente pueden, como, hincharse desproporcionadamente. Y si tienes el privilegio de tener una aplicación tan popular que necesitas localizarla en diferentes ubicaciones, bueno, ahora tienes al menos dos versiones de las que tienes que preocuparte. Así que solo toma todas esas vistas y multiplícalas por dos. Y si alguna vez has tenido que hacer esto, te darás cuenta de lo mal que tus aplicaciones probablemente se adaptan para hacer ese cambio, porque cada vez que usas un margen derecho para cualquier cosa, como, todo eso es algo que tienes que arreglar ahora. Y luego la documentación. La documentación siempre es un gran problema. Creamos estas bibliotecas de componentes y esperamos que las personas las usen diligentemente, pero necesitamos hacer el trabajo para crear una buena documentación.

Estos son los problemas reales a los que tenemos que enfrentarnos. Ahora hablemos de mis problemas personales. He estado trabajando durante los últimos, como, 12 años en, como, sistemas de diseño, bibliotecas de componentes tipos de trabajo. Y así es como se veían los desafíos a los que me enfrentaba en los últimos años cuando llegué a estas soluciones.

Para cada vista, tendríamos seis puntos de vista, tres motores de navegadores, tres capacidades de dispositivos y cuatro habilidades de los usuarios. Así que eso es 216 estados perfectos por vista. A gran escala, digamos que hay dos tipos de autorización, como, tipos de usuarios. En realidad eran cuatro o cinco. Pero quiero mantener estos números lo más bajos posible. No estábamos haciendo de derecha a izquierda. Así que solo teníamos uno. Así que voy a eliminar eso. Y teníamos dos frameworks de UI. Así que necesitábamos que nuestras cosas funcionaran en React y en Rails. Espera, React y, sí, lo hice bien la primera vez. Así que eso es 864 estados perfectos por vista.

De acuerdo. Vamos a llevar esto un poco más lejos. Ahora vamos a hablar sobre el estilo. Tenemos esquemas de color. Los esquemas de color son muy importantes en estos días. La gente quiere su modo oscuro. Teníamos dos preferencias de contraste para que pudieras tener un contraste bajo o más contraste. Y también admitíamos diez aplicaciones distintas. Así que teníamos este tipo de sistema de diseño de etiqueta blanca que podía ser tematizado para aplicaciones individuales. Si multiplicamos eso, obtenemos este número aproximado de 34,560 estados ideales por vista, lo cual es un poco loco. Y creo que miramos esto y estamos un poco, como, acostumbrados a no pensar en esto. Porque si pensáramos demasiado en ello, simplemente no haríamos el trabajo. Y creo que ese es el enfoque que hemos tomado para testing muchas de estas cosas. Fácil de hacer todo tipo de testing.

Excepto las pruebas visuales en todas estas diferentes dimensiones. Ahora, solo para mostrarles que no estoy completamente fuera de lugar. Este es un archivo de Figma. Alguien escribió una publicación de blog documentando todas las variantes en Figma. Y llegaron a solo en estos dos modos de color, 1,134 variantes. Esto no incluye el soporte de contraste múltiple. No estamos hablando de ventanas gráficas o lógica o autorización. Solo los botones por sí solos. Así que se acumula muy rápido.

Ahora, nuevamente, no vamos a tener mucho tiempo hoy. Quiero dejarles dos enlaces. Vamos a cubrir todo lo que podamos. Y luego les dejaré estos. Si van a Chan.dev 1M, ese será el repositorio de GitHub en el que estamos trabajando en el estado exacto que tengo ahora. Y vean, ¿esto está contando hacia arriba o hacia abajo? Oh, Dios mío, hacia abajo. Luego, YouTube.com/atstorybook.js. He estado cubriendo muchos de estos temas en profundidad. Entonces, todo lo que cubramos hoy también estará disponible allí. Y también pueden verme haciendo algunas poses realmente humillantes. Así que disfruten.

De acuerdo. Vamos a pasar a las demostraciones. Bien. Vamos a echar un vistazo rápido a Storybook. Estoy seguro de que muchos de ustedes han visto Storybook en su estado básico. Este es el Storybook que se genera para ustedes cuando ejecutan NPX Storybook. He agregado un par de bibliotecas para no tener que instalar NPM hoy, pero esto es realmente lo que están viendo. En su base, es un catálogo de componentes. Y al igual que muchas personas, cuando vi por primera vez Storybook, pensé: no necesito eso. Sé cómo colocar un componente en una página.

Como si todo fuera a estar bien. Simplemente crearía Gatsby, colocaría todos mis componentes allí, o lo que sea. Sin embargo, si profundizamos un poco más, veremos que hay muchas cosas realmente geniales que comenzamos a extraer de los componentes. Recuerda, nuestro objetivo es obtener tantas cosas como sea posible de un componente.

Si pasamos a esta página de documentación, podemos obtener ejemplos de código, lo cual es bastante bueno. Copiable y pegable. Pero también tenemos esta cosa realmente genial donde si estás agregando anotaciones de tipo usando o TypeScript, bueno, en realidad podemos extraer todo eso por ti y darte una interfaz de documentación muy agradable para este componente. Pero también podemos llevar eso un poco más lejos. No deberías tener que ser un desarrollador para poder ver cómo todas estas cosas pueden... Cómo todas estas interfaces interactúan entre sí.

Entonces, dado que conocemos todas las interfaces de tipo, creamos un espacio de juego para ti de forma predeterminada. Así que puedo decir que en realidad no quiero que esto sea un botón principal. Puedo hacer que este texto sea realmente largo si quiero. Cambiar el color. Tenemos todo tipo de cosas aquí que puedes usar. Muy genial. Así que voy a volver a Canvas. Eso está disponible para todos estos componentes si hago clic en este panel de complementos aquí.

Otra cosa genial acerca de las historias es que puedo inyectar ciertas cosas en esto. Entonces, si mis componentes están bien diseñados, son una función pura de props, bueno, entonces puedo simplemente lanzar los datos que quiero. Y así se renderizará con los datos que quiero. Puedo pasar objetos, todo ese tipo de cosas. Otra cosa genial es que los componentes no son solo una función de sus props todo el tiempo. También son una función de las interacciones que se pueden hacer con ellos. Así que también tenemos respuestas para eso. Veamos este componente de página que tenemos. Es una composición de todos los botones y el encabezado que tenemos aquí. Y vamos a hacer clic en este estado de inicio de sesión. Así que tenemos la sesión cerrada. Verás el botón de inicio de sesión y configuración, y entramos en la sesión iniciada y vemos este estado de inicio de sesión.

¿Cómo lo conseguimos? En realidad, tenemos una interacción que podemos ejecutar utilizando la biblioteca de pruebas encima de estos componentes, lo cual es realmente genial. Eso significa que podemos derivar historias tanto de los propios componentes como de las interacciones que esperamos que las personas realicen en ellos.

Ahora, sumergámonos un poco en el código. Nunca antes había hecho codificación en vivo frente a un grupo, así que he tratado de hacer todo lo posible para que salga bien, pero ten paciencia. Así que tenemos nuestro storybook en ejecución. Tengo muchos ejemplos si decides ver este repositorio más tarde. Tengo muchas tareas pendientes aquí a las que puedes ir a diferentes partes.

Quiero mostrarte primero la ergonomía de una historia. Importamos el componente que queremos documentar. Simplemente exportamos por defecto un poco de metadatos, el título donde queremos que se muestre esa historia, el componente en prueba para ver por qué es importante. Y luego podemos pasar argumentos por defecto si queremos. Piensa en ellos como props en el mundo de react. Es un término desambiguado para otras bibliotecas.

De acuerdo. Entonces, ¿qué tenemos? Así es como se ven las pruebas. Podríamos escribir JSX de esta manera. Pero tenemos el formato de objeto donde simplemente decimos: hey, queremos hacer una prueba principal, estamos asumiendo que estamos probando este componente, vamos a agregar estos argumentos allí. Podemos ejecutarlo sin argumentos. Podemos pasar los argumentos que queramos. Y en realidad componemos argumentos. Así que aquí abajo podemos decir: hey, quiero usar todos los argumentos del botón grande y principal para componer esta nueva historia. Así que simplemente los expandimos y luego tenemos una nueva historia. Así es como se ven las historias. Hasta ahora, muy fácil.

Ahora, pasemos a la siguiente cosa. Justo aquí. Uno de los valores de storybook es que podemos capturar estos estados que son un tanto no ideales. Hasta este punto, tenemos esta historia de Jane Doe aquí, ¿verdad? Y este es como un nombre muy ideal. Pero si has estado haciendo desarrollo web durante mucho tiempo, sabes que estas vistas se envían con estos estados ideales, no los casos extremos. Así que hagamos un caso extremo aquí mismo.

Vamos a hacer John Jacob Jingleheimer Schmidt. Así que, con un nombre largo, y te voy a mostrar una cosa más. Podemos hacer cosas realmente geniales. Así que, voy a hacer otra prueba aquí, o otro estado de la interfaz de usuario.

Crearemos una historia usando el nombre largo, usando el arco del nombre largo. Pero también vamos a establecer un viewport. Así que, una cosa genial de esta sintaxis de objeto que tenemos es que nos permite hacer parámetros de todo tipo. Así que, no tengo que poner imperativamente esta historia en un cierto estado. Solo puedo decir, hey, el viewport que quiero es este viewport móvil 1. ¿Lo guardé? No, tengo que guardarlo. Voy a darle a esta nueva historia, y aquí vamos. Así que, al saltar a eso, puedo ver, como, bueno, esto no es exactamente ideal. Y luego podemos tomar algunas decisiones basadas en eso. Pero básicamente estamos parametrizando todas las cosas que nos importan en esta historia específica.

¿Cuánto tiempo tenemos? Dos minutos y medio. Genial. De acuerdo. Vamos a tardar un poco más. Así que, ya sabes, sí. De acuerdo. Así que, genial. Teníamos eso. Así que, estas historias son realmente geniales. Ahora vamos a entrar rápidamente en las funciones de juego. Así que, vimos esas interacciones realmente geniales. Quiero pasar aquí a las funciones de juego. Ahora, ¿cómo empezamos a hacer esas interacciones? Bueno, esto es lo que parece esa prueba. Así que, tenemos, de nuevo, vamos a pasar por esto. Tenemos una página. Así que, estamos importando toda esa página.

Esa página es el tema de todas estas historias, y estamos aquí de verdad. Permíteme mostrarte una cosa más. He hecho, solo un poco, todo esto es solo, como, código normal. Puedes escribir tu React aquí. Tengo una página, y esto es solo pasar esas funciones, y he hecho un pequeño, muy pequeño mock donde tengo un componente pequeño que inserto, ya sabes, captura estas acciones y luego devuelve un estado resultante. Así que no quería pasar por alto eso. Muy fácil de simplemente, como, poner los componentes en los estados que deseas.

A partir de ahí, simplemente usamos la biblioteca de testing para interactuar con esta historia. Así que tomamos nuestro lienzo, agarramos ese botón de inicio de sesión. Así que simplemente usamos nuestros coreys para agarrarlo. Y luego simplemente decimos use event, haz clic en ese botón. Súper fácil. Ahora, en realidad, también componemos estas historias, así que vimos una composición de, como, todos los argumentos y parámetros. Pero también vamos a probar estas, componer estas historias. Así que puedo decir, hey, todo desde la función de juego iniciada, quiero ejecutar eso, pero luego también quiero hacer esta otra cosa. Así que voy a escribir una prueba para iniciar sesión y luego cerrar sesión. De acuerdo, súper genial. Tenemos, veamos. ¿Dónde está? Iniciar sesión y luego iniciar sesión y luego cerrar sesión. Ahora esto parece ser lo mismo que el estado de cerrar sesión, pero puedes ver que hemos ejecutado ambas interacciones sobre él para llegar a ese estado. Ahora también ejecutamos afirmaciones de jest aquí, así que voy a importar expect storybook jest, y luego escribir algunas afirmaciones aquí para asegurarnos de que de hecho está llegando a esos estados. ¿Guardé? Sí, lo hice. Así que hacemos clic en el botón de inicio de sesión, afirmamos que Jane Doe está ahí y luego hacemos clic en el botón de cierre de sesión y luego afirmamos que el botón de inicio de sesión está ahí de nuevo. Bastante genial. Bastante genial. Bastante genial. De acuerdo, veamos. Y luego, mira esto. Esto es súper genial. Así que instalé la biblioteca de ejecución de pruebas de storybook, y podemos simplemente ejecutar yarn test storybook.

Y eso va a ejecutar pruebas en modo headless usando headless Chromium para todos nuestros y simplemente ejecutar todas estas pruebas.

Ahora quiero mostrarte algo realmente genial. Ahora esto vuelve a nuestras dimensiones de UI. Realmente no hemos tenido una forma realmente buena de probar la accessibility.

Quiero mostrarte algo realmente genial que estamos haciendo con el Test Runner. Así que voy a entrar aquí y decir que voy a hacer algunos cambios en el Test Runner. Ahora, no soy un súper buen programador, así que literalmente todo lo que ves aquí, simplemente lo copié y pegué. Así que esto está en nuestro blog. Aumentamos o damos alguna configuración al Test Runner para decir que queremos ejecutar la biblioteca de axe-playwright durante esa fase. Así que voy a ejecutar, veamos, yarn test storybook de nuevo. Va a ejecutar todas nuestras pruebas. Oh, maldición. ¿Qué hice? No guardé. Ahí vamos. Nuevamente, no soy un buen programador.

De acuerdo. Vamos a ejecutar eso de nuevo y vamos a obtener algunos errores. Ya sé cuáles son estos errores, pero puedes ver que ejecutó axe-playwright en todas nuestras historias y ahora tenemos la capacidad de decir, como, okay, así que no estamos obteniendo contraste en un par de cosas y luego hacer algunas correcciones. Así que estos son todos CSS. Súper fácil. Voy a hacer algunos cambios rápidos. Ese color estaba un poco bajo. Vamos a cambiar algunos contrastes para todos estos. Ejecutamos nuestras pruebas de nuevo. Oh, tengo que recargar. Tengo que recargar porque cambié CSS. Ahí vamos. Ejecutamos estos de nuevo. Oh, ¿qué hice? Probablemente no guardé un archivo de nuevo. Elimino un comentario.

Oh, gracias. Sí. Programación en grupo. Ahora estamos entrando en ello. De acuerdo. Genial. Ahora todas esas pruebas pasan. Súper impresionante. Oh, sí. Hagámoslo. Esto es realmente genial. Porque esto protege la experiencia del usuario de algo que si eres un usuario orientado visualmente en la web, protege la experiencia de algo que no siempre puedes ver o que no siempre está en tu mente. Porque es algo que es invisible para ti. Pero es la forma en que las personas interactúan con la web la mayor parte del tiempo.

Así que eso fue súper fácil. Como, increíblemente fácil. Y ahora tenemos el beneficio de todas esas cosas. Así que eso es... De acuerdo. Así que eso es todo eso. Quiero mostrarte una última cosa. Mira esto. Incluso podemos hacer esto... Y dije en la... Tenía esa diapositiva al principio. Quema todas las instantáneas con fuego. Bueno, este es probablemente el único caso de uso aceptable de las instantáneas, que es generar... Mira esto. Estoy generando instantáneas para el... ¿Qué es? El árbol de accesibilidad.

Ahora podemos saber con certeza si algo que cambiamos realmente resultó en una regresión en el árbol de accesibilidad. Es súper, súper, súper, súper, súper genial.

De acuerdo. Ahora, para esta parte, hay mucha instalación de NPM. Y esto probablemente sea lo último que cubriremos hoy. Así que quería avanzar rápidamente en eso. Pero quería mostrarte cómo puedes obtener pruebas de regresión visual en menos de dos minutos. Así que voy a explicarlo rápidamente.

Tenemos un video. Primero, tomamos esta biblioteca. Esta es la que estamos viendo hoy. Vamos a colocarla en GitHub. Vamos a Chromatic.com, iniciamos sesión con la cuenta. Ahí vamos. Agregamos un proyecto. Encontramos nuestro proyecto en GitHub. Hasta ahora, muy fácil. Vamos a agregar nuestra biblioteca Chromatic a nuestro repositorio Git. Rápido y fácil. Vamos a ejecutar este script, npx Chromatic. Con nuestro token de proyecto. Va a tomar más tiempo que esto para compilar. Pero luego vemos nuestra compilación en línea. Ahí está. Así que podemos ir a nuestro proyecto y ver todo lo que hizo por nosotros. Muestra todas estas instantáneas, y también muestra estas historias en estado de interacción posterior. También muestra instantáneas del DOM. Así que podemos saber cuándo algo en el DOM cambió. Obtenemos un storybook alojado de forma gratuita desde el principio. Y podemos realizar pruebas en varios navegadores.

Así que eso es lo que estaba mencionando, queremos mantener la consistencia en todos los navegadores. Como tenemos un poco más de tiempo, te mostraré cómo instalar GitHub Action. Nuevamente, solo copia y pega aquí. No estoy tratando de escribir ningún código. Así que copiamos y pegamos eso. Lo vamos a agregar a nuestra GitHub Action. Pegar. Crear un secreto para nuestra GitHub Action. Configuración. Secretos. Acción. Nuevamente, copiar y pegar, todo el camino. Fácil, fácil. Agregamos ese secreto y luego lo confirmamos y enviamos. Vamos a GitHub Actions y luego observamos cómo se ejecutan estas cosas. El primero falló, fue mi culpa. Pero este está bien. Y vamos y podemos ver nuestra compilación. Así que ahora, cada vez que hagamos un push, se ejecutarán todas estas pruebas por nosotros. Tenemos un ejército de robots probando en todos nuestros navegadores, todos nuestros tamaños de pantalla, todo. Súper fácil.

Creo que estoy bastante seguro de que me he excedido. Así que lo dejaremos así. Quiero que revises este Readabook, porque hay algunos pasos adicionales realmente geniales en los, ¿qué es? Creo que tenemos, ¿qué es? Del 14 al 17. Algunas cosas realmente interesantes sobre la integración con Chromatic, la prueba de tus temas, y todo ese tipo de cosas. De todos modos, muchas gracias por tu tiempo hoy. Espero que hayas aprendido algo nuevo sobre Storybook y Chromatic, y comiences a probar visualmente tus aplicaciones. Gracias por tenerme.

Gracias. Gracias, Michael. ¡Sí! ¿Por qué no entras en la cámara de entrevistas? Vamos a hacerlo. ¿Estoy en este lado? Sí, de hecho te has excedido un poco, lo cual es una lástima, porque estaba deseando entrevistarte. ¿Cuánto tiempo me he excedido? Lo siento. Unos 7 minutos. Solo nos quedan tres minutos. ¡Oh, maldición! Está bien. Aquí. Pero ahora estarás a salvo de... De todas las preguntas, lo sé. De todas las preguntas, sí. Lo siento. Bueno, tenemos la sesión de preguntas y respuestas en vivo, ¿verdad? Aquí, esto es para ti. Muchas gracias, Michael. Por favor, sigue con tu tercera mano. ¿Quieres que... Oh, maldición! Oh, no, estoy bien. De acuerdo. Sí, adelante. No, estoy bien. Gracias.

De acuerdo. Vamos a pasar a las preguntas. No estoy seguro... ¿Vemos las preguntas? ¡Sí! Creo que la pregunta más votada es cuáles son los errores más comunes que debemos evitar al usar Storybook. Sé que es una gran pregunta, pero ¿cuál es la cosa más grande que la gente tiende a arruinar? Oh, hombre. Eso es realmente... Esa es una pregunta difícil. No sé si tengo una respuesta realmente buena para eso. Creo... Algo que creo que es realmente importante es encontrar formas de no escribir una historia para cada estado exacto. Uno de los ejemplos que no llegamos a ver fue que estoy probando temas. Y es muy fácil decir, oh, quiero, ya sabes, voy a tener esta historia y quiero presentarla en este tema y ese tema y este modo de contraste. Pero eso se sale de proporción, ¿verdad? Y ahora tienes como siete historias solo para ver los diferentes temas. Uno de los ejemplos que no llegamos a ver es establecer todo eso como un parámetro global. Puedes crear nuevos controles o complementos que coloques en la barra superior muy fácilmente. Y ahora puedes cambiar esos parámetros a través de la barra superior. Y luego en tu entorno de pruebas, en Chromatic, puedes decir, oye, usa esta instantánea, que es una cuadrícula de temas. Así que ahora no tienes que pensar en los temas de una historia. Puedes aplicarlo a cualquier historia. Así que creo que encontrar estrategias como esa, donde puedas mantener las historias simples, pero luego usar los robots para hacer todo el trabajo por ti, es el sueño. Sí, creo que eso también respondió un poco a la pregunta de cómo te ayuda Storybook a verificar miles de estados. Sí, exactamente, porque no quiero escribir historias para cada vista. Solo quiero saber que cuando lo empuje, nada cambió. Así que, sí.

Genial. De acuerdo. Hagamos una pregunta más. Esta es la más votada. Con esta biblioteca de pruebas, ¿deberíamos ahora hacer nuestras pruebas unitarias directamente en Storybook? ¿Es esa la forma en que vamos? ¡Oh! ¡Ah! Bueno, el objetivo del test runner es que puedas integrarlo de la forma que mejor te parezca. Así que si tienes un equipo que es más de ingeniería y se siente cómodo en ese entorno de Jest, ahora puedes llevar algunas de esas cosas al entorno de Jest y usarlo. Sin embargo, tal vez tu línea sea un poco diferente.

Quieres hacer muchas más cosas en el lado visual, poner muchas en Chromatic y luego solo tener algunas de estas cosas donde estás, nuevamente, como testing el árbol de accesibilidad para detectar regresiones, ese tipo de cosas, ejecutarlo en Jest. Pero yo, como persona, tiendo a evitar líneas duras o recomendaciones y simplemente digo, hey, lo que apoye al equipo que tienes y su comodidad, eso es hacia donde deberías ir.

Sí, creo que es una buena nota para terminar. Tenemos tantas preguntas para ti. Creo que estas podrían ser las preguntas más. ¡Oh, vaya! Bueno, entonces lamento haberme tomado tanto tiempo. Pero habrá una sesión de preguntas y respuestas en vivo. Así que si quieres hacer alguna pregunta a Michael, puedes hacerlo en el próximo descanso en la sala de preguntas y respuestas de los ponentes. Desafortunadamente, ahora tenemos que agradecerte, Michael, por tu tiempo y despedirte. Gracias por recibirme. Muy bien, ¡salud! ¡Salud!