Veo lo que está sucediendo: Pruebas visuales para tus componentes

Rate this content
Bookmark

Muchos marcos de trabajo web modernos utilizan componentes como sus bloques de construcción.


En esta charla, mostraré las pruebas de componentes utilizando Cypress, y cuando digo "mostrar", lo digo literalmente. Verás el componente ejecutándose dentro de un navegador real, interactuarás con el componente como un usuario real y podrás depurar el componente utilizando las herramientas de desarrollo del navegador real. Por último, repasaré las opciones actuales de código abierto y comerciales para probar visualmente los estilos y la representación del componente.

35 min
18 Jun, 2021

Video Summary and Transcription

Gleb Akhmetov explica cómo probar visualmente los componentes de React, enfatizando la importancia de abordar el cambio climático y la colaboración. Discute las pruebas de componentes, el estilo y los desafíos de los cambios de CSS. Gleb destaca el uso de capturas de imagen para las pruebas visuales y la importancia de controlar los datos para obtener resultados precisos. También habla sobre el uso de Docker para pruebas visuales consistentes y el soporte para múltiples navegadores. Cypress se enfoca en pruebas sin fallos y tiene planes de reintento de pruebas y nuevas características en la hoja de ruta.

Available in English

1. Introducción a las pruebas visuales de componentes de React

Short description:

En esta parte, Gleb Akhmetov, VP de Ingeniería en Cypress Atayo, explica cómo probar visualmente los componentes de React. Enfatiza la importancia de tomar medidas para abordar el cambio climático y fomenta la colaboración. Gleb luego presenta una aplicación de React, específicamente una aplicación de Sudoku, y discute su estructura y componentes.

Hola a todos. Gracias por invitarme. Soy Gleb Akhmetov, VP de Ingeniería en Cypress Atayo, y les voy a contar cómo probar visualmente sus componentes de React. El título de mi charla es, Veo lo que está sucediendo. Y a lo largo de mi presentación, verán lo que está sucediendo.

Antes de comenzar, solo una diapositiva rápida. Nuestro planeta todavía está en peligro inminente a pesar del COVID. Entonces, si no cambiamos nuestra política climática, vamos a extinguirnos. Así que el momento de actuar es realmente ayer. Pueden cambiar sus vidas, pero también deberían unirse a una organización porque no podemos hacerlo solos. Tenemos que trabajar juntos.

Bien, tomemos una aplicación de React. En este caso, es un Sudoku. Realmente me gusta esta aplicación porque se ve bien, se juega bien y tiene un estilo muy bueno. Incluso tiene estilos responsivos para que puedan ver cómo cambia de escritorio a tableta a teléfono. Esta aplicación es una aplicación de React. Y está construida internamente a partir de componentes de React. Entonces, si miramos la aplicación y miramos el código fuente, podemos ver archivos individuales. E incluso por el nombre, podemos darnos cuenta de que, por ejemplo, el footer es el componente footer, el header es el componente header, y así sucesivamente. Si tenemos instaladas las herramientas de desarrollo de React en nuestro navegador, podemos pasar el cursor sobre la lista de componentes a la izquierda y ver cada componente y dónde se presenta en el DOM a la derecha. Podemos ver el código fuente. Es una aplicación típica de React. El archivo index.js tiene un componente app que renderiza. El componente app importa el componente game y lo rodea con un proveedor de contexto donde se almacenan todos los datos. El componente app también importa el archivo CSS de la aplicación con todos los estilos. El componente game es donde se encuentra la mayor parte de la lógica. Importa todos los demás componentes como header y game section status e inicializa el juego. Y luego renderiza el header, la sección del juego, el estado, el footer y para esos componentes hijos, realmente pasa diferentes controladores como props. Esta es una arquitectura de aplicación React muy estándar. Así que veamos los componentes individuales. Toman algunas entradas y producen DOM, reaccionan a eventos del usuario.

2. Pruebas de componentes y montaje en Cypress

Short description:

Veamos qué espera un componente. El componente de números muestra números del uno al nueve en la cuadrícula de Sudoku. Puede resaltar un número específico según el contexto. El componente acepta props, como onClickNumber, para manejar las interacciones del usuario. Podemos pensar en el componente de números como una unidad de código que responde a diferentes propiedades, valores de contexto y eventos del usuario. Para escribir pruebas de componentes, necesitamos instalar Cypress y Cypress React unit test. También debemos configurar Cypress para agrupar las pruebas de componentes. En el archivo de especificaciones de números, montamos el componente de números y usamos los comandos de Cypress para interactuar con él. Sin embargo, los números no se ven correctamente en comparación con una aplicación real.

Veamos qué espera un componente. Voy a hablar sobre este componente de números. Muestra números o dígitos del uno al nueve que puedo ingresar en la cuadrícula de Sudoku. Puedes ver el componente en la esquina inferior derecha. Puedes resaltar un número específico porque ese es el número que estás a punto de ingresar. El número resaltado proviene del contexto. Por lo tanto, no tienes que pasarlo a través de todos los componentes. En cambio, el componente de números simplemente lo obtiene del contexto de Sudoku y lo usa para resaltar un número.

Pero este componente de números también acepta props. Y en este caso, el componente padre pasa la propiedad onClickNumber. Cada vez que un usuario hace clic en un número, esa propiedad se asocia con el número que el usuario selecciona. Por lo tanto, realmente podemos pensar en nuestro componente de números como esta unidad de código donde alimentamos diferentes propiedades, diferentes valores de contexto y eventos de usuario como clics. Y en respuesta, el componente de números genera una vista diferente y realiza llamadas a propiedades de salida. Esta visión de los componentes como simples unidades de código no es solo esta presentación. También he compartido mi filosofía sobre los componentes como unidades en otras charlas que puedes consultar.

Entonces, escribamos pruebas de componentes. Voy a instalar Cypress, que es un corredor de pruebas de código abierto gratuito y con licencia MIT. También voy a instalar Cypress React unit test, que es un adaptador para Cypress que te permite montar componentes de React directamente. Voy a agregar Cypress React unit test al archivo de soporte de Cypress y al archivo de complementos. Esto permitirá que Cypress agrupe las especificaciones de componentes de la misma manera que tu aplicación agrupa su código. Debido a que esta es todavía una función experimental, tendré que configurar en el archivo de configuración de Cypress experimental component testing true y decirle a Cypress que mis pruebas de componentes se encuentran en la carpeta de origen, junto a los archivos de origen.

Aquí hay una especificación de números que probará los números. Importaré una función de montaje de Cypress React unit test y importaré mi componente de números desde el archivo de números. Y aquí es donde sucede la magia. Voy a montar mi componente de números usando mount numbers. Después de que se monte, que es un comando asíncrono, tomaré cada dígito, cada número del uno al nueve, y escribiré un comando Cypress contains porque luego puedo usar cualquier comando Cypress para interactuar con mi aplicación. Y es una aplicación web real completa. El componente de números se monta y se estructura y se ejecuta como una miniaplicación web dentro de Cypress, como puedes ver en esta captura de pantalla. Pero los números no se ven bien. No se parecen en nada al componente en una aplicación real.

3. Estilización y Pruebas de Componentes

Short description:

En esta parte, aprendemos sobre la importancia de la estilización en nuestra aplicación y cómo afecta la apariencia de nuestros componentes. Discutimos la necesidad de renderizar los componentes de manera precisa proporcionando la estructura y estilos necesarios. También exploramos cómo probar las props de los componentes, los clics y los proveedores de contexto. Además, profundizamos en los desafíos de los cambios de CSS y el impacto que tienen en diferentes componentes y en la aplicación en general. Por último, destacamos la necesidad de revisar y guardar manualmente capturas de pantalla de la aplicación para asegurarnos de que cumple con nuestras expectativas de diseño.

Y eso es porque no tenemos estilos. Solo estamos montando los números. En nuestra aplicación, el CSS se importa por el componente de la aplicación. Como no tenemos el componente de la aplicación, estamos trabajando solo con los números en este momento. Importaremos el CSS de la aplicación nosotros mismos desde los archivos de especificación y lo incluiremos en la aplicación esqueleto.

Entonces, ahora nuestro componente de números se renderizará de manera más precisa, pero aún no perfectamente. Como puedes ver, está todo disperso. Esto se debe a que nuestro componente y nuestros estilos asumen una estructura de contenedor específica. Para renderizar el componente de números de manera precisa, debemos envolverlo en un div con la clase 'inter', en un contenedor y en una sección con la clase 'status'. De esta manera, el montaje será exactamente lo que nuestro CSS y la estructura esperan. Ahora puedo ver esos números en la pantalla de mi navegador real, tal como se ven en una aplicación real.

Genial, ¿y qué pasa con todas las props y los clics? Cuando monto los números desde mi prueba, puedo pasar una propiedad 'onClickNumber' y puedo crear un stub para que cada vez que se interactúe con los números, como aquí, obtenga el clic de vuelta. Puedo ver en el registro de comandos de Cypress que esos stubs realmente se involucraron en el clic del usuario. Excelente, la última pieza de entrada para mi componente es el proveedor de contexto, donde se obtiene el dato, como el número seleccionado. En este caso, cuando monto el componente de números, lo rodeo con el proveedor de contexto de Sudoku y establezco el número seleccionado en cuatro. Luego puedo ver que mi número en el DOM realmente tiene la clase que espero que tenga. Esta prueba confirma que el componente funciona como se espera.

Pero ahora llegamos al meollo del asunto en mi charla. ¿Qué pasa si cambio el CSS, los selectores, la estructura del DOM o los parámetros de diseño, solo un poco? Probablemente mi aplicación seguirá funcionando porque no rompí la lógica. Pero, ¿se ve bien? Es más fácil decirlo para el componente de números, sí, son solo números, y si un número seleccionado debe ser azul y debe estar en la cuadrícula. Pero, ¿qué pasa con componentes más grandes? Tienen muchos estilos agradables y únicos en este caso. Y si interactúo y tengo diferentes propiedades de contexto, se verán diferentes debido a lo que dije antes. ¿Cambiar el CSS de un componente afectará de repente a otro componente en otra parte del juego? ¿Y qué pasa con toda la aplicación? Se ve realmente bien en el escritorio. ¿Sigue viéndose tan bien en una tableta? ¿Y se ve bien en un dispositivo móvil? ¿Revisas manualmente tu aplicación cada vez que cambias un poco de CSS? Probablemente no puedas hacerlo. El truco aquí es entender que solo tienes que hacerlo manualmente como lo haría un ser humano. Cuando trabajas en la aplicación, cuando diseñas en CSS, quieres ver la aplicación en tu navegador y decir: sí, esto es lo que quiero. Las computadoras no pueden hacer eso automáticamente. En su lugar, cuando estés satisfecho con el resultado, guarda una captura de pantalla de tu aplicación.

4. Pruebas Visuales y Capturas de Imagen

Short description:

Digamos que esto es lo que quiero que se vea mi aplicación. Las computadoras pueden determinar si se ve exactamente igual píxel por píxel. En las pruebas de componentes, utilizamos el complemento de captura de imagen de Cypress para guardar una sección del DOM como una imagen. Esta imagen sirve como referencia para comparaciones futuras. Si los cambios de CSS afectan a los componentes, el comando de coincidencia de captura genera una imagen ligeramente diferente. La salida de diferencia muestra la imagen de referencia, la imagen actual y las diferencias de píxeles. La inspección visual manual permite identificar fácilmente los cambios. Generar la misma captura de imagen es crucial. El componente de temporizador en nuestro juego cuenta los segundos desde el inicio.

Digamos que esto es lo que quiero que se vea mi aplicación. Pero las computadoras, por otro lado, son realmente buenas en otra tarea. En lugar de decir que esto se ve bien, son muy buenas en decir que esto se ve exactamente igual píxel por píxel como solía verse antes. Así que sustituimos el problema de si esto se ve bien o es correcto, por si se ve igual. Y esto es lo que las computadoras pueden hacer.

Entonces, en nuestra prueba de componente, instalaré un complemento gratuito y de código abierto llamado captura de imagen de Cypress. Agregaré este complemento a mi archivo de soporte y en mi archivo de complementos. Lo que hará es que en esta prueba que teníamos antes, donde establecemos un número como seleccionado y confirmamos que ese número en el DOM tiene la clase 'status number selected'. Después de eso, hacemos una cosa más. Ahora tenemos este comando 'match image snapshot' que proviene de este complemento. Y este comando, la primera vez que ejecutas esta prueba, guardará esa sección del DOM renderizado en una imagen. Lo guardará en la carpeta de capturas de Cypress con el nombre de la prueba. Debes comprometer este archivo de imagen en tu repositorio fuente, justo al lado del archivo fuente. Porque esta imagen te dirá cómo debe verse la replicación de este componente a partir de ahora.

Ahora hagamos un cambio. Digamos que alguien va al archivo CSS y cambia el relleno de 12 píxeles a 10 píxeles. ¿Cómo afectará esto a todos nuestros componentes? Bueno, ejecutas la prueba y ese comando para coincidir con la captura de imagen ahora generará una imagen que se ve ligeramente diferente. Guardará esa diferencia en una carpeta de salida de diferencias como una imagen en sí misma. Y esta imagen tiene tres columnas. A la izquierda, ves la imagen de referencia. Esa es la que viste antes y almacenaste en tu repositorio fuente. A la derecha, ves la imagen actual. Y en el medio, ves la diferencia píxel por píxel con el rojo siendo píxeles muy diferentes y el amarillo siendo píxeles ligeramente diferentes. Y ahora puedes ver qué ha cambiado visualmente, ¿verdad? Como ser humano. Y ahora puedes decir, sí, esto es lo que quería. Oh no, no quiero esto. Y es fácil decir, oh, solo compara todos los componentes píxel por píxel y eso es el final de la historia. Y desafortunadamente, no lo es. Debes generar precisamente la misma captura de imagen cada vez que ejecutes la tarea. En nuestro juego, tenemos un componente de temporizador. Como puedes ver, simplemente cuenta los segundos desde el inicio del juego.

5. Tomando Capturas de Temporizadores

Short description:

Para generar la misma imagen píxel por píxel, necesitamos controlar los datos. Cypress proporciona el comando CyClock para congelar el reloj, lo que nos permite tomar capturas en momentos específicos. También podemos adelantar rápidamente el reloj para capturar capturas con diferentes valores de tiempo. Al controlar el reloj y utilizar datos constantes, podemos generar capturas precisas y consistentes de los temporizadores.

Bueno, ¿cómo tomamos una captura de un temporizador? Probablemente podamos tomar una captura de un temporizador en el tiempo cero, cero, cero, ¿verdad? Nuestra coincidencia de la captura podría ser lo suficientemente rápida como para capturarla tan pronto como el temporizador muestre cero, cero. Pero, ¿qué pasa si queremos esperar 10 minutos? ¿Qué pasa si queremos tomar una captura de un temporizador y a veces nos lleva en este segundo y a veces nos lleva en el segundo segundo, ¿verdad? ¿Qué pasa si capturamos esta transición? Crearemos una imagen con píxeles diferentes y será una prueba muy inestable. Entonces, ¿qué tenemos que hacer en este caso para generar precisamente la misma imagen píxel por píxel? Tenemos que controlar los datos. En este caso, tenemos que detener el reloj y Cypress incluye este comando en su API. Se llama CyClock. Una vez que congelamos el reloj, se detienen todos los intervalos, todos los temporizadores, todo. Luego podemos montar la aplicación, confirmar que se muestra el estado cero cero y luego tomar una captura. Y esta es la imagen que obtenemos. Además de CyClock, que congela el reloj, podemos adelantar rápidamente el reloj en este caso, 700 segundos. Y una vez que adelantamos rápidamente, sigue estando congelado. Así que adelantamos rápidamente el reloj al instante, la replicación se actualiza porque piensa que han pasado 700 segundos y luego podemos tomar una captura precisa de datos constantes y genera la misma captura de temporizador.

6. Tomando Capturas de todo el Tablero de Juego

Short description:

Podemos tomar una captura de todo el tablero de juego para confirmar que todos los componentes y elementos de la interfaz de usuario se vean iguales. Sin embargo, generar un nuevo tablero de juego con números diferentes cada vez dificulta la comparación de las capturas. Para simular la generación del tablero, podemos guardar los arreglos iniciales y resueltos de números como archivos JSON e importarlos en nuestras pruebas. Al congelar el reloj y controlar los datos, podemos generar capturas consistentes con diferentes movimientos. El depurador de viaje en el tiempo de Cypress nos permite analizar los cambios y la apariencia del tablero durante la prueba. Además, discutimos cómo manejar las capturas localmente y en un servidor de integración continua, considerando factores como las diferencias de resolución y la densidad de píxeles.

Pero eso no es todo, ¿verdad? Hemos analizado componentes pequeños. ¿Por qué no tomar una captura de todo el tablero de juego, ¿verdad? Después de todo, nuestro juego es un árbol de componentes y realmente habremos escrito pruebas para los componentes pequeños, ¿por qué no escribir una prueba para el componente de la aplicación? En una sola captura, confirmarías con todo el tablero con todos los datos y todos los componentes y todos los elementos de la interfaz de usuario se ven iguales. Pero no es tan fácil porque cada vez que haces clic en un nuevo juego, ¿verdad? En realidad, crea un nuevo juego por definición. Entonces genera un tablero diferente y no puedes comparar ambos tableros, ¿verdad? Siempre tendrán diferencias de píxeles debido a los números diferentes. ¿Entonces, cómo simulamos la generación del tablero? Bueno, tenemos que mirar nuestro código fuente. En este juego, quiero decir, este archivo game.js, podemos ver que getUniqueSudoku se importa de otro módulo. Luego se utiliza para generar una matriz inicial de números y una matriz resuelta de números. Entonces, fui a DevTools y en una iteración del juego, simplemente tomé esas variables y las guardé exactamente como archivos JSON en la carpeta de accesorios de Cypress. Luego, dentro de mi prueba, importo ese módulo como un objeto. Y luego en ese objeto, puedo usar un side stop, ya sabes, el mismo enfoque que uso para detener los controladores de clic. Y dije, en ese módulo, detén el método getUniqueSudoku y siempre úsalo en las mismas matrices. Ahora, congela el reloj, toma la captura. A partir de ahora, cada vez que ejecute el juego, generará exactamente el mismo tablero. Puedo construir sobre eso. Si tengo el mismo tablero, puedo hacer un movimiento, confirmar que se hizo y luego tomar otra captura y ahora hay una captura de un tablero con un solo movimiento. Aún mejor, Cypress tiene un depurador de viaje en el tiempo. Entonces, cuando trabajamos con pruebas de componentes, puedo pasar el mouse sobre cada comando y ver qué sucedió durante la prueba. ¿Qué hice clic? ¿Cómo ha cambiado el tablero? ¿Cómo se ve ahora? Puedo ver todo lo que está sucediendo durante mi prueba de componente React. Ahora hablé sobre pruebas de componentes, mostré cómo configurar pruebas de captura visual y hablé sobre cómo controlar tus datos para obtener las mismas imágenes píxel por píxel. Ahora hablemos de cómo funciona localmente y en CI. El primer problema, si ejecuto Cypress en modo interactivo, veo los resultados y miro la captura de pantalla que guardé, puedo ver que su resolución es realmente el doble que si ejecutara Cypress en modo headless en Mac debido a la densidad de píxeles. Entonces, el primer truco que hago cuando trabajo con capturas localmente es desactivarlas. No las tomo en modo interactivo porque su resolución será el doble que en modo headless, incluso en el mismo mapa. Entonces, en su lugar, las omito, puedo ver dónde las omito y cada vez que quiero agregar una nueva imagen de captura, simplemente ejecuto Cypress run headlessly. Si tengo una captura actualizada y realmente quiero guardar una nueva imagen, ejecuto Cypress headlessly y establezco una variable de entorno que le indica al complemento que actualice la captura y no falle en las diferencias. Bueno, esto es lo que hago localmente, ¿verdad? Pero luego subo mi código y mis imágenes de captura al servidor de integración continua. Y adivina qué, hay una diferencia píxel por píxel. Incluso el temporizador, a la izquierda puedes ver la salida de una captura de pantalla headless en Mac. A la derecha, ves la salida de una captura de pantalla headless en Linux. En el medio, hay pequeñas diferencias en la representación de fuentes, en la restauración, en el aliasing.

7. Pruebas Visuales con Docker y Cypress

Short description:

Para garantizar pruebas visuales consistentes en diferentes sistemas operativos, Gleb utiliza un contenedor Docker con la imagen cypress-included. Esto elimina la necesidad de instalar cualquier cosa y asegura que todas las dependencias y representaciones sean las mismas. Al ejecutar pruebas en CI, Gleb utiliza un contenedor que coincide con la imagen. Al permitir que se generen todas las imágenes y usar un script para verificar las diferencias visuales, Gleb garantiza la precisión de las capturas de pantalla. En resumen, Cypress React-Unit test es ideal para pruebas de componentes y capturas visuales con Cypress image snapshot. Gleb recomienda considerar un servicio de pago de terceros para una implementación más sencilla.

No puedo recrear el mismo contenido píxel por píxel en Mac, Windows y Linux. Por lo tanto, el truco aquí es utilizar exactamente el mismo entorno, exactamente el mismo sistema operativo, con exactamente las mismas bibliotecas y fuentes y navegadores, versión, todo, tanto localmente como en CI.

Entonces, lo que sucede es que en mi paquete JSON, en lugar de simplemente ejecutar un comando 'yarn cypress run', configuro un comando que ejecuta la prueba de Cypress utilizando Docker, y tenemos una imagen de Docker llamada 'cypress-included'. Por lo tanto, no tengo que instalar nada. Cada vez que quiero actualizar las capturas de pantalla o agregar nuevas, simplemente ejecuto ese comando, que inicia nuestro contenedor Docker y ejecuta todo. Cuando ejecuto las pruebas en CI, las ejecuto en un contenedor que coincide exactamente con esa imagen. 'Cypress-excluded' se basa en los navegadores de Cypress. Por lo tanto, sé que todas las dependencias del sistema operativo, todas las fuentes, todo es lo mismo. La representación debería ser la misma.

Entonces, en las solicitudes de extracción, no fallo las imágenes. Simplemente permito que se generen todas, y luego uso un pequeño script para publicar una comprobación de estado de GitHub en la captura de pantalla. En este caso, hubo una diferencia visual, y cuando se actualizó, no hubo diferencias visuales en las capturas. Así que todo está bien. En resumen, Cypress React-Unit test es excelente para pruebas de componentes, capturas visuales con Cypress image snapshot. Hablamos sobre marcar datos en el flujo. Y para ser honesto, me encantan las capturas de pantalla de imágenes de Cypress, pero requieren mucho esfuerzo para que todo funcione. Así que si puedes considerar un servicio de pago de terceros. Muchas gracias. Puedes encontrar las diapositivas en línea y puedes encontrar el ejemplo en el repositorio. Gracias. ¡Wooo!

Gracias, Gleb. Voy a secarme la cabeza porque mi cerebro acaba de explotar. Qué gran charla. ¿Te importaría subir y responder algunas preguntas en vivo, por favor? Absolutamente, Bruce. Gracias a todos por ver. Fue increíble. Gracias. Tenemos algunas preguntas para ti. Nos gusta llamar a esto el interrogatorio despiadado de cinco minutos.

QnA

Usando Cypress y Cypress React Unit Test

Short description:

Si te hago llorar, solo dime que pare. ¿En qué situaciones usarías Cypress en lugar de otro paquete de representación de componentes como storybook? Nos encanta storybook en Cypress. Te permite montar un componente React, diseñarlo, ajustar diferentes entradas y comparar cómo se veía antes. Con Cypress, puedes montar un componente, interactuar con él como un usuario y ver qué hace. Si quieres interactuar con un componente, prueba Cypress React Unit Test.

Si te hago llorar, solo dime que pare.

Primera pregunta, que tenemos de Dennis o Dennis 1975 y preguntas similares de otras personas. ¿En qué situaciones usarías Cypress en lugar de otro paquete de representación de componentes como storybook por ejemplo? Nos encanta storybook en Cypress. Lo usamos nosotros mismos, ¿verdad? Te permite montar un componente React y diseñarlo, ajustar diferentes entradas. Tal vez tomar una captura de pantalla y comparar cómo se veía antes. Y con Cypress siempre queremos decir montar un componente y luego hacer clic en un botón como lo haría un usuario, ver qué hace el componente, tal vez hace una solicitud de red. Entonces, si quieres interactuar con un componente, probablemente quieras probar Cypress React Unio test. porque tu componente está montado y se convierte en una miniaplicación web. Por eso lo usarías.

Otra pregunta. ¿Podremos usar WebGL real con Cypress? Eso no es lo que controla Cypress, ¿verdad? Generar una captura de pantalla, creemos que debería generar e incluir la parte de WebGL, pero tengo un experimento, así que no puedo confirmarlo. Después de generar una imagen, no importa qué la haya generado, ¿verdad? ¿Fue un DOM? ¿Fue un lienzo? ¿Fue WebGL? En ese punto, son solo píxeles, y después de eso, puedes compararlos. Creo que el problema con WebGL es que no sabes cuándo se ha detenido la representación, ¿verdad? Cuándo tomar una captura de pantalla. Entonces, de alguna manera, cuando renderizas una escena de WebGL, debes establecer una propiedad o exponer algún tipo de atributo observable donde Cypress sepa que debe esperar eso, y luego tomar una captura de pantalla. Si puedes hacer eso, entonces creo que la comparación de imágenes debería funcionar bien. Gracias.

La transición de Microsoft a Chromium y el soporte de Cypress

Short description:

Estábamos muy contentos cuando Microsoft anunció que se estaba trasladando al motor de Chromium. El nuevo navegador Microsoft Edge está construido sobre Chromium, lo que permite que Cypress admita múltiples navegadores. Fue una solicitud de la comunidad de usuarios la que implementó esta función, y quedamos impresionados por la contribución. Felicitaciones al equipo de Microsoft y a la contribución de la comunidad de usuarios, que muestra la belleza del código abierto.

Una pregunta de alguien llamado Metin. ¿Qué tan satisfecho estaba tu equipo cuando Microsoft anunció que se estaba trasladando al motor de Chromium? Estábamos muy contentos. Entonces, el nuevo navegador Microsoft Edge está construido sobre Chromium, lo que significa que Cypress puede abrir ese navegador y controlarlo utilizando el mismo enfoque, las mismas banderas, los mismos ganchos que usamos para controlar Chrome y Electron regularmente. Eso realmente nos permite decir que admitimos múltiples navegadores. Lo divertido de esto es que no lo hicimos nosotros mismos, fue una solicitud de la comunidad de usuarios la que lo implementó. Cuando lo pulimos, fue una contribución completa de la comunidad de usuarios al proyecto de código abierto. Quedamos realmente impresionados por esta contribución en particular y felicitaciones al equipo de Microsoft por avanzar hacia un navegador. Felicitaciones al equipo de Microsoft y felicitaciones a la contribución de la comunidad de usuarios, la belleza del código abierto en acción.

Evitando la Inestabilidad y las Repeticiones de Pruebas

Short description:

En Cypress, luchamos arduamente para que los comandos sean libres de inestabilidad. Tenemos un mecanismo de reintento incorporado y nos encargamos de esperar a que los elementos estén habilitados y visibles. Sin embargo, existen otras fuentes de inestabilidad, como problemas del servidor, problemas de red y renderizado del navegador. Estamos abordando esto al proporcionar análisis en nuestro panel de control para ayudarte a decidir si una prueba está fallando de manera confiable o si debe ser ignorada. También estamos agregando repeticiones de pruebas como una función principal para volver a ejecutar automáticamente las pruebas fallidas.

Otra pregunta es, ¿qué podemos hacer para evitar la inestabilidad y cómo podemos detectarla automáticamente? Excelente pregunta. En Cypress, luchamos arduamente para que los comandos individuales sean lo más libres de inestabilidad posible. Cypress tiene un mecanismo de reintento incorporado, pero esperaremos a que el elemento esté habilitado y visible antes de hacer clic. Nos encargamos de eso. Pero existen otras fuentes de inestabilidad. Por ejemplo, cuando pruebas la aplicación completa que realiza solicitudes a un servidor, recibe una respuesta, actualiza la interfaz de usuario, hay muchas cosas que pueden fallar temporalmente y luego volver a funcionar. Tal vez el servidor estaba ocupado y no respondió. Tal vez la red se cayó. Tal vez el navegador tuvo un problema y no se renderizó.

Inestabilidad, Futuro y Comida Reconfortante

Short description:

De cada 100 pruebas de extremo a extremo, puede haber fallas ocasionales. Cypress está introduciendo análisis en el panel de control para ayudarte a determinar si una prueba está fallando de manera confiable o si debe ser ignorada. También están agregando repeticiones de pruebas como una función principal, lo que te permite volver a ejecutar pruebas fallidas. Cypress tiene un plan de desarrollo con características próximas, incluyendo banderas experimentales para el soporte de shadow dump y el polyfill de window.fetch. La documentación se mantiene actualizada con todas las características que están por venir. Por último, a Gleb se le pregunta sobre su comida reconfortante favorita.

En ese caso, de cada 100 pruebas de extremo a extremo, puede haber una que falle ocasionalmente. Ahora, la vuelves a ejecutar y siempre pasa. No quieres bloquear el flujo de trabajo, pero aún así tienes que hacer algo. Estamos haciendo dos cosas para resolverlo. Primero, en nuestro panel de control, ahora tenemos análisis que mostrarán toda la información histórica sobre cada prueba. Puedes decidir si esta prueba está fallando de manera confiable. ¿Debería estar fallando? ¿Es no-flake o debería ignorarla? También estamos agregando repeticiones de pruebas complementarias. Ya está disponible en Cypress como un complemento donde, si ejecutas una prueba, puedes designar una prueba específica y decir, si falla, vuelve a ejecutarla hasta, digamos, dos veces. O puedes habilitarlo globalmente. Lo estamos agregando como una función principal. Solo debes estar atento a nuestras notas de lanzamiento. Pronto estará disponible. Podrás controlarlo a nivel global o por prueba. Creo que eso resolverá toda esta inestabilidad que está fuera de tu control y que es tan frustrante. Me desactivo el silencio. Gracias. Ahora te hemos tentado a hablar sobre lo que puede venir en el futuro. Una pregunta de Iraudir. Una pregunta de Davulca. ¿Qué plan de desarrollo tienes para las próximas versiones? Así que tenemos muchas características próximas. Tenemos un enlace en nuestra documentación al plan de desarrollo. Las principales son consolidar lo que hemos lanzado como banderas experimentales. Ya tenemos una bandera experimental para el soporte de shadow dump, que fue una gran característica. Tenemos una nueva bandera experimental que saldrá el lunes con el polyfill de window.fetch. Y esto es una medida temporal antes de que lancemos el stubbing completo de red que te permitirá hacer lo que quieras desde tu prueba, detener recursos estáticos, controlar cómo detienes GraphQL, todas esas cosas. Así que consulta nuestra documentación. Tenemos un plan de desarrollo, lo mantenemos actualizado y te enterarás de todas las características que están por venir.

Documentación actualizada, estas son palabras que me encanta escuchar, pero rara vez encuentro. Así que gracias, Gleb.

Q&A: Comida Reconfortante, Cypress vs Puppeteer+Jest

Short description:

Última pregunta: ¿comida reconfortante favorita? ¿Docker se ejecuta lento en el gancho de confirmación? Cypress permite especificar archivos de prueba usando el parámetro spec. Ejecuta pruebas de integridad en cada confirmación, conjunto completo en solicitudes de extracción. No hay planes para el soporte de React Native. Cypress es una herramienta de prueba de extremo a extremo dirigida con funciones integradas. Diferencia con Puppeteer y Jest: Cypress tiene un depurador con viaje en el tiempo, soporte multi-navegador y todas las herramientas para CI y depuración de pruebas fallidas.

Última pregunta, como puedes ver, de los cuatro MCs, cuatro de nosotros somos cocineros ávidos. ¿Cuál es tu comida reconfortante favorita? Por ejemplo, si una compilación se rompe o GitHub se cae. ¿Cuenta la cerveza como comida? Porque me encanta la cerveza. ¿Cuenta la cerveza como comida? Soy inglés. La cerveza es comida, absolutamente. Absolutamente, totalmente.

Mencioné que Iraldeer tenía una pregunta. Es una pregunta detallada. Dicen, hemos encontrado que una ejecución de Docker puede ser bastante lenta en un gancho de confirmación. ¿Hay alguna forma de tener confianza en una base de confirmación en lugar de solo en las solicitudes de extracción? Mira nuestra documentación. Sabes, puedes definir qué prueba quieres ejecutar, ¿verdad? Probablemente sea más complicado que simplemente decir ejecutar todas las pruebas, ¿verdad? Así que depende de ti, ¿en qué tienes confianza? Cypress te permite especificar qué archivos de prueba quieres ejecutar usando el parámetro spec. Entonces tal vez quieras ejecutar solo algunas pruebas de integridad en cada confirmación, y solo si pasan, luego ejecutar el conjunto completo de pruebas, ¿verdad? Creo que eso acelerará tus pruebas y aún te dará plena confianza. Probablemente deberías ejecutar el conjunto completo de pruebas en las solicitudes de extracción y en la rama principal o ramas principales, hemos cambiado el nombre de nuestras ramas. Pero para confirmaciones más pequeñas, probablemente quieras ejecutar al menos un pequeño subconjunto de pruebas.

Bien, otra pregunta sobre el futuro, ¿habrá soporte para React Native en el futuro? No tenemos planes concretos. Como puedes ver, incluso el soporte de aplicaciones web React todavía es una característica experimental. Probablemente podrás ejecutar muchas pruebas mientras el componente se renderiza en el navegador. Una vez que se renderiza en una aplicación móvil, no tenemos planes. Es una plataforma muy diferente. Así que no tenemos planes de dominar las pruebas móviles todavía. Entendido, 10 personas votaron a favor de esta pregunta. ¿Cómo ves la diferencia entre Cypress y Puppeteer más Jest? Bueno, nos encantaría que todos escribieran más pruebas con Puppeteer, más pruebas con Jest y más pruebas con Cypress. Realmente no estamos compitiendo para quitar la cuota de mercado de Puppeteer, ¿verdad? Creemos que el 90% de los desarrolladores no están escribiendo pruebas de extremo a extremo. Así que Puppeteer puede tomar el 45%, nosotros tomaremos el 45. Creo que la diferencia es que con Cypress, tienes una herramienta específicamente dirigida a las pruebas de extremo a extremo. Con un depurador con viaje en el tiempo, con soporte multi-navegador, con todas las buenas aserciones integradas, no tienes que instalar nada. Ya hemos instalado todo lo que configuramos y lo probamos hasta la saciedad, ¿verdad? Y tenemos todas las herramientas y todas las comodidades para ejecutarlo en CIs, para observar los resultados, para depurar pruebas fallidas. Con Puppeteer y Jest, tienes algunas partes de eso, pero no es un sistema único, sino una combinación de dos sistemas dispares que tendrás que mantener. Entonces, lo siento. Lo siento, silenciado.

Why Use jQuery in Cypress?

Short description:

Alguien preguntó por qué usas jQuery y daré un mejor contexto sobre esto. jQuery te permite trabajar con elementos en una página para encontrarlos de manera confiable y probada en batalla. Cypress incluye muchas cosas y una sola descarga de jQuery no agregará peso. Ha sido probado en batalla durante mucho tiempo, se ejecuta en todos los navegadores y hace lo que se le indica. Gracias, Gleb, por tus conocimientos y por responder nuestras preguntas.

Por último, esta pregunta también tuvo 10 votos a favor. Alguien preguntó por qué usas jQuery y daré un mejor contexto sobre esto, pero recientemente tuve que usarlo, estaba en un proyecto que estaba usando jQuery y me encantó. Fue maravilloso usar una pequeña biblioteca que hacía lo que yo quería en lugar de hacerme hacer lo que ella quería. Y sé que jQuery no es necesariamente lo más moderno, pero creo que el almanaque de los archivos HTTP mostró que está en el 70% de los sitios web o algo así. Entonces, ¿por qué sigues usándolo? Bueno, no hay nada de malo en jQuery. Te permite trabajar con elementos en una página para encontrarlos de manera confiable y probada en batalla. Así que podemos discutir sobre cualquier otra tecnología pero para encontrar un elemento en una página jQuery es perfecto.

Ahora podrías decir, bueno, ¿no es pesado o no agrega sobrecarga? Bueno, Cypress incluye tantas cosas para controlar el navegador y ejecutar las tareas. Una sola descarga de jQuery en un escritorio que haces solo una vez no agregará peso. Es una biblioteca agradable que si no estamos satisfechos con ella, realmente reescribimos partes, ¿verdad? Pero la API sigue siendo la misma. Así que jQuery es simplemente una gran herramienta. Entonces, ¿la usaremos, verdad? Sí, quiero decir, como dijiste, ha sido probado en batalla desde hace mucho tiempo... Ha estado funcionando desde que no tenía cabello blanco. Se ejecuta en todos los navegadores. Y sí, lo que me encanta es que hace lo que se le indica. No exige que yo diseñe de cierta manera o cambie la forma en que trabajo.

Gleb, ha sido fabuloso hablar contigo. Voy a agitar mi batidora mágica y transportarte de vuelta a la sala de conferencias porque sé que habrá una llamada de Zoom donde los titulares de boletos pagados podrán interrogarte más a fondo. Espero no haberte dado un tiempo horrible. Muchas gracias por tus conocimientos y por responder nuestras preguntas. Gracias, Bruce. Gracias a todos. ♪ Hey, hey, hey, hey, hey, hey, hey, hey, hey, hey, hey ♪

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

JSNation 2023JSNation 2023
29 min
Modern Web Debugging
Few developers enjoy debugging, and debugging can be complex for modern web apps because of the multiple frameworks, languages, and libraries used. But, developer tools have come a long way in making the process easier. In this talk, Jecelyn will dig into the modern state of debugging, improvements in DevTools, and how you can use them to reliably debug your apps.
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.
JSNation 2022JSNation 2022
21 min
The Future of Performance Tooling
Top Content
Our understanding of performance & user-experience has heavily evolved over the years. Web Developer Tooling needs to similarly evolve to make sure it is user-centric, actionable and contextual where modern experiences are concerned. In this talk, Addy will walk you through Chrome and others have been thinking about this problem and what updates they've been making to performance tools to lower the friction for building great experiences on the web.
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!

Workshops on related topic

React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
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.