Prueba tu interfaz de usuario en el navegador REAL

Rate this content
Bookmark

Imagina escribir una función compleja sin pruebas unitarias. Tendrías que verificar cada escenario manualmente, una y otra vez. Engorroso, pero así es como la mayoría de los equipos construyen interfaces de usuario.


Imagina si pudieras construir interfaces de usuario y probar interfaces de usuario en el mismo lugar. Si tus componentes incluyeran expectativas de cómo se suponía que debían comportarse, sabrías al instante cuando se rompieran.

Storybook proporciona un enfoque organizado para construir interfaces de usuario. Documentas los casos de uso de un componente como historias, que luego se representan de forma aislada. Las historias son como pruebas, pero para la interfaz de usuario. Las pruebas de interacción de Storybook te permiten escribir secuencias de interacción y verificar expectativas en la propia historia. Esto te permite ejecutar y depurar pruebas de interfaz de usuario en el mismo entorno en el que se desarrollan los componentes de interfaz de usuario: tu navegador.

33 min
19 Nov, 2021

Video Summary and Transcription

Storybook es una herramienta poderosa para construir componentes de interfaz de usuario y probarlos. Permite una fácil reutilización y compatibilidad con otras herramientas. Storybook 6.4 introduce historias interactivas y codificación en vivo, lo que facilita la creación y depuración de componentes complejos. También se integra con bibliotecas populares de pruebas como Jest y Testing Library. Storybook tiene como objetivo cerrar la brecha entre las pruebas de extremo a extremo y las pruebas unitarias, proporcionando opciones de pruebas automatizadas para componentes de interfaz de usuario.

Available in English

1. Introducción a Gert Hengeveld y Storybook

Short description:

Hola, soy Gert Hengeveld, un ingeniero de software full stack en Chromatic. Hoy estoy emocionado de mostrarte algo en lo que he estado trabajando durante los últimos meses. Las interfaces de usuario se construyen utilizando componentes, y el desarrollo basado en componentes aporta muchos beneficios. Aún es difícil realizar pruebas de UI correctamente, y las herramientas de prueba existentes dejan mucho que desear. Storybook es una herramienta para construir componentes de UI, proporcionando un entorno aislado y compatible con todos los principales frameworks frontend.

Chromatic fue fundado por los mantenedores de Storybook y proporciona una plataforma para la prueba de regresión visual y revisión sobre ella. Trabajo desde mi casa en los Países Bajos, y debido a que Storybook es de código abierto, gran parte de mi trabajo está disponible públicamente. Por supuesto, puedes seguirme en Twitter para obtener actualizaciones ocasionales sobre desarrollo de UI y mejores prácticas.

Hoy estoy emocionado de mostrarte algo en lo que he estado trabajando durante los últimos meses. Pero primero, cubramos lo básico. En estos días, las interfaces de usuario se construyen utilizando componentes. Todos los frameworks modernos proporcionan una forma de hacer desarrollo basado en componentes. Incluso los frameworks de servidor como Ruby on Rails ahora proporcionan una forma de construir y usar componentes. Esto tiene sentido porque el desarrollo basado en componentes aporta muchos beneficios. Puedes trabajar de manera más eficiente porque no todos los elementos de la UI tienen que ser personalizados. Puedes acelerar el desarrollo al paralelizar el trabajo entre personas y equipos. Y las interfaces de usuario se vuelven más duraderas a medida que se dedica más atención a las API de los componentes trabajando en ellos de forma aislada.

A pesar de los esfuerzos de los autores de los frameworks para reducir la barrera de crear grandes interfaces de usuario, aún es difícil realizar pruebas correctamente. Realizar pruebas en una aplicación en ejecución puede ser lento e inestable, y reproducir un error es difícil. La lógica empresarial compleja significa que hay toneladas de escenarios y estados que considerar, los cuales no se pueden probar manualmente. Especialmente cuando tu UI está en constante desarrollo. Las herramientas de prueba existentes también dejan mucho que desear. Si lo piensas, es absurdo cómo el status quo es ejecutar pruebas unitarias con JS DOM, que es un entorno totalmente diferente al que se ejecutará tu interfaz de usuario. O que debas instalar un navegador separado para ejecutar y depurar tus pruebas de interacción.

En caso de que aún no estés familiarizado con Storybook, es una herramienta para construir componentes de UI. Proporciona un entorno aislado para tus componentes, para que puedas centrarte en cómo funcionan y se ven en todos sus estados y variantes. Funciona con todos los principales frameworks frontend. Storybook se construye principalmente para ejecutarse en tu máquina local, junto con el código de tu proyecto, mientras desarrollas o pruebas aplicaciones. Pero también puedes cargar una versión estática para compartirla con colegas o clientes. Storybook se puede ampliar con cientos de complementos, para integrarse con herramientas de diseño como Figma o conectar componentes a una fuente de datos, renderizar componentes como los vería una persona con daltonismo, o generar documentación de componentes. Es la única fuente de verdad para los componentes de UI. Cuando trabajas en Storybook, construirás componentes de forma aislada. Storybook proporciona un lienzo en el que renderizará tus componentes. En un flujo de trabajo típico, ejecutarás tu Storybook junto con tu editor de código.

2. Introducción a Storybook y Component Stories

Short description:

Storybook es una poderosa herramienta para catalogar y categorizar variantes de componentes. Es confiable para miles de equipos de desarrollo y se utiliza en empresas como Shopify, GitHub, IBM y la BBC. Las historias se definen utilizando el formato de historia de componentes (CSF), lo que permite una fácil reutilización y compatibilidad con otras herramientas. Ahora adentrémonos en algo de código con un archivo de historias simple para un componente de insignia.

Storybook se trata de catalogar variantes de componentes y categorizar componentes para formar una biblioteca de componentes organizada y fácilmente buscable. Esto ayudará a todos a encontrar los componentes que necesitan, facilitando la reutilización de lo que ya está disponible.

Storybook es un proyecto de código abierto impulsado por una gran comunidad de colaboradores. Es confiable para miles de equipos de desarrollo en todo el mundo. Se utiliza en empresas como Shopify, GitHub, IBM y la BBC. ¡Incluso está apareciendo cada vez más en los currículums de las personas!

La principal innovación de Storybook es el concepto de Historias. La mayoría de los componentes de la interfaz de usuario tienen más de una variación. Una Historia es un fragmento de código que representa un componente en una de esas variaciones. Piensa en cosas como estados de carga, estados de error y estados funcionales, como un interruptor. Pero también hay casos extremos, como valores extremos, contenido desbordado o datos faltantes. Y finalmente, hay variaciones dependientes del contexto, como si un usuario ha iniciado sesión o no, su idioma, si prefiere un tema oscuro o cuál es su variante asignada en una prueba A-B. Y para empeorar las cosas, también hay innumerables combinaciones posibles, ciertamente no es algo que quieras probar manualmente.

Las historias se definen utilizando el formato de historia de componentes, o CSF por sus siglas en inglés. Es una especificación abierta compatible no solo con Storybook, sino también con muchas otras herramientas. Esto significa que puedes escribir historias una vez y reutilizarlas en varios lugares. No hay dependencia de API, porque simplemente estás escribiendo JavaScript básico. Si quieres, puedes usar historias con Playwright o Cypress.

Ahora adentrémonos en algo de código. Esto es lo que se ve un archivo de historias simple para un componente de insignia. En la parte superior, importamos el componente y definimos un objeto de metadatos. Este es la exportación predeterminada. Este objeto se puede utilizar para definir cosas como el tipo de datos que necesita este componente, dónde se encuentra en la jerarquía de componentes, especificar argumentos predeterminados y envolver el componente con un proveedor de datos. En este caso, solo necesitamos decirle a Storybook qué componente estamos representando. También estamos especificando una etiqueta predeterminada. El componente de insignia tiene una variante pequeña y una grande, por lo que definimos dos historias, pequeña y grande, que solo difieren en su propiedad de tamaño. Para escribir una historia, realmente solo se necesita un objeto JavaScript básico. Ahora que sabes cómo definir historias, podemos agregar interacciones. A veces, un componente tiene variantes que no se pueden expresar solo pasando argumentos. Tal vez no puedas o no quieras cambiar la API del componente, o el componente está anidado dentro de otro componente, como una página.

3. Historias interactivas y codificación en vivo

Short description:

Storybook 6.4 introduce historias interactivas, lo que te permite crear historias para componentes y páginas complejas. Puedes simular el comportamiento del usuario utilizando la biblioteca de pruebas, y estas interacciones se ejecutan en el navegador. El complemento de Interacciones permite la depuración interactiva, y puedes utilizar las herramientas de desarrollo que conoces y amas sin instalar software adicional. Con el Ejecutor de Pruebas de Node.js, puedes ejecutar todo el Storybook como un conjunto de pruebas y recibir una URL para reproducir errores. Veamos cómo funciona esto en la práctica con algo de codificación en vivo.

De cualquier manera, pasar argumentos puede no ser una opción. Muchas personas han tenido dificultades con esto. Y es por eso que Storybook 6.4 introduce historias interactivas. En Storybook 6.4 puedes definir una función de reproducción en tus historias que se ejecuta inmediatamente después de que tu componente se renderiza. Esto te permite crear historias para componentes y páginas complejas. Por ejemplo, puedes simular el comportamiento del usuario utilizando la popular biblioteca de pruebas. Estas interacciones se ejecutan en el navegador, por lo que realmente puedes ver e inspeccionar el resultado.

Incluso hay un complemento de ESLint para ayudarte a escribir funciones de reproducción sin caer en errores comunes. Además de ejecutar historias interactivas, también estamos trabajando en la interacción de pruebas. En los próximos meses, lanzaremos herramientas para hacer afirmaciones en tus funciones de reproducción. El complemento de Interacciones te permitirá depurar tus pruebas de forma interactiva directamente en tu navegador. Lo genial de usar Testing Library con Storybook es que se ejecuta en tu navegador habitual, lo que significa que puedes utilizar las herramientas de desarrollo que conoces y amas, y no necesitarás instalar ningún software adicional. Utilizando el Ejecutor de Pruebas de Node.js, podrás ejecutar todo el Storybook como un conjunto de pruebas, y cuando algo falle, recibirás una URL con la que podrás reproducir el error.

Ahora veamos cómo funciona esto en la práctica con algo de codificación en vivo. Muy bien, he configurado un componente simple para un formulario de cuenta con un archivo de historias, y lo que quiero hacer ahora es escribir algunas historias para el estado del campo. Así que vamos a hacer eso. Exporta const field, y es solo un objeto simple. Tiene una función de reproducción en ella, que siempre es una función asíncrona. Entonces, lo que queremos hacer aquí es escribir algunas interacciones con el componente en ejecución en Storybook. Para hacer eso, primero necesitamos obtener el elemento del lienzo, para poder apuntar nuestros selectores a ese contenedor. Eso se pasa en el contexto de la historia que recibe la función de reproducción, elemento del lienzo. Y luego podemos usar una utilidad de la biblioteca de pruebas para obtener un selector específico. Importa within de storybook/testing-library. Y ahora const canvas equals within ese elemento del lienzo. Bien, guardemos nuestro archivo y veamos si obtenemos una nueva historia. Entonces, en Storybook, ha aparecido una nueva historia, pero aún no hace nada especial. Muy bien, no hemos hecho nada. Así que sigamos escribiendo algunas interacciones. Para hacer eso, necesitamos user event de la biblioteca de pruebas. Y decimos await user event.type, porque queremos escribir en este campo de entrada y, bueno, ahora necesitamos proporcionar un elemento. Entonces, ¿cómo obtenemos un nuevo elemento? Bueno, para hacer eso, necesitamos crear un nuevo cliente.

4. Interactuando con Elementos y Escribiendo Historias

Short description:

Para interactuar con elementos en Storybook, podemos usar las herramientas de desarrollo de nuestro navegador para inspeccionar y manipularlos. Al proporcionar valores y activar acciones, podemos simular interacciones de usuario y observar los cambios resultantes. Escribamos una historia para un estado específico del componente, donde nos encontramos con un error debido a una entrada no válida. Esto nos ayudará a probar y mostrar este escenario.

Bien, ahora necesitamos proporcionar un elemento. Entonces, ¿cómo obtenemos ese cuadro de entrada? Lo genial es que puedes usar las herramientas de desarrollo regulares de tu navegador aquí para inspeccionar el elemento. Y podemos ver que este campo de entrada tiene un ID de prueba data, que puedo copiar y pegar. Dame eso. Y luego digamos canvas get by test ID, no obtener todos, solo obtener ese, mi ID de prueba, correo electrónico, y por supuesto, proporcionar un valor. Hola. Guardar mi archivo. Y boom, Storybook ha vuelto a renderizar instantáneamente mi componente, ha completado el formulario y también ha listado eso en el panel de interacciones.

Hagamos lo mismo para la contraseña. Contraseña, hola mundo, por supuesto. Guardar mi archivo. Boom. Tenemos dos interacciones aquí. En realidad, podemos pasar el cursor sobre estas cosas, hacer clic en ellas, para ver qué está sucediendo en ese paso en particular. Puedes retroceder y avanzar entre las interacciones. Entonces, veamos qué sucede cuando hago clic en ese botón de crear cuenta. Boom, hay un error, por supuesto. No he completado una dirección de correo electrónico válida y la contraseña no es lo suficientemente larga.

Entonces, escribamos una historia para este estado particular de mi componente. Porque este es un estado totalmente válido que las personas pueden encontrar y queremos escribir una historia para ello. Entonces, export const invalid. Esta es una nueva historia. Voy a tomar una función Play. Y nuevamente, una función Async. Y en lugar de repetirme aquí, simplemente voy a usar la función Play de la historia anterior. Entonces, necesito esperar eso. Build.Play. Y la función Play necesita un contexto de historia. Así que pasaré ese contexto. Guardar mi archivo y debería tener una nueva historia.

5. Escribiendo Pruebas para Elementos Interactivos

Short description:

Haz clic en el botón para activar el estado envuelto. Especifica el botón deseado cuando haya varios botones presentes. Amplía la historia para mostrar el tooltip al pasar el cursor. Escribir pruebas para elementos interactivos puede ser desafiante.

Haz clic en él. Boom. Lo mismo. ¿Verdad? La misma historia.

Ahora, vamos a ampliarla. Nuevamente, necesito un lienzo. CanvasElement. Y ahora puedo hacer await. UserEvent.click. Porque quiero hacer clic en ese botón para activar el estado envuelto. Lienzo. Nuevamente, por rol. Rol. Botón. Guardar mi archivo, ver qué sucede. Boom, ocurrió un error. Bueno, encontró varios botones en la página porque, por supuesto, también hay un botón de reinicio aquí. Entonces, necesitamos especificar exactamente cuál queremos. Guardar. Y boom, funciona. Ahora tenemos una historia para este estado envuelto.

Echemos un vistazo más de cerca aquí. Hay este mensaje de error y tiene este tooltip. Ampliemos, ampliemos esta historia en particular para mostrar también el tooltip al pasar el cursor. Podemos hacerlo totalmente usando userEvent. userEvent.hover Y ahora, nuevamente, no sé qué componente, qué historia, qué elemento necesito. Entonces, inspectElement y hay un ID de prueba en él. Cópialo y haz canvas.getByTestID Pásalo, guarda mi archivo y ocurrió un error. Bueno, ¿qué está pasando aquí? Entonces, este es un problema particular al escribir pruebas para elementos interactivos.

6. Escribiendo Historias y Verificándolas con Jest

Short description:

Especialmente si tienen un proceso asíncrono allí. En este caso, validación de formulario asíncrona. FindByTestID es un selector asíncrono proporcionado por Testing Library. Ahora vamos a escribir una historia para el estado enviado y verificarlo usando expect de Jest. La función play te permite ejecutar interacciones y hacer afirmaciones sobre tu componente. Utiliza los envoltorios de Storybook para jest y Testing Library para usar el complemento de interacciones.

Especialmente si tienen un proceso asíncrono allí. En este caso, validación de formulario asíncrona. Entonces, después de hacer clic en el botón, tarda muy poco tiempo en aparecer ese mensaje de error. Entonces, necesito usar una consulta diferente aquí. Y, afortunadamente, Testing Library proporciona un selector diferente para hacer eso. FindByTestID, que es algo asíncrono, así que necesitamos esperarlo. Guarda el archivo y ¡ahora funciona! Entonces, verás que la historia se actualiza y realmente ha abierto ese tooltip, lo que significa que el hover funcionó.

Bien, ahora vamos a escribir una historia para el estado enviado. Entonces, lo que voy a hacer es Exportar Consubmitted, Nueva Historia, y voy a copiar la función play de la primera, y corregir mis errores. Genial, ahora también voy a enviar, hacer clic en el botón, guardarlo, tengo una nueva historia. Y boom, tan pronto como lo abro, se envía el formulario y está hecho. Lo que realmente queremos hacer ahora es verificar que funcionó, que no solo termina en el clic del botón, verificar que funcionó usando una prueba. Y para hacer eso vamos a usar expect de Jest. Así que voy a importarlo, importar expect de storybook.jest. Nuevamente, necesitamos el envoltorio de storybook para Jest aquí porque es una versión instrumentada que funcionará con el complemento de interacciones. Entonces, lo que podemos afirmar aquí es el hecho de que se desencadenó una acción porque lo que sucede cuando se hace clic en el botón, se invoca este controlador de desenvío. Y eso es algo en lo que podemos afirmar usando expect. Entonces, esperar, expect, y luego podemos afirmar sobre los args. Y los args se pasan a lo largo de la función play. Así que voy a decir que se haya llamado a args.unsubmit. Guardar mi archivo. Veamos qué sucede. No se ha llamado. Nuevamente, esto se debe a que hay alguna validación asíncrona en su lugar, así que antes de que se llame al controlador de desenvío, lleva un poco de tiempo. En este caso, podemos solucionarlo usando la utilidad waitfor en la testing library. Waitfor, que toma una función, una función de devolución de llamada en realidad. Y ahora guardo mi archivo, y ahora funciona.

Bien, repasemos lo que hemos visto. La función play es solo una propiedad en tu storybook, y te permite ejecutar interacciones y hacer afirmaciones sobre tu componente. Para usar el complemento de interacciones, tendrás que usar los envoltorios de storybook para jest y testing library.

7. Intercepción y Integración de CI en Tiempo de Ejecución

Short description:

Este código se basa en la biblioteca de pruebas y jest, brindando más potencia y una mejor experiencia de usuario. La intercepción y la intercepción en tiempo de ejecución se utilizan para rastrear las invocaciones de métodos y mostrar un registro de interacciones. La función play en Storybook permite la depuración interactiva y la integración con CI se logra a través de un ejecutor de pruebas Node.js. Storybook está creciendo rápidamente y se utiliza ampliamente, y recién estamos comenzando. Sígueme en Twitter para obtener actualizaciones y únete a la sesión de preguntas y respuestas para cualquier pregunta.

Este código realmente no se desvía mucho de la forma en que ya puedes estar usando la biblioteca de pruebas o una herramienta similar. Lo hemos diseñado para apoyarnos en los gigantes mientras brindamos más potencia y una mejor experiencia de usuario.

A estas alturas, es posible que te preguntes cómo lo logramos. Puede parecer mágico, pero en realidad estamos utilizando la intercepción y la intercepción en tiempo de ejecución. Dado que nos basamos en la biblioteca de pruebas y jest, estas bibliotecas están instrumentadas para funcionar con el complemento de interacciones. En tiempo de ejecución, se rastrean las invocaciones de métodos y se envían al panel del complemento para mostrar un registro de interacciones. Luego, cuando estás retrocediendo y avanzando con el depurador, en lugar de invocar el método de la biblioteca, devuelve una promesa que no se resolverá hasta que presiones Siguiente. Finalmente, para salir prematuramente de la función play, lanzamos excepciones que son ignoradas silenciosamente por Storybook. Puede sonar como algo malo, pero es el truco para que todo funcione.

Entonces, ¿cómo se integra esto con CI? Para eso, lanzaremos un ejecutor de pruebas Node.js que ejecuta todas las funciones play en tu Storybook utilizando un navegador sin cabeza. Y cuando algo falla, puedes revisar los errores en tu navegador habitual o enviar un informe a otras herramientas. De alguna manera, las historias siempre han sido como pruebas en Storybook. Con el complemento de Interacciones, solo lo llevamos al siguiente nivel y recién estamos comenzando. Gracias por escuchar, y por favor sígueme en Twitter si deseas recibir actualizaciones al respecto. Si tienes alguna pregunta, por favor encuéntrame en mi sesión de preguntas y respuestas. Muchas gracias por eso, Goert. Es una charla que definitivamente tendré que volver a ver porque no tuve la oportunidad de asimilarla lo suficiente como me gustaría. Y Storybook es algo que sigue llegando a mí por todas partes y no tengo la oportunidad de mirarlo lo suficiente.

Goert, te doy la bienvenida al escenario y veamos los resultados de tu encuesta. Pregunta fascinante. Prueba de extremo a extremo, 64%. ¿Qué opinas al respecto? En primer lugar, gracias por tenerme aquí. Estoy muy emocionado de hacer esto. Para ser honesto, no me sorprenden mucho los resultados de la encuesta porque, seamos honestos, TestJS Summit es, por supuesto, una audiencia bastante particular. Así que sospecho que muchas de estas personas están usando Cypress para sus pruebas porque, francamente, ese es el gran jugador, ¿verdad? Es muy popular y lo entiendo completamente. Así que no es sorprendente que obviamente hayamos tomado mucha inspiración de lo que han estado haciendo. Y, por supuesto, tenemos mucho respeto por lo que han hecho. Y estamos tratando de llevar parte de eso al universo de Storybook. Y, por supuesto, el universo de Storybook, como mencionaste, está creciendo muy rápido y es muy popular. Utilizado por miles de empresas en todo el mundo y todos están muy contentos al respecto.

8. Pruebas de Interfaz de Usuario y el Rol de la Automatización

Short description:

Estamos tratando de ofrecer una forma nueva y adicional de probar la interfaz de usuario, cerrando la brecha entre las pruebas de extremo a extremo y las pruebas unitarias. Nuestro objetivo es eliminar las pruebas manuales y proporcionar opciones de pruebas automatizadas. Si bien ciertas cosas solo se pueden probar manualmente, herramientas como Selenium y Cypress pueden ayudar con las pruebas funcionales. Sin embargo, para los aspectos visuales, la regresión visual y las pruebas manuales son necesarias.

Entonces, estamos tratando de agregar algo a esta mezcla aquí. Por eso quería hacer esta pregunta de encuesta, ¿cuál es la forma de probar la interfaz de usuario? ¿Cómo lo hacen las personas en este momento? La razón por la que estoy interesado en eso es porque, por supuesto, estamos tratando de ofrecer una forma nueva y adicional de hacerlo. Que está en el límite entre las pruebas de extremo a extremo y las pruebas unitarias. Y, por supuesto, también nos encantaría eliminar esa prueba manual para muchas personas. Porque también imagino que muchas personas están a punto de comenzar a hacer pruebas automatizadas. Pero todavía están atrapados con las pruebas manuales. Porque ciertas cosas son difíciles de probar o es una gran inversión, y cosas así. Creo que ciertas cosas solo se pueden probar de forma humana o manual. Pero lo fascinante que encontré aquí es que no fuiste muy específico con tu pregunta, ¿verdad? Así que todas las respuestas son correctas. Pero hay diferentes tipos de riesgos. Entonces, funcionalmente, Selenium y Cypress pueden ayudarte. Pero obviamente no es lo que ve el ser humano. Por lo tanto, la regresión visual y las pruebas manuales serán de ayuda. Así que pensé que era una gran pregunta. Una gran encuesta y resultados impresionantes.

QnA

Q&A: Soporte del navegador y pruebas de componentes

Short description:

Tenemos una pregunta sobre el soporte del navegador para las historias interactivas y las pruebas de interacción de Storybook. Aunque Storybook aún admite oficialmente Internet Explorer, se está alejando de él y se centra en admitir todos los demás navegadores principales. Aunque Internet Explorer todavía existe y tiene valor para ciertas personas, está perdiendo relevancia. Otra pregunta pregunta si hay complementos en Storybook para probar componentes cuando se combinan, como probar una página completa o un diseño de Figma.

Pero vamos a tener algunas preguntas del público para ti. Porque siempre pone al orador en apuros. Aquí es donde descubrimos qué sabe Gert. Tenemos una pregunta de Refactor Eric. ¿Qué navegadores son compatibles con las historias interactivas y las pruebas de interacción de Storybook? Excelente pregunta. Creo que prácticamente todos ellos siempre que ejecuten Storybook. Lo cual puede o no incluir Internet Explorer. No lo he probado, para ser honesto. Sospecho que no funcionará realmente. Storybook aún admite oficialmente Internet Explorer en la configuración particular. Pero nos estamos alejando de eso, por supuesto. Pero, por supuesto, estamos admitiendo prácticamente todos los demás navegadores actuales. Y eso se mantendrá. Porque simplemente se ejecuta en tu navegador y tenemos la intención de admitir a todos los principales proveedores.

Perfecto. ¿Tienes estadísticas? ¿Alguien todavía usa Internet Explorer para sus sitios web? Nosotros no, pero sabemos que otras personas sí lo hacen. Trabajo para Chromatic y ofrecemos Internet Explorer como una de las opciones de navegador para que nuestros clientes lo usen en las pruebas. Y todavía muchos clientes lo hacen. Así que todavía hay valor allí. Esa es la palabra correcta. Esa es la palabra correcta, para ciertas personas todavía hay valor en IE. Todavía está ahí. Todavía existe. Pero esperemos que esté en el – Sí. Tal vez deberíamos dejar de hablar de eso. ¿Verdad? Me siento mal incluso por mencionarlo, ¿verdad? Claro.

Otra pregunta de Jane Monroe. Storybook es genial para componentes individuales. ¿Y hay algún complemento para probar los componentes cuando se combinan? Básicamente, intentar probar como una página completa. Algo como un diseño completo de Figma.

Construcción de componentes y pruebas en Storybook

Short description:

Storybook no solo es conocido por construir componentes de IU personalizados, sino también por el desarrollo de aplicaciones. Chromatic se basa en pruebas de regresión visual para el 90% de las pruebas de front-end. Mock Service Worker es un complemento que te permite interceptar las solicitudes HTTP y devolver datos simulados. Storybook es una combinación de pruebas unitarias y pruebas de extremo a extremo, lo que permite pruebas de interacción para flujos de IU.

Claro que sí. Sí. Entonces hay una gran cantidad de complementos en el ecosistema. Y una cosa en la que nos estamos enfocando mucho en este momento es hacer que sea más fácil y mejor construir componentes, o en realidad, historias, que compongan páginas completas, pantallas o asistentes. En realidad, aplicaciones completas.

Storybook es principalmente conocido por construir componentes de IU personalizados que encontrarías en, por ejemplo, una biblioteca de componentes o un sistema de diseño. Eso es por lo que es conocido. Pero el verdadero valor radica también en cuando comienzas a usarlo para el desarrollo de aplicaciones, donde construyes toda tu aplicación web en Storybook. De hecho, Chromatic en sí es una aplicación web muy complicada, un sistema muy complejo. Está completamente construido en Storybook.

Y volviendo a nuestra pregunta de la encuesta, en Chromatic confiamos en las pruebas de regresión visual para el 90% de nuestras pruebas, al menos para el front-end del sistema. Para el back-end, tenemos pruebas unitarias, etc. Pero el front-end es principalmente pruebas de regresión visual, y eso cubre prácticamente todo lo que necesitamos. Por supuesto, también tenemos algunas pruebas de extremo a extremo, solo para verificar, como una prueba de humo, para asegurarnos de que la cosa no esté caída, ¿verdad? Que funcione en absoluto. Pero el 90% son pruebas de regresión visual en nuestra situación, por supuesto, como prueba de uso propio, por supuesto. Bueno, como dije acerca de las pruebas de humo, solo asegurándonos de que todos los puntos estén conectados. Entonces, ya sabes, individualmente estás probando los puntos, ahora estás interesado en todo el flujo. Para dar una respuesta concreta a la pregunta, ¿qué complementos? Mock Service Worker es el que me viene a la mente, porque te permite simular solicitudes HTTP. Entonces, si construyes una página completa, esa página sin duda va a hacer algunas solicitudes HTTP para obtener algunos datos para alimentarla, ¿verdad? Entonces, Mock Service Worker te permite interceptar esa solicitud. No tienes que cambiar el código de tu aplicación para que esto suceda, porque vive en tu navegador e intercepta las solicitudes HTTP reales que tu aplicación está haciendo y devuelves datos simulados para que siempre sean estables, súper rápidos, sin errores, y así es como construirías una historia para una página compleja en Storybook. Fantástico, entonces Refactor Eric tenía una pregunta al respecto. Esperemos que nos hagas saber si eso responde a tu pregunta. No lo preguntaré, porque creo que sí. Julia Bond tiene una pregunta. ¿Qué pruebas debería reemplazar? Ellos creen que solo las pruebas unitarias. ¿Qué piensas, Gert? Bueno, yo diría que dependiendo de la forma en que hagas tus pruebas unitarias, tal vez. Pero diría que es una combinación. Está realmente en el límite entre tus pruebas unitarias y tus pruebas de extremo a extremo. Entonces, muchas cosas que tal vez escribirías una prueba de Cypress para probar cierto flujo en tu IU, puedes escribir pruebas de interacción en Storybook para eso.

Pruebas unitarias de componentes de IU en Storybook

Short description:

Se pueden escribir pruebas unitarias en Jest con Testing Library para probar componentes de IU específicos, incluido el estado interno. En Storybook, puedes escribir una historia para el componente de IU y agregar afirmaciones utilizando la función play. Esto elimina la necesidad de un archivo de prueba separado y proporciona los mismos beneficios a un costo menor.

Y pruebas unitarias, por supuesto, también. Muchas personas escriben sus pruebas unitarias en Jest con Testing Library, por ejemplo, para probar un componente de IU específico, como el estado interno de un componente de IU. Eso es algo que podrías o harías en Storybook. A medida que desarrollas el componente de IU, escribes una historia para él, espero que ya lo estuvieras haciendo. Lo único que haces ahora es agregar esta función play para agregar algunas afirmaciones, las afirmaciones que de otra manera irían en un archivo de prueba separado. Ahora ya no necesitas escribir ese archivo de prueba. Las colocas directamente en tu archivo de historia y obtienes muchos de esos beneficios, los mismos beneficios realmente, a un costo menor incluso ahora. Fantástico. Pregunta de nosotros mismos, ¿puedo usar interacciones de Storybook con algo que no sea Testing Library? Sí. Entonces, la cuestión es que nos estamos enfocando por ahora en Testing Library porque preguntamos en la comunidad y trabajamos con grandes empresas, y les preguntamos qué herramientas usan Y Testing Library realmente es el jugador dominante en las pruebas unitarias de tus componentes de IU pero también permiten escribir pruebas de interacción en una prueba unitaria. Por lo tanto, fue muy natural elegirlos como el objetivo principal para la integración. Sin embargo, lo hemos configurado de manera genérica para que cualquier biblioteca que pueda ser útil aquí pueda ser instrumentada, como lo llamamos, para trabajar con Storybook, con el complemento de interacciones. Entonces, como ejemplo, mientras estaba prototipando estas cosas, construí una integración para CHI, que es un tipo diferente de biblioteca de afirmaciones, solo por diversión para ver si funciona, ¿verdad? Y hay otro sistema de algunas personas de una empresa llamada Frontside que están construyendo una biblioteca llamada Interactors. Y de hecho, estamos trabajando con ellos para crear también una integración con esa biblioteca. Entonces, comenzamos con Testing Library y Jest Expect, o simplemente Jest, porque son los jugadores dominantes en este momento. Pero este es un ecosistema que solo va a crecer, y por supuesto, hemos diseñado este sistema de tal manera que es fácil de integrar con otras bibliotecas también, sí. Entonces, para resumir. Como mencionaste, va a crecer y mencioné al principio que sigo escuchando historias por todas partes. ¿Cómo se ve ese crecimiento? ¿Cómo crees que va a ser ese crecimiento? ¿Qué tan grande crees que va a ser? ¿Y qué tipo de crecimiento estás viendo? La cuestión es que todavía hay un gran campo por explorar, por así decirlo. Como mencioné, los sistemas de diseño son lo más importante en este momento, pero los desarrolladores de aplicaciones aún son un gran campo en el que apenas hemos incursionado. Entonces, ahí es donde se producirá el crecimiento principal y en eso nos estamos enfocando en este momento. Fantástico. Bueno, creo que nos has brindado mucha información, y espero que la audiencia de desarrolladores y probadores de aquí esté interesada en ver qué está por venir y qué está atrayendo. Si queremos estar al tanto de tus novedades, ¿estás en alguna red social? ¿Podemos seguirte y recibir actualizaciones al respecto? Sí, por supuesto. En mi charla lo mencioné, Scheehengeveld es mi nombre de usuario en Twitter. Es la primera letra de mi nombre y mi apellido. Encuéntrame y sígueme. Excelente, muchas gracias por tomarte el tiempo de venir a hablar con nosotros y compartir tus ideas, y espero verte de nuevo pronto. Gracias. Gracias.

Check out more articles and videos

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

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.
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 2021TestJS Summit 2021
31 min
Test Effective Development
Top Content
Developers want to sleep tight knowing they didn't break production. Companies want to be efficient in order to meet their customer needs faster and to gain competitive advantage sooner. We ALL want to be cost effective... or shall I say... TEST EFFECTIVE!But how do we do that?Are the "unit" and "integration" terminology serves us right?Or is it time for a change? When should we use either strategy to maximize our "test effectiveness"?In this talk I'll show you a brand new way to think about cost effective testing with new strategies and new testing terms!It’s time to go DEEPER!
TestJS Summit 2023TestJS Summit 2023
21 min
Everyone Can Easily Write Tests
Let’s take a look at how Playwright can help you get your end to end tests written with tools like Codegen that generate tests on user interaction. Let’s explore UI mode for a better developer experience and then go over some tips to make sure you don’t have flakey tests. Then let’s talk about how to get your tests up and running on CI, debugging on CI and scaling using shards.

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.
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.
TestJS Summit 2023TestJS Summit 2023
148 min
Best Practices for Writing and Debugging Cypress Tests
Workshop
You probably know the story. You’ve created a couple of tests, and since you are using Cypress, you’ve done this pretty quickly. Seems like nothing is stopping you, but then – failed test. It wasn’t the app, wasn’t an error, the test was… flaky? Well yes. Test design is important no matter what tool you will use, Cypress included. The good news is that Cypress has a couple of tools behind its belt that can help you out. Join me on my workshop, where I’ll guide you away from the valley of anti-patterns into the fields of evergreen, stable tests. We’ll talk about common mistakes when writing your test as well as debug and unveil underlying problems. All with the goal of avoiding flakiness, and designing stable test.