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

Rate this content
Bookmark

Estado de error, estado de carga, punto de interrupción incómodo, datos incorrectos, formato deficiente, soporte del navegador. Cada componente puede representar cientos o miles de estados visuales discretos. ¿Cómo lo pruebas? Desactiva manualmente la red, temporalmente. Inserta código incorrecto, solo por un minuto. Toca la pantalla en el borde. Manipula las fijaciones de la base de datos local. El desarrollo frontend tiene tantas dimensiones. El tiempo y la variación resultan en un número infinito de posibilidades de UI. En esta charla, utilizaremos Storybook para desarrollar, probar y documentar progresivamente nuestro trabajo, automatizando el trabajo pesado del desarrollo de UI.

29 min
21 Oct, 2022

Video Summary and Transcription

La charla aborda la necesidad de herramientas más robustas para pruebas visuales en el desarrollo de UI. Explora los desafíos en la construcción de interfaces de usuario, incluyendo vistas múltiples, variantes y puntos de interrupción. Se enfatiza la importancia de la extracción de componentes y las interacciones. La charla también cubre la derivación de historias a partir de componentes e interacciones, pruebas de UI con el ejecutor de pruebas y pruebas de regresión visual con Chromatic. Se discute la automatización de pruebas utilizando GitHub Actions y los errores comunes al usar Storybook. La charla concluye con una sesión de preguntas y respuestas.

Available in English

1. Introducción a las pruebas visuales en el desarrollo de UI

Short description:

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. Hablaremos sobre las pruebas visuales utilizando Storybook con Chromatic, que son herramientas basadas en componentes. La idea es extraer el máximo valor posible de un componente.

¿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.

2. Desafíos en la construcción de interfaces de usuario

Short description:

Los componentes te permiten inyectar un estado y avanzar rápidamente. El multiverso de la UI es un desafío multidimensional en la construcción de interfaces de usuario. Cada interfaz de usuario tiene múltiples vistas, incluyendo estados de error, carga y éxito. Hay diferentes variantes y puntos de quiebre a considerar. Los motores de navegadores, la usabilidad y las capacidades de los dispositivos añaden complejidad. La complejidad creciente incluye autorización, props, estado y localización. Una buena documentación es esencial.

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.

3. Desafíos de gestionar sistemas de diseño complejos

Short description:

He estado trabajando en sistemas de diseño y bibliotecas de componentes durante los últimos 12 años. Los desafíos a los que me enfrenté involucraron múltiples puntos de vista, motores de navegadores, capacidades de dispositivos y habilidades de los usuarios. A gran escala, esto resultó en 864 estados perfectos por vista. Además, teníamos esquemas de color, preferencias de contraste y diez aplicaciones distintas, lo que resultó en 34,560 estados ideales por vista.

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.

4. Desafíos de las pruebas visuales y demostraciones de Storybook

Short description:

Las pruebas visuales en diferentes dimensiones pueden ser desafiantes, especialmente al considerar la multitud de variantes en herramientas como Figma. Con solo dos modos de color, ya hay 1,134 variantes. Esta complejidad se acumula rápidamente, por lo que las herramientas robustas son esenciales. Proporcionaré dos enlaces para una exploración más detallada: Chan.dev 1M para el repositorio de GitHub que estamos utilizando y YouTube.com/atstorybook.js para una cobertura exhaustiva de temas relacionados. Ahora, sumerjámonos en las demostraciones y echemos un vistazo rápido a Storybook, un catálogo de componentes que puede parecer innecesario al principio, pero ofrece características valiosas.

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.

5. Explorando la Extracción de Componentes e Interacciones

Short description:

Hay muchas cosas geniales que podemos extraer de los componentes. Proporcionamos ejemplos de código y documentación de interfaz. También creamos un espacio de juego y permitimos inyectar datos en los componentes. Los componentes no son solo una función de props, sino también de interacciones. Vamos a explorar un componente de página con un estado de inicio de sesión.

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.

6. Derivando Historias de Componentes e Interacciones

Short description:

Podemos derivar historias tanto de los propios componentes como de las interacciones que esperamos que las personas realicen en ellos. Vamos a sumergirnos un poco en el código. Quiero mostrarte primero la ergonomía de una historia. Importamos el componente que queremos documentar. Así es como se ven las pruebas. Tenemos el formato de objeto donde simplemente decimos: hey, queremos hacer una prueba principal. Uno de los valores de Storybook es que podemos capturar estos estados que son un tanto no ideales. Hagamos un caso extremo aquí mismo.

¿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.

7. Explorando Interacciones de la Interfaz de Usuario

Short description:

Vamos a hacer John Jacob Jingleheimer Schmidt. Podemos hacer cosas realmente geniales. Crearemos una historia usando el nombre largo y estableceremos un viewport. La sintaxis de objeto nos permite parametrizar todas las cosas que nos importan en esta historia específica. Estas historias son realmente geniales. Ahora vamos a entrar en las funciones de juego y empezar a hacer esas interacciones. Tenemos una página que estamos importando.

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.

8. Explorando Pruebas de Storybook

Short description:

Usamos la biblioteca de pruebas para interactuar con la historia, agarrando el botón de inicio de sesión y haciendo clic en él. Componemos historias y escribimos pruebas para iniciar sesión y cerrar sesión. Ejecutamos las afirmaciones de jest para asegurarnos de que se alcancen los estados. La biblioteca de ejecución de pruebas de Storybook está instalada para ejecutar las pruebas.

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.

9. Explorando pruebas de UI con el Test Runner

Short description:

Y eso va a ejecutar pruebas en modo headless usando 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 accesibilidad. Quiero mostrarte algo realmente genial que estamos haciendo con el Test Runner.

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.

10. Mob Programming and Generating Snapshots

Short description:

La programación en grupo protege la experiencia del usuario de los usuarios orientados visualmente en la web. Es la forma en que las personas interactúan con la web. Generar instantáneas para el árbol de accesibilidad es un caso de uso aceptable de las instantáneas.

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.

11. Visual Regression Testing with Chromatic

Short description:

Ahora podemos saber con certeza si algo que cambiamos realmente resultó en una regresión en el árbol de accesibilidad. Para esta parte, hay mucha instalación de NPM. Quería mostrarte cómo puedes obtener pruebas de regresión visual en menos de dos minutos. Tomamos esta biblioteca, la colocamos en GitHub, iniciamos sesión en Chromatic.com, agregamos un proyecto, encontramos nuestro proyecto en GitHub, agregamos nuestra biblioteca Chromatic a nuestro repositorio Git y ejecutamos el script npx Chromatic con nuestro token de proyecto. Luego podemos ver nuestra compilación en línea y ver todas las instantáneas e historias en estado de interacción posterior. Obtenemos un storybook alojado de forma gratuita y podemos realizar pruebas en varios navegadores.

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.

12. Instalación de GitHub Action y Automatización de Pruebas

Short description:

Queremos mantener la consistencia en todos los navegadores, así que te mostraré cómo instalar GitHub Action. Copia y pega el código, crea un secreto y observa cómo las pruebas se ejecutan automáticamente cada vez que hacemos un push. Es como tener un ejército de robots probando en todos los navegadores y tamaños de pantalla.

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.

QnA

Conclusion and Q&A

Short description:

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.

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.

Common Mistakes and Integrating the Test Runner

Short description:

El error más común al usar Storybook es escribir una historia para cada estado exacto, lo cual puede salirse de proporción. En cambio, puedes establecer parámetros como globales y usar controles o complementos para cambiarlos fácilmente. Al utilizar estrategias que mantengan las historias simples y permitan que los robots hagan el trabajo, puedes verificar miles de estados sin escribir historias para cada uno. Storybook te ayuda al permitirte saber si algo cambió cuando lo empujas, sin tener que escribir historias para cada vista. El test runner se puede integrar de diferentes formas, dependiendo de lo que sea mejor para tu equipo.

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.

Visual Testing and Q&A Session

Short description:

Puedes poner muchas cosas visuales en Chromatic y probar el árbol de accesibilidad para detectar regresiones usando Jest. Es importante apoyar a tu equipo y priorizar su comodidad. Tenemos muchas preguntas para Michael y habrá una sesión de preguntas y respuestas en vivo durante el próximo descanso en la sala de preguntas y respuestas de los ponentes.

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!

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

TestJS Summit 2021TestJS Summit 2021
33 min
Network Requests with Cypress
Top Content
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.
TestJS Summit 2021TestJS Summit 2021
38 min
Testing Pyramid Makes Little Sense, What We Can Use Instead
Top Content
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.
TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt.In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.

React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.
TestJS Summit 2022TestJS Summit 2022
27 min
Full-Circle Testing With Cypress
Top Content
Cypress has taken the world by storm by brining an easy to use tool for end to end testing. It’s capabilities have proven to be be useful for creating stable tests for frontend applications. But end to end testing is just a small part of testing efforts. What about your API? What about your components? Well, in my talk I would like to show you how we can start with end-to-end tests, go deeper with component testing and then move up to testing our API, circ
TestJS Summit 2022TestJS Summit 2022
20 min
Testing Web Applications with Playwright
Top Content
Testing is hard, testing takes time to learn and to write, and time is money. As developers we want to test. We know we should but we don't have time. So how can we get more developers to do testing? We can create better tools.Let me introduce you to Playwright - Reliable end-to-end cross browser testing for modern web apps, by Microsoft and fully open source. Playwright's codegen generates tests for you in JavaScript, TypeScript, Dot Net, Java or Python. Now you really have no excuses. It's time to play your tests wright.

Workshops on related topic

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
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 Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
Top Content
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
TestJS Summit 2023TestJS Summit 2023
48 min
API Testing with Postman Workshop
WorkshopFree
In the ever-evolving landscape of software development, ensuring the reliability and functionality of APIs has become paramount. "API Testing with Postman" is a comprehensive workshop designed to equip participants with the knowledge and skills needed to excel in API testing using Postman, a powerful tool widely adopted by professionals in the field. This workshop delves into the fundamentals of API testing, progresses to advanced testing techniques, and explores automation, performance testing, and multi-protocol support, providing attendees with a holistic understanding of API testing with Postman.
1. Welcome to Postman- Explaining the Postman User Interface (UI)2. Workspace and Collections Collaboration- Understanding Workspaces and their role in collaboration- Exploring the concept of Collections for organizing and executing API requests3. Introduction to API Testing- Covering the basics of API testing and its significance4. Variable Management- Managing environment, global, and collection variables- Utilizing scripting snippets for dynamic data5. Building Testing Workflows- Creating effective testing workflows for comprehensive testing- Utilizing the Collection Runner for test execution- Introduction to Postbot for automated testing6. Advanced Testing- Contract Testing for ensuring API contracts- Using Mock Servers for effective testing- Maximizing productivity with Collection/Workspace templates- Integration Testing and Regression Testing strategies7. Automation with Postman- Leveraging the Postman CLI for automation- Scheduled Runs for regular testing- Integrating Postman into CI/CD pipelines8. Performance Testing- Demonstrating performance testing capabilities (showing the desktop client)- Synchronizing tests with VS Code for streamlined development9. Exploring Advanced Features - Working with Multiple Protocols: GraphQL, gRPC, and more
Join us for this workshop to unlock the full potential of Postman for API testing, streamline your testing processes, and enhance the quality and reliability of your software. Whether you're a beginner or an experienced tester, this workshop will equip you with the skills needed to excel in API testing with Postman.
React Summit Remote Edition 2021React Summit Remote Edition 2021
87 min
Building a Shopify App with React & Node
Top Content
WorkshopFree
Shopify merchants have a diverse set of needs, and developers have a unique opportunity to meet those needs building apps. Building an app can be tough work but Shopify has created a set of tools and resources to help you build out a seamless app experience as quickly as possible. Get hands on experience building an embedded Shopify app using the Shopify App CLI, Polaris and Shopify App Bridge.We’ll show you how to create an app that accesses information from a development store and can run in your local environment.
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
WorkshopFree
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.