Prueba tu interfaz de usuario en el navegador REAL

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

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.

This talk has been presented at TestJS Summit 2021, check out the latest edition of this JavaScript Conference.

FAQ

Chromatic es una plataforma fundada por los mantenedores de Storybook, diseñada para realizar pruebas de regresión visual y su revisión. Funciona integradamente con Storybook, una herramienta para construir y organizar componentes de UI.

Puedes seguir las actualizaciones sobre desarrollo de UI y mejores prácticas siguiendo en Twitter a los desarrolladores y mantenedores de plataformas como Storybook y Chromatic, quienes comparten regularmente consejos y novedades en esta área.

El desarrollo basado en componentes permite trabajar de manera más eficiente al no tener que personalizar todos los elementos de la UI, acelera el desarrollo al permitir paralelizar el trabajo y hace que las interfaces de usuario sean más duraderas al centrarse en las API de los componentes.

Realizar pruebas en interfaces de usuario puede ser complicado debido a la complejidad de la lógica empresarial, la cantidad de escenarios y estados posibles, y la dificultad para reproducir errores en un entorno diferente al que se ejecuta la interfaz de usuario.

Una 'Historia' en Storybook es un fragmento de código que representa un componente en una de sus variaciones, como estados de carga, error, o funcionales. Las historias ayudan a visualizar y probar cómo funcionan los componentes en diferentes contextos y estados.

Storybook se puede ampliar con cientos de complementos que permiten integrarse con herramientas de diseño como Figma, conectar componentes a fuentes de datos, renderizar componentes como los vería una persona con daltonismo, o generar documentación de componentes.

Las historias interactivas y pruebas de interacción de Storybook son compatibles con la mayoría de los navegadores modernos, aunque el soporte para Internet Explorer puede ser limitado o inexistente debido a su desuso y limitaciones tecnológicas.

Sí, existen varios complementos en Storybook que permiten probar componentes de UI combinados, como Mock Service Worker, que ayuda a simular solicitudes HTTP para construir historias que representen páginas completas o aplicaciones.

Gert Hengeveld
Gert Hengeveld
33 min
19 Nov, 2021

Comments

Sign in or register to post your comment.
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: Test your UI in the REAL Browser

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.

Read also

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

Solicitudes de Red con Cypress
TestJS Summit 2021TestJS Summit 2021
33 min
Solicitudes de Red con Cypress
Top Content
Cecilia Martinez, a technical account manager at Cypress, discusses network requests in Cypress and demonstrates commands like cydot request and SCI.INTERCEPT. She also explains dynamic matching and aliasing, network stubbing, and the pros and cons of using real server responses versus stubbing. The talk covers logging request responses, testing front-end and backend API, handling list length and DOM traversal, lazy loading, and provides resources for beginners to learn Cypress.
Pruebas de ciclo completo con Cypress
TestJS Summit 2022TestJS Summit 2022
27 min
Pruebas de ciclo completo con Cypress
Top Content
Cypress is a powerful tool for end-to-end testing and API testing. It provides instant feedback on test errors and allows tests to be run inside the browser. Cypress enables testing at both the application and network layers, making it easier to reach different edge cases. With features like AppActions and component testing, Cypress allows for comprehensive testing of individual components and the entire application. Join the workshops to learn more about full circle testing with Cypress.
Desarrollo Efectivo de Pruebas
TestJS Summit 2021TestJS Summit 2021
31 min
Desarrollo Efectivo de Pruebas
Top Content
This Talk introduces Test Effective Development, a new approach to testing that aims to make companies more cost-effective. The speaker shares their personal journey of improving code quality and reducing bugs through smarter testing strategies. They discuss the importance of finding a balance between testing confidence and efficiency and introduce the concepts of isolated and integrated testing. The speaker also suggests different testing strategies based on the size of the application and emphasizes the need to choose cost-effective testing approaches based on the specific project requirements.
Playwright Test Runner
TestJS Summit 2021TestJS Summit 2021
25 min
Playwright Test Runner
Top Content
The Playwright Test Runner is a cross-browser web testing framework that allows you to write tests using just a few lines of code. It supports features like parallel test execution, device emulation, and different reporters for customized output. Code-Gen is a new feature that generates code to interact with web pages. Playwright Tracing provides a powerful tool for debugging and analyzing test actions, with the ability to explore trace files using TraceViewer. Overall, Playwright Test offers installation, test authoring, debugging, and post-mortem debugging capabilities.
Todos pueden escribir pruebas fácilmente
TestJS Summit 2023TestJS Summit 2023
21 min
Todos pueden escribir pruebas fácilmente
Playwright is a reliable end-to-end testing tool for modern web apps that provides one API, full isolation, fast execution, and supports multiple languages. It offers features like auto-weighting, retrying assertions, seamless testing of iframes and shadow DOM, test isolation, parallelism, and scalability. Playwright provides tools like VS Code extension, UiMode, and Trace Viewer for writing, debugging, and running tests. Effective tests prioritize user-facing attributes, use playwright locators and assertions, and avoid testing third-party dependencies. Playwright simplifies testing by generating tests, providing code generation and UI mode, and allows for easy running and debugging of tests. It helps in fixing failed tests and analyzing DOM changes, fixing locator mismatches, and scaling tests. Playwright is open source, free, and continuously growing.

Workshops on related topic

Diseñando Pruebas Efectivas con la Biblioteca de Pruebas de React
React Summit 2023React Summit 2023
151 min
Diseñando Pruebas Efectivas con la Biblioteca de Pruebas de React
Top Content
Featured Workshop
Josh Justice
Josh Justice
La Biblioteca de Pruebas de React es un gran marco para las pruebas de componentes de React porque responde muchas preguntas por ti, por lo que no necesitas preocuparte por esas preguntas. Pero eso no significa que las pruebas sean fáciles. Todavía hay muchas preguntas que tienes que resolver por ti mismo: ¿Cuántas pruebas de componentes debes escribir vs pruebas de extremo a extremo o pruebas de unidad de nivel inferior? ¿Cómo puedes probar una cierta línea de código que es difícil de probar? ¿Y qué se supone que debes hacer con esa persistente advertencia de act()?
En esta masterclass de tres horas, presentaremos la Biblioteca de Pruebas de React junto con un modelo mental de cómo pensar en el diseño de tus pruebas de componentes. Este modelo mental te ayudará a ver cómo probar cada bit de lógica, si debes o no simular dependencias, y ayudará a mejorar el diseño de tus componentes. Te irás con las herramientas, técnicas y principios que necesitas para implementar pruebas de componentes de bajo costo y alto valor.
Tabla de contenidos- Los diferentes tipos de pruebas de aplicaciones de React, y dónde encajan las pruebas de componentes- Un modelo mental para pensar en las entradas y salidas de los componentes que pruebas- Opciones para seleccionar elementos DOM para verificar e interactuar con ellos- El valor de los mocks y por qué no deben evitarse- Los desafíos con la asincronía en las pruebas de RTL y cómo manejarlos
Requisitos previos- Familiaridad con la construcción de aplicaciones con React- Experiencia básica escribiendo pruebas automatizadas con Jest u otro marco de pruebas unitarias- No necesitas ninguna experiencia con la Biblioteca de Pruebas de React- Configuración de la máquina: Node LTS, Yarn
Detox 101: Cómo escribir pruebas de extremo a extremo estables para su aplicación React Native
React Summit 2022React Summit 2022
117 min
Detox 101: Cómo escribir pruebas de extremo a extremo estables para su aplicación React Native
Top Content
Workshop
Yevheniia Hlovatska
Yevheniia Hlovatska
A diferencia de las pruebas unitarias, las pruebas de extremo a extremo buscan interactuar con su aplicación tal como lo haría un usuario real. Y como todos sabemos, puede ser bastante desafiante. Especialmente cuando hablamos de aplicaciones móviles.
Las pruebas dependen de muchas condiciones y se consideran lentas e inestables. Por otro lado, las pruebas de extremo a extremo pueden dar la mayor confianza de que su aplicación está funcionando. Y si se hace correctamente, puede convertirse en una herramienta increíble para aumentar la velocidad del desarrollador.
Detox es un marco de pruebas de extremo a extremo en caja gris para aplicaciones móviles. Desarrollado por Wix para resolver el problema de la lentitud e inestabilidad y utilizado por React Native en sí como su herramienta de pruebas E2E.
Únete a mí en esta masterclass para aprender cómo hacer que tus pruebas de extremo a extremo móviles con Detox sean excelentes.
Prerrequisitos- iOS/Android: MacOS Catalina o más reciente- Solo Android: Linux- Instalar antes de la masterclass
Masterclass de Pruebas de API con Postman
TestJS Summit 2023TestJS Summit 2023
48 min
Masterclass de Pruebas de API con Postman
Top Content
WorkshopFree
Pooja Mistry
Pooja Mistry
En el panorama siempre en evolución del desarrollo de software, garantizar la fiabilidad y funcionalidad de las API se ha vuelto primordial. "Pruebas de API con Postman" es una masterclass completa diseñada para equipar a los participantes con los conocimientos y habilidades necesarios para sobresalir en las pruebas de API utilizando Postman, una herramienta poderosa ampliamente adoptada por profesionales en el campo. Esta masterclass profundiza en los fundamentos de las pruebas de API, avanza a técnicas de prueba avanzadas y explora la automatización, las pruebas de rendimiento y el soporte multiprotocolo, proporcionando a los asistentes una comprensión holística de las pruebas de API con Postman.
Únete a nosotros para esta masterclass para desbloquear todo el potencial de Postman para las pruebas de API, agilizar tus procesos de prueba y mejorar la calidad y fiabilidad de tu software. Ya seas un principiante o un probador experimentado, esta masterclass te equipará con las habilidades necesarias para sobresalir en las pruebas de API con Postman.
Monitoreo 101 para Desarrolladores de React
React Summit US 2023React Summit US 2023
107 min
Monitoreo 101 para Desarrolladores de React
Top Content
WorkshopFree
Lazar Nikolov
Sarah Guthals
2 authors
Si encontrar errores en tu proyecto frontend es como buscar una aguja en un pajar de código, entonces el monitoreo de errores de Sentry puede ser tu detector de metales. Aprende los conceptos básicos del monitoreo de errores con Sentry. Ya sea que estés ejecutando un proyecto de React, Angular, Vue, o simplemente JavaScript “vainilla”, mira cómo Sentry puede ayudarte a encontrar el quién, qué, cuándo y dónde detrás de los errores en tu proyecto frontend.
Nivel de la masterclass: Intermedio
Testing Web Applications Using Cypress
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
Top Content
Workshop
Gleb Bahmutov
Gleb Bahmutov
Esta masterclass te enseñará los conceptos básicos para escribir pruebas end-to-end útiles utilizando Cypress Test Runner.
Cubriremos la escritura de pruebas, cubriendo cada característica de la aplicación, estructurando pruebas, interceptando solicitudes de red y configurando los datos del backend.
Cualquiera que conozca el lenguaje de programación JavaScript y tenga NPM instalado podrá seguir adelante.
Mejores Prácticas para Escribir y Depurar Pruebas de Cypress
TestJS Summit 2023TestJS Summit 2023
148 min
Mejores Prácticas para Escribir y Depurar Pruebas de Cypress
Top Content
Workshop
Filip Hric
Filip Hric
Probablemente conozcas la historia. Has creado un par de pruebas y, como estás utilizando Cypress, lo has hecho bastante rápido. Parece que nada te detiene, pero luego - prueba fallida. No fue la aplicación, no fue un error, la prueba fue... ¿inestable? Bueno sí. El diseño de la prueba es importante sin importar la herramienta que utilices, incluyendo Cypress. La buena noticia es que Cypress tiene un par de herramientas bajo su cinturón que pueden ayudarte. Únete a mí en mi masterclass, donde te guiaré lejos del valle de los anti-patrones hacia los campos de pruebas estables y siempre verdes. Hablaremos sobre los errores comunes al escribir tu prueba, así como depurar y revelar problemas subyacentes. Todo con el objetivo de evitar la inestabilidad y diseñar pruebas estables.