Domina el Multiverso de Componentes

Esta es una charla sobre las pruebas de interfaz de usuario, un problema de herramientas que subestimamos críticamente y su impacto tanto en nuestras aplicaciones, en nuestra experiencia al construirlas y creo que en la web en general.

Ahora, quiero hablar sobre algunas herramientas que creo que faltan en nuestro conjunto actual de pruebas. Así que vamos a hablar sobre algunas herramientas, algunas estrategias que creo que deberíamos empezar a utilizar como desarrolladores frontend e ingenieros de UI, y espero responder a la pregunta que algún fanático me ha estado haciendo desde que subí a este escenario virtual, ¿cuándo este idiota va a quitar esta diapositiva? Todavía no.

Así que amo la web, y amo el buen software, y me he sentido muy decepcionado a medida que hemos visto que la web ha ido ocupando una parte cada vez más grande del desarrollo de software en general. Con la llegada de React Native y Electron, la web ha comenzado a moverse cada vez más lugares en el software en su conjunto, y ha comenzado a ofrecer una experiencia bastante deficiente en todos los aspectos. Ahora, egoístamente, quiero que la web sea mejor, porque la uso todo el tiempo. Amo la web, y quiero asegurarme de que tengamos las estrategias de pruebas necesarias para garantizar que protegemos las experiencias de los usuarios en cada paso del camino.

Ahora que hemos terminado con la introducción, finalmente podemos deshacernos de esta diapositiva. Entonces, ¿quién diablos soy yo? Este es el punto de la charla donde se supone que debo convencerte de que tengo mucha credibilidad, así que simplemente te daré una introducción general sobre quién soy y tú puedes decidir si me encuentras creíble. Confía en ti mismo.

Entonces, en primer lugar, soy Chan, Chantastic o Michael. Puedes llamarme como quieras, cualquiera está bien para mí. Solía presentar un programa llamado React Podcasts hasta que, desafortunadamente, me agoté. Fue mucho trabajo. Si alguna vez has hecho un podcast, sabes que es mucho trabajo, pero durante mi tiempo en React Podcasts tuve la oportunidad de hablar con algunos de los desarrolladores y personas más brillantes que he conocido en toda mi vida. Así que si estás interesado en eso y nunca has escuchado el programa antes, hay un gran catálogo, y si quieres escuchar a algunos de tus desarrolladores favoritos, está ahí para ti.

Ahora, durante mi fase de agotamiento, me enamoré del juego Destiny también. Así que si eres jugador de Destiny, contáctame y podemos hacer algunas incursiones o jugar en el Crucible juntos o algo así. Ahora, no todo fue diversión y juegos. Tuve la oportunidad de trabajar con el equipo principal de React en el Grupo de Trabajo de React, lo cual fue una experiencia realmente increíble, ya que ayudé a dar vida a React 18 en la comunidad y asegurarme de que todos supieran cómo hacer la transición de sus aplicaciones y aprovechar algunas de las nuevas características. También comencé uno de mis espacios en línea favoritos para desarrolladores de React creativos, curiosos y amables. Está en discord.gg. Tenemos muchas personas allí, y te invito a unirte si te gusta pasar tiempo en discords. Lo más relevante para esta charla es que tengo unos 12 años de experiencia en productividad del desarrollador, sistemas de diseño y arquitectura frontend. Ahí es donde he adquirido experiencia en el desarrollo web y de donde provienen muchas de las experiencias que compartiré hoy. Ahora trabajo en Chromatic, y hablaremos sobre ese servicio a medida que avancemos en esta charla.

Nuestro objetivo allí es mejorar la experiencia de usuario en la web. Si has estado en el espacio de React y JavaScript durante un tiempo, probablemente hayas oído hablar del trofeo de pruebas. Permíteme mostrarlo en pantalla ahora mismo. Este es el trofeo de pruebas, visualizado por Kent C. Dodds. Se basa en un tweet de Guillermo Rauch que dice: escribe pruebas, no demasiadas, principalmente de integración. Curiosamente, se basa en un formato de resumen que Michael Pollan utilizó para resumir El dilema del omnívoro, que es un libro muy bueno y un formato de resumen muy bueno para muchas cosas como las pruebas. De todos modos, de ahí viene eso. Este es el trofeo de pruebas. Para esta charla, quiero ponerlo de lado y hablar de él como un continuo y colocar algunas de nuestras estrategias de pruebas en la parte superior. Cuando miramos esta visualización, tenemos algunas cosas.

Tenemos pruebas Estáticas, Unitarias, Integración y de Extremo a Extremo. Estos son todos los tipos de pruebas que podemos escribir para respaldar una aplicación. En el ámbito de las pruebas Estáticas, TypeScript domina en este momento, así que simplemente voy a colocar TypeScript allí. En las pruebas de Extremo a Extremo, escuchamos mucho sobre Cypress. Definitivamente tienen la mayor atención. En el medio, tenemos Jest, u otras bibliotecas similares, que abarcan las pruebas unitarias y de integración. Pongo a Jest aquí porque creo que está muy bien integrado con JSDOM y la biblioteca de Testing, que son herramientas muy populares en el espacio de React específicamente. Aquí es donde se supone que debemos escribir la mayoría de nuestras pruebas. Hay un poco de complicación aquí. Tenemos dos categorías y tres herramientas aquí. Y cada vez que veo una distribución como esta, donde no está particularmente claro qué está sucediendo, me pregunto si no tenemos a dos niños en un abrigo, si no hay alguna idea que es un poco confusa y que aún no hemos descubierto completamente. Ahora, si tuviera que adivinar, diría que el concepto que realmente no hemos dominado es el de las pruebas visuales. Así que de eso se trata esto, pruebas visuales. Hablaré mucho sobre esta diapositiva y la llamaré el continuo de pruebas de UI. Así que si me refiero a eso, me estoy refiriendo a este continuo del que estoy hablando.

Hablemos sobre el multiverso de la interfaz de usuario. Este es el problema al que veo que los desarrolladores front-end se enfrentan en el espacio de las pruebas de integración visual. A veces también me refiero a esto como las 10 dimensiones aproximadas de la interfaz de usuario web, o si me siento especialmente ingenioso, las 35,000 estados perfectos. Vamos a profundizar en eso.

Entonces, cada vez que designamos una vista web, pensamos en ella en su estado ideal. Esta vista perfecta, tal vez la hayamos dibujado en un papel o la hayamos diseñado, pero este estado ideal perfecto para esta vista. Ahora todos sabemos que la vida no es perfecta y tendremos que complementar eso con estados de error y carga. Tenemos una tercera dimensión, que son las complicaciones de los estados de carga y error, para las cuales podríamos tener vistas de esqueleto dedicadas para una página específica. Manejamos diferentes errores de diferentes maneras porque un error 404 es significativamente diferente de un error 500, y así sucesivamente. Ahora tenemos una dimensión adicional, incluso para nuestras páginas exitosas, que son los puntos de interrupción. Entonces no creamos una sola vista. Por lo general, para la web, tenemos varios puntos de interrupción para un sitio web receptivo. Es bastante estándar en estos días. Por lo general, utilizo alrededor de seis, pero para este caso, lo mantendré pequeño, en cuatro. Ahora eso se multiplica nuevamente cuando comenzamos a pensar en los navegadores y cómo nuestras vistas realmente interactúan con el navegador. En este momento, generalmente tenemos tres o cuatro motores a los que la mayoría de las aplicaciones tienen que apuntar, así que pondré cuatro allí. Ahora tomamos eso y lo multiplicamos nuevamente por las habilidades del usuario. Esto podría ser navegación por teclado o navegación por mouse o, ya sabes, tener el sitio leído a través de un lector de pantalla. También tenemos las capacidades del dispositivo. Esto es un poco diferente a las capacidades del usuario porque un dispositivo puede tener pantalla táctil o teclado o mouse, o se puede hablar con él. Y todas esas son formas en las que podemos interactuar con el contenido. Ahora no tengo soluciones para esta parte en este momento, así que no agregaré diapositivas a nuestro universo en expansión de páginas. Así que pasamos por alto eso.

Ahora la mayoría de las aplicaciones en estos días, al menos aquellas que son servicios, tendrán algún nivel de autorización también. Y he duplicado esto varias veces para mostrar diferentes tipos de autorización. Pero además de esto, puedes pensar en la lógica en tus páginas. Cualquier página que tenga, ya sabes, un booleano que cambie la vista, pero lo que no he representado aquí es la lógica combinatoria donde tienes dos propiedades que generan un tercer o cuarto o quinto estado posible. Sé que podrías estar pensando, como, wow, acabas de agregar un montón de páginas. Pero en realidad, este es un número bastante mínimo si consideramos lo complicados que se vuelven los componentes. Y hablaremos más sobre eso en un segundo.

Ahora, si se admite múltiples idiomas, entonces realmente multiplicará toda esta pila de vistas perfectas por cada idioma que se admita. Esto es particularmente importante si se admite el texto de derecha a izquierda, donde la página se volteará efectivamente para admitir el idioma adecuado. Así que estamos hablando de números bastante grandes aquí.

Ahora, si trabajas en el espacio de los sistemas de diseño o bibliotecas de componentes, sabes que también existe esta dimensión de organización, donde podrías tener todo el mundo bajo tu control. Pero tu galaxia de componentes está bajo una presión increíble por las partes de tu organización que adoptaron, tanto de manera intencional como accidental o no intencionalmente. Y cómo algunos de esos equipos o partes de tu organización incluso pueden tener la autonomía para elegir la capa de visualización que utilizan. Tal vez no estén utilizando React. Sé que en mi caso, estábamos utilizando Rails y React. Pero algunos de ustedes podrían tener partes de su aplicación en Backbone o Ember o incluso Vue. Y construir una biblioteca de componentes que sea integral realmente implica admitir todas esas bibliotecas. Así que realmente no puedo asumir los desafíos específicos que enfrenta tu sistema de diseño y biblioteca de componentes. Sin embargo, puedo contarte un poco sobre el mío y hacer los cálculos sobre los problemas que he estado resolviendo en los últimos años, y multiplicar eso.

Estas son las apuestas básicas. Entonces, para cada componente Vue, tendríamos seis puertos Vue, tres motores de navegadores, tres capacidades del dispositivo y cuatro habilidades del usuario. Eso nos lleva a 216 estados perfectos. Bueno, hay un poco más. Tendríamos al menos dos tipos de autorización. Por lo general, eran más como cuatro o cinco. No admitíamos el texto de derecha a izquierda, porque somos una empresa con sede en Estados Unidos, pero sí admitíamos dos frameworks. Eso nos lleva a un total de 864 estados perfectos. Pero no termina ahí, porque ni siquiera hemos hablado sobre el estilo. Así que admitiríamos dos temas, dos modos de contraste y todos ellos podrían multiplicarse por las 10 aplicaciones, que tendrían un tema discreto para cada aplicación. Totalmente loco. Pero en realidad nos lleva a un incomprensible 34,560 estados ideales por componente. Ahora, esto ni siquiera maneja todas nuestras posibilidades de autorización y definitivamente no maneja ninguna lógica combinatoria de props. Absolutamente asombroso. Ahora quiero hablar sobre la parte lógica de esto por un segundo, para mostrarte cuánto pueden crecer exponencialmente los estados de la interfaz de usuario. Este fue un artículo de blog que mostraba un botón que se estaba construyendo y todas las posibles variantes, ni siquiera para modos de contraste adicionales, sino solo para dos temas, claro y oscuro. Y todas las formas en que se podía representar un botón en esta aplicación. Y tenían 1134 variantes.

Solo para este componente. Ahora, creo que tenemos un problema realmente grande. Y muchas veces no nos permitimos sentir el peso de este desafío. Y incluso en este momento podrías estar retorciéndote porque la primera vez que realmente pensaste en todo esto fue ahora mismo. Y muchas veces seguimos adelante simplemente no pensando en esto. Solo nos enfocamos en nuestra tarea actual y dejamos que QA se encargue de informarnos los errores, o simplemente hacemos un desarrollo impulsado por Twitter donde lo lanzamos sabiendo que puede haber cosas malas y la gente nos dirá dónde están.

Ahora creo que uno de los mayores desafíos a los que nos enfrentamos está en la creación de pruebas. Así que quiero hablar un poco sobre la adecuación de las estrategias de prueba en este continuum. Entonces, en primer lugar, las pruebas estáticas son realmente excelentes para las interfaces. Por lo tanto, los lenguajes son excelentes para probar interfaces. Las pruebas unitarias son excelentes para probar la implementación de una unidad de código. Las pruebas de extremo a extremo son realmente excelentes para los flujos, registro, CRUD, actualización de facturación, etc. Y en esta parte de integración, tenemos coordinación. Idealmente, esta es la coordinación de componentes o código. Están separados del stack completo, que es lo que hacen las pruebas de extremo a extremo. Ahora, la integración es principalmente para, voy a limitarlo a cosas no visuales. Y luego lo visual será ese punto de integración donde nuestro código realmente se representa dentro de un navegador.

Ahora hablemos sobre la idoneidad de estas estrategias de prueba según el rol. En la mayoría de los casos, los ingenieros se encargan de las pruebas estáticas, unitarias y de integración. Esto depende de la organización, obviamente. Por otro lado, el equipo de control de calidad suele dominar las pruebas de extremo a extremo. Sin embargo, en el aspecto visual, a menudo nos encontramos con pruebas insuficientes y esperamos que se vea bien en nuestra máquina y que también se vea bien para los demás. Creo que si queremos tener una mejor cobertura de pruebas en este aspecto, necesitamos herramientas que funcionen de la misma manera que la creación de interfaces de usuario y que sean más declarativas.

Por un lado, Jest tiene pruebas de instantáneas y Cypress tiene algunas pruebas de componentes, pero tienen desafíos en cuanto a la forma en que se sienten al crear pruebas visuales. Entonces, ¿cómo producimos pruebas en esta brecha de integración visual? Creo que lo hacemos de forma automática. Ahora quiero hablar sobre algunas cosas. Llamo a esto las pruebas de interfaz de usuario declarativas. Estas son Storybook, Chromatic y la integración continua. Quiero agradecer a mi compañero de trabajo, Varun, por preparar estas diapositivas a partir de una presentación que comparte con nuestros clientes.

Comencemos con Storybook. Cuando pienso en Storybook, realmente se sitúa en la brecha entre el diseño y el desarrollo. Tenemos esta idea de desarrollo basado en componentes donde realmente aprovechamos los componentes y el hecho de que están aislados del resto del entorno de componentes. Nos inspiramos en herramientas como Figma, que tienen estas ideas de hojas de pegatinas para los componentes, y llevamos eso al lado del código. Creamos un entorno que está disponible para cualquier persona con acceso, de la forma que deseen compartirlo, que realmente representa visualmente los componentes y combina eso con la documentación y la capacidad de interactuar con ellos. Estos son componentes vivos. Traemos muchas herramientas con nosotros que ahora podemos compartir en este entorno de desarrollo front-end. Tenemos vistas, que podemos codificar con las vistas que admitimos en nuestra aplicación. Podemos usar herramientas como medidas en lugar de tener que abrir un inspector y medir todo esto, simplemente podemos tenerlo y asegurarnos de que todos nuestros espacios estén correctos y el tamaño sea el adecuado entre los elementos. Podemos resaltar cosas para depurar las interfaces de usuario, todo dentro de este entorno de desarrollo front-end. Además, tenemos pruebas de accesibilidad incorporadas. Esto es algo que normalmente tienes que instalar en tu navegador o a través de alguna herramienta de línea de comandos. Podemos llevar eso a nuestro entorno de desarrollo front-end y asegurarnos de que todos tengan la misma información sobre las auditorías de accesibilidad y si pueden admitir el espectro completo de usuarios en nuestras aplicaciones. Y para mí, sé que hago muchos console.log.wats, o console.log.wats, y podemos tener una amplia variedad de formas de probar nuestros componentes utilizando controles, arquetipos, etc. Tenemos documentación generada automáticamente dentro de Storybook que te permite, simplemente escribiendo un componente, tener documentación que muestre la interfaz de ese componente y las props disponibles para ti. Y tenemos controles, por lo que una vez que se identifican esas interfaces, ahora te ofrecemos un espacio de pruebas donde cualquier persona, independientemente de su capacidad para codificar el componente, puede experimentar con algunas de las props y asegurarse de que lo que están intentando lograr, en este caso el botón, sea posible con la interfaz disponible. Ahora hay una cita, tuve la oportunidad de hablar con Ryan Bayhan en Shopify, y ellos se centran mucho en el poder interfuncional de sus equipos, en la capacidad de los equipos de enfocarse en su experiencia y tener empatía por las otras disciplinas también. Él dice que los controles interactivos de Storybook mejoran la comprensión interfuncional y la comunicación en torno a React, y simplemente me encanta eso.

Ahora Chromatic es la pieza de esto donde realmente podemos obtener algunas pruebas automatizadas. Storybook es realmente bueno para resolver el aspecto organizativo, pero Chromatic es donde se convierte en una herramienta de prueba. Cuando integras Chromatic con tu canal de integración continua (CI), puedes realizar pruebas visuales en comparación con las pruebas visuales previamente aceptadas. Así que cuando cargas tu primera prueba visual, la defines como línea base, y luego cada solicitud de extracción después de eso se comparará para asegurarse de que no se hayan introducido cambios inesperados. Esto no solo está disponible para vistas estáticas, sino que también podemos hacerlo para elementos interactivos. Por ejemplo, podemos tener un botón que abre un modal y luego podemos ejecutar nuestras pruebas para asegurarnos de que se haya hecho clic y se haya abierto correctamente. Muy interesante. También podemos hacer esto en todos los navegadores que admitimos y en todos los tamaños de pantalla. Y todo esto está integrado en tu canal de integración continua (CI), por lo que al enviar una solicitud de extracción, ahora puedes ejecutar tu ejército de robots en todas tus pruebas visuales y asegurarte de que nada haya cambiado. Y así, Brad Frost, quien es una figura destacada en el espacio del frontend, lo expresó de manera muy elocuente. Él dice que las pruebas históricamente han sido difíciles para nosotros porque ha sido como una imagen en tu mente, un modal, e imagina hacer clic en un botón que abre ese modal. Pero al escribir una historia, obtienes la documentación para el componente, las pruebas y un entorno de pruebas, todo de forma gratuita. Ahora, también he estado muy emocionado de trabajar con equipos como Redwood para integrar aún más las pruebas de Storybook utilizando Testing Library, MSW y Prisma en el marco y obtener cosas realmente geniales con características como los generadores de Redwood, que simplemente generan todos estos diferentes estados de éxito, inicio de sesión, error y carga de forma automática. Muy interesante.

Entonces hablamos de storybook, chromatic, pruebas visuales, ¿por qué debería importarte? Bueno, creo que estamos igualmente maldecidos, y eso es porque amamos la web. La web es increíble. Creemos en todo, en todas partes, al mismo tiempo, ahora y para siempre, accesible para todos. Y a pesar de todas sus fallas, ninguna plataforma excepto la web abierta realmente cumple esa promesa. Y si soy completamente honesto, hay algo divertido en crear estos mundos, estos universos que controlo completamente. Y cuando se resisten, tengo que aprender nuevas estrategias para volver a controlarlos nuevamente. Y mantener este universo, este multiverso de la interfaz de usuario que hemos creado bajo control. Desafortunadamente, deja de ser divertido cuando las cosas se salen de control. Y tendemos a agotarnos de manera interesante, desafortunadamente, cuando queremos implementar nuevas características, pero cada vez que implementamos algo, llegan cien nuevos informes de errores o diez personas se quejan de lo que hemos hecho. Y nos volvemos tímidos acerca de lo que queremos lanzar al mundo. Así que comenzamos a decir que no a nuevas ideas, características y bibliotecas porque tememos que se rompan. Nuestros productos comienzan a languidecer y nuestros equipos comienzan a irritarse. E inevitablemente, nos convertimos en estos villanos retorcidos que juramos nunca ser cuando éramos ambiciosos y creíamos que todo era posible. Simplemente nos sentamos y disfrutamos del hecho de que realmente no hay nada que podamos hacer que tenga éxito. Pero quiero que la web sea grandiosa. Quiero que mis aplicaciones sean grandiosas y quiero que tus aplicaciones sean grandiosas. Especialmente tus aplicaciones, si soy cliente de tus aplicaciones. Ahora, creo que hasta este punto, no hemos tenido las herramientas de frontend que realmente representen la forma en que trabajamos, la forma en que trabajamos en un espacio visual, uno complicado por múltiples motores de renderizado y múltiples bibliotecas. Y hay una gran discrepancia de impedancia entre la forma declarativa en que escribimos código y la forma imperativa en que se espera que escribamos pruebas. Antes de los componentes, realmente nunca tuvimos las herramientas adecuadas para manejar la integración con nuestro código y los navegadores, y para escribir pruebas de una manera declarativa que no requiera la pila completa como lo hace una prueba de extremo a extremo. Entonces, las pruebas visuales son una categoría completa de pruebas de integración basadas en el navegador que estamos apenas comenzando a explorar. Y estas son las herramientas que uso, amo y recomiendo, pero realmente espero que comiences a explorar este espacio de pruebas de integración visual en tus aplicaciones y lo hagas de tal manera que se integre con las herramientas que ya estamos utilizando en este espacio de integración. Ahora, nuevamente, la encapsulación, el aislamiento de un componente realmente nos ha permitido hacer cosas que nunca antes habíamos hecho e integrarnos con el navegador de una manera que no requiere la pila completa. Y sé que he dicho eso un par de veces, pero creo que es algo tan importante de recordar, que las pruebas visuales son una prueba de integración con el navegador, pero sin la pila completa. Ahora, una de mis citas favoritas es de Sandy Matt, un desarrollador héroe mío, y dicen, prueba el muro a tus espaldas. Ahora, quiero que tengas la seguridad de que nunca romperás la interfaz de usuario para ningún usuario nunca más, que cada decisión que hayas codificado para cada vista, para cada punto de interrupción y tipo de usuario esté defendida, contenida y controlada. Así que puedes avanzar con confianza hacia el futuro. Tenemos una gran tarea por delante, pero armados con las herramientas adecuadas y los paradigmas de pruebas, espero con ansias el futuro de la web, controla tu multiverso de la interfaz de usuario y mejoremos la experiencia de usuario de la web juntos. Soy ChanTastic, puedes encontrarme en chan.dev, en chantastic, discord.gg/lunchdev. Y si estás interesado en storybook, puedes visitarnos en storybook.js.org, en storybookjs y discord.gg/storybook. Muchas gracias por escuchar. Espero verte en línea.