Veo lo que está sucediendo: Pruebas visuales para tus 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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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

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 ♪