Pruebas para la Web Moderna con Playwright

Hola, mi nombre es Arjun y estoy emocionado de estar aquí en Test.js y hablarles sobre las pruebas. Soy un gerente de programa en Microsoft, donde mi equipo está construyendo Playwright. Playwright es una nueva biblioteca para pruebas de extremo a extremo en múltiples navegadores de aplicaciones web.

En esta charla les hablaré sobre las pruebas en la web moderna. Mi equipo y yo hemos interactuado con cientos de probadores y desarrolladores que están construyendo aplicaciones web modernas, y hemos diseñado Playwright para satisfacer sus necesidades. También les mostraré las ideas principales detrás de Playwright y espero convencerlos de por qué Playwright es la herramienta de pruebas adecuada si están construyendo una aplicación web moderna.

Comencemos. Empecemos hablando sobre la plataforma web moderna. La plataforma web moderna es más capaz que nunca. Los navegadores web han madurado significativamente en los últimos años. Se ejecutan en todos los dispositivos que tenemos, incluyendo nuestro escritorio, nuestros teléfonos y televisores inteligentes. También ha habido una continua incorporación de nuevas características en la plataforma web. Por ejemplo, la web ahora puede detectar tu ubicación actual, puede conectarse a dispositivos Bluetooth y también interactuar con tu sistema de archivos. El ritmo de innovación en la plataforma web ha sido increíble.

Estos cambios en la plataforma web han impulsado la innovación en el mundo de las aplicaciones. Si observamos las aplicaciones de escritorio, son muy similares a lo que eran hace 10 años, pero las aplicaciones web son muy diferentes. Las aplicaciones web de hoy en día son aplicaciones completas que tienen interacciones ricas y receptivas. Estamos construyendo aplicaciones de una sola página que se crean con nuevos frameworks reactivos de JavaScript. También estamos construyendo PWAs que están reemplazando a las aplicaciones nativas. Tanto la plataforma como nuestras aplicaciones en la web han evolucionado significativamente.

Con estos cambios, también hemos visto cambios en la forma en que los equipos operan. Los equipos de desarrolladores y probadores están avanzando más rápido. Muchos equipos están construyendo aplicaciones hoy en día y hay presiones competitivas que los empujan a lanzar más rápido, porque así es como logran sus objetivos comerciales. Esto ha llevado a los equipos a adoptar flujos de trabajo más nuevos como CI, CD y despliegue continuo. Los equipos también están buscando soluciones de pruebas automatizadas para poder lanzar aún más rápido. Desafortunadamente, las pruebas de extremo a extremo no han evolucionado tan rápido como la web misma. Hablemos un poco más sobre eso.

Las pruebas de extremo a extremo deben evolucionar para los cambios que hemos mencionado en la web moderna. Por ejemplo, las pruebas deben poder automatizar las nuevas características de la plataforma que están apareciendo en los navegadores. Estas incluyen capacidades disponibles en navegadores de escritorio, capacidades disponibles en navegadores móviles e incluso capacidades que se están impulsando en televisores inteligentes. Los equipos están luchando por poder automatizar todas las partes de su aplicación porque sus pruebas no pueden cubrir todas las capacidades que están utilizando. Las aplicaciones de hoy en día también son más difíciles de automatizar. Las pruebas no pueden mantenerse al día con cómo funcionan los frameworks reactivos. Por lo tanto, los equipos que están construyendo aplicaciones de una sola página con interacciones ricas encuentran que sus pruebas de extremo a extremo son inestables. No pueden automatizar de manera confiable las interacciones del usuario en sus aplicaciones. Lo que sucede como resultado es que las pruebas de extremo a extremo que en realidad deberían ayudarte a avanzar más rápido, en realidad están ralentizando a los equipos. Los equipos terminan teniendo que agregar tiempos de espera o reintentos para poder manejar problemas de confiabilidad. Los equipos están luchando con problemas de cobertura porque no pueden automatizar todas las partes de su aplicación. Por lo tanto, las pruebas de extremo a extremo están ralentizando a los equipos cuando realmente necesitan poder lanzar más rápido. Estos tres problemas son la razón por la cual las pruebas de extremo a extremo no han podido evolucionar para la web moderna. Y estos tres problemas nos dan realmente los tres pilares de las pruebas en la web moderna. Las pruebas en la web moderna deben ser capaces para poder automatizar todas las posibles capacidades de la plataforma web moderna. Las pruebas en la web moderna también deben ser confiables, lo que significa que deben poder automatizar de manera confiable las interacciones del usuario con aplicaciones web altamente ricas y receptivas. Y finalmente, las pruebas en la web moderna deben ser rápidas, lo que significa que deben poder acelerar nuestros procesos de envío y lanzamiento en lugar de ralentizarlos.

Cualquier solución de pruebas para la web moderna debe ser capaz, confiable y rápida, los tres pilares de las pruebas modernas en la web. Nos hemos enfocado en estas tres ideas principales al construir Playright, lo que significa que Playright se enfoca en una automatización capaz sin compromisos. También se enfoca en una automatización confiable sin fallos ni problemas de tiempo. Y finalmente, Playright permite una ejecución rápida, al igual que las pruebas unitarias. Por lo tanto, puedes utilizar pruebas de extremo a extremo con Playright para acelerar tus flujos de trabajo de pruebas y no ralentizarlos.

Para el resto de la charla, me enfocaré en cada una de estas tres ideas principales y te mostraré código sobre cómo se implementan en Playright y cómo puedes aprovechar al máximo estas capacidades en tus pruebas mientras envías tus aplicaciones. Comencemos con la capacidad. Automatización capaz sin compromisos. Veamos un poco de código. Aquí tengo un fragmento muy simple que utiliza Playright en JavaScript. Playright es, en su esencia, una herramienta para escribir pruebas de extremo a extremo para tu aplicación web, lo que significa que con la API de Playright puedes automatizar interacciones del navegador. Puedes lanzar un navegador y automatizar las interacciones que ocurren dentro de esa ventana del navegador. En este fragmento de código en particular, estoy utilizando Playright para lanzar una instancia de Chromium. Chromium es el motor de navegador que se utiliza en Google Chrome y Microsoft Edge. Una vez que he lanzado ese navegador, abro una nueva página, lo que significa que abro una nueva pestaña en esa ventana del navegador con Playright. Luego, esa página en particular navega a la página de inicio de TestJS. Por último, cierro el navegador y finalizo mi script básico. Playright permite esto, lo que significa que puedes utilizar Playright para automatizar Chromium. Junto con Chromium, también puedes utilizar Playright para automatizar Firefox y WebKit. Estos tres hacen de Playright la herramienta de pruebas multi-navegador adecuada para la web moderna, ya que Chromium, Firefox y WebKit cubren los tres principales motores de navegador que se utilizan en los navegadores modernos hoy en día. Hemos hablado de Chromium, que impulsa Microsoft Edge y Google Chrome, Firefox impulsa Mozilla Firefox y WebKit es el motor de navegador utilizado en Apple Safari. Playright te proporciona una API que puede automatizar los tres navegadores. En este fragmento de código en particular, estamos lanzando una instancia de WebKit y luego realizando la misma interacción. Algo notable aquí es que Playright WebKit está disponible en todas las plataformas, lo que significa que puedes utilizar WebKit para probar problemas de Safari en tus entornos de CI de Linux, por ejemplo, y eso es posible gracias a Playright.

Veamos cómo funcionan más de estas capacidades. Con Playright, puedes tener navegadores ejecutándose tanto en modo sin cabeza como en modo con interfaz gráfica. Esto significa que puedo ejecutar mis pruebas en CI en modo sin cabeza, para que la interfaz de usuario no sea visible y mis pruebas se ejecuten más rápido. Pero también puedo ejecutar estas pruebas localmente en modo con interfaz gráfica, donde puedo ver la interfaz de usuario y ver lo que ha sucedido en el navegador. Esta funcionalidad, nuevamente, está disponible en todas las plataformas. Cuando probamos nuestras aplicaciones web modernas hoy en día, no se trata solo de probarlas en nuestros entornos de escritorio.

También estamos desarrollando aplicaciones para dispositivos móviles. Con Playwright, podemos emular entornos móviles en nuestras pruebas multi-navegador. Por ejemplo, al lanzar una instancia de WebKit, especificamos que la página de WebKit debe emular el dispositivo iPhone 11. Esto significa que mi página tendrá el mismo tamaño de vista que un iPhone 11 y habilitará funciones específicas para dispositivos móviles, como eventos táctiles.

Hablando más sobre las capacidades, mencionamos cómo la web actual puede detectar tu ubicación actual. Al lanzar un navegador con Playwright, puedes utilizar estas nuevas características web. En este fragmento en particular, estoy lanzando el navegador y especificando que se habilite el modo oscuro. También estoy especificando una ubicación geográfica particular para esa ventana del navegador, así como una serie de permisos y configuraciones locales. De esta manera, mi navegador funciona como si tuviera una ubicación simulada. Esto te brinda una vista previa rápida de cómo Playwright permite las nuevas características web para que puedas probar tus aplicaciones con esas capacidades.

Otra capacidad importante que quiero resaltar es que Playwright también puede interceptar la actividad de red. En este fragmento en particular, cuando lanzo un navegador y creo una nueva página, configuro una API simulada para que mi punto final de API devuelva un código de error. Esto me permite probar escenarios de error con las capacidades de red de Playwright. Y finalmente, otra capacidad destacada es que Playwright puede automatizar interacciones en múltiples páginas. No estás limitado a una sola página. En este ejemplo, estoy lanzando una instancia del navegador, creando una nueva página y luego abriendo un nuevo popup. Luego podemos automatizar ese popup con Playwright.

Lo que acabamos de ver fue una automatización sin compromisos. Pudimos automatizar todos los navegadores web modernos, obtener ejecución tanto en modo sin cabeza como en modo con interfaz gráfica en todas las plataformas. También vimos la emulación de dispositivos para pruebas móviles y la mejor cobertura para las API de la plataforma web moderna. Si estás utilizando alguna de estas API, Playwright es realmente la mejor herramienta para crear tus pruebas de extremo a extremo y asegurarte de que todas las características de tu aplicación estén cubiertas. Esto concluye la sección de capacidades.

Ahora hablemos de la confiabilidad. Como mencionamos anteriormente, la confiabilidad es básicamente el problema de poder automatizar las interacciones del usuario en tu aplicación sin que tus pruebas sean inestables. En muchos casos, los usuarios tienen que establecer tiempos de espera, lo que significa que deben hacer que sus pruebas esperen un tiempo determinado para poder automatizar de manera confiable. Esto crea una serie de problemas porque los tiempos de espera pueden generar inestabilidad. Playwright resuelve estos problemas de una manera muy única. Veamos cómo. Lo más importante a tener en cuenta sobre Playwright es que puede escuchar los eventos del navegador.

En realidad, puede obtener eventos del navegador y comprender lo que está sucediendo en tu aplicación cuando se está ejecutando dentro del navegador. En este fragmento en particular, estoy lanzando una instancia de Firefox, estoy creando una nueva página y luego estoy configurando un nuevo escuchador de eventos para esa página en particular. Básicamente, estoy diciendo que cada vez que mi aplicación genere un registro de consola, debería mostrarse en mi prueba. Playwright no se limita a los registros de consola. También puedo escuchar otros eventos, como el evento de carga del contenido del DOM. El evento de carga del contenido del DOM es un evento importante del ciclo de vida cuando tu aplicación o tu página web se carga dentro del navegador. Y puedo escuchar este evento como parte de mi prueba.

También puedo escuchar la actividad de la red. Por ejemplo, puedo verificar si se ha abierto una conexión de WebSocket específica. Esta capacidad de escuchar eventos le brinda a Playwright la capacidad de esperar eventos precisos en lugar de tener que esperar de manera generalizada y utilizar temporizadores de espera. Esto hace que tus pruebas sean altamente confiables.

Playwright utiliza esta funcionalidad internamente en cada interacción. En este fragmento, estoy lanzando una instancia de Firefox y luego voy a github.com y luego hago clic en un botón. Observa que no tuve que usar ningún temporizador de espera. Esto se debe a que el método page.click de Playwright espera automáticamente las condiciones adecuadas. Espera a que el elemento sea visible, espera a que el elemento deje de animarse, espera a que el elemento reciba eventos de clic. Todo esto se hace internamente para que tus interacciones de usuario puedan ir de manera confiable a tus aplicaciones y probar tus aplicaciones. Esto hace que tus pruebas sean significativamente más fáciles de escribir y mantener a lo largo del tiempo, porque no tienes que preocuparte por condiciones de espera personalizadas o temporizadores de espera. En muchos casos, estas configuraciones predeterminadas funcionan sin problemas, pero en caso de que estés buscando más control, Playwright también te proporciona APIs para ofrecer tus propias condiciones de espera personalizadas. Estas condiciones de espera utilizan la misma lógica de eventos completa, lo que significa que no tienes que preocuparte por adivinar cuánto tiempo tomará. Puedes escribir esa condición precisa y asegurarte de que tus pruebas realmente esperen por ella. Esto muestra cómo Playwright es más confiable. Básicamente, esto significa que no necesitas adivinar cuánto tiempo tomará algo. Puedes usar eventos para verificar el estado de la aplicación. Y esto está, ya sabes, envuelto automáticamente para todas las interacciones dentro de Playwright, lo que significa que todo lo que haces en Playwright tiene esperas y reintentos automáticos incorporados. Y finalmente, si tu aplicación requiere lógica personalizada, tienes APIs de espera poderosas que puedes usar y crear tus propias condiciones de espera. Esta característica diferencia a Playwright de otras herramientas de testing y mejora la confiabilidad.

Ahora hablemos de la ejecución rápida, ya sabes, los desarrolladores y probadores generalmente están muy satisfechos con sus pruebas unitarias porque se ejecutan de manera confiable y son rápidas de ejecutar. Sin embargo, ese no es el caso con las pruebas de extremo a extremo porque dependen de los navegadores y los navegadores pueden ser lentos, especialmente cuando se trata de abrir y cerrar un navegador. Si estás ejecutando cientos de pruebas, poder ejecutar cientos de navegadores es una operación muy costosa y eso realmente hace que tus pruebas sean más lentas.

Para resolver esto en Playwright, hemos introducido una nueva abstracción. Veamos este fragmento de código para mostrarte cómo funciona. En este fragmento, estoy usando Playwright para lanzar una instancia de WebKit, que es el motor de navegador utilizado en Apple Safari. Ahora, en esta instancia del navegador, estoy creando un nuevo contexto con la API browser.newContext. A pesar del contexto, ahora estoy abriendo mis páginas y realizando interacciones como lo hacía antes. Lo que hemos hecho aquí es crear una nueva capa de abstracción sobre esta instancia del navegador llamada contexto del navegador. Este contexto del navegador puede alojar múltiples páginas web en su interior. Ahora, es muy económico crear contextos de navegador, lo que significa que puedes crear múltiples contextos sin tener que preocuparte por el tiempo que lleva abrir y cerrar un navegador. Esto acelera significativamente tus pruebas.

Ahora, hay algunas propiedades de los contextos de navegador que quiero resaltar. La primera es que los contextos de navegador están completamente aislados entre sí, lo que significa que puedes crear múltiples contextos de navegador, ejecutar pruebas aisladas sin tener que preocuparte de que afecten entre sí. En este fragmento de código en particular, estoy lanzando una instancia de Firefox y luego estoy creando dos contextos en él. El primer contexto es un contexto vacío y el segundo contexto es un contexto con autenticación. En el segundo contexto, estoy agregando cookies específicas. Esto significa que puedo ejecutar mi prueba en dos escenarios diferentes. El primero es sin autenticación, un estado vacío, que es una excelente manera de probar tus sitios web de marketing. El segundo contexto es un contexto con autenticación, lo que significa que puedes probar flujos de trabajo que requieren autenticación. Las cookies en el segundo contexto no afectarán al primer contexto. Esto asegura que si tenemos cientos de pruebas, puedan ejecutarse en entornos concurrentes y aislados a través de los contextos de navegador sin tener que perder tiempo abriendo y cerrando navegadores.

Lo otro interesante que permiten los contextos de navegador es la emulación. Hemos visto cómo puedes usar Playwright para automatizar las pruebas de dispositivos para dispositivos iPhone o iPad. En este ejemplo en particular, estoy lanzando una instancia de WebKit y luego estoy especificando los dos dispositivos que quiero probar, el iPhone 11 y el iPad Pro 11. Cuando creo esta instancia del navegador, puedo crear contextos de navegador en ella. Básicamente, estoy recorriendo los dispositivos a probar y creando un nuevo contexto para cada dispositivo que quiero probar. Una vez que tengo ese contexto del navegador, puedo abrir múltiples páginas en él y navegar a las páginas que deseo. Esto significa que teníamos una instancia del navegador pero pudimos reutilizar esa instancia del navegador en forma de contextos de navegador para poder ejecutar múltiples pruebas en múltiples dispositivos. Los contextos de navegador, por lo tanto, no solo hacen que tus pruebas sean más rápidas, sino que también te brindan muchas más capacidades para poder ejecutar escenarios de emulación, por ejemplo.

Básicamente, así es como Playwright hace que tus pruebas de extremo a extremo sean mucho más rápidas, ¿verdad? A pesar de que los navegadores son lentos, podemos crear una nueva capa de abstracción llamada contextos de navegador que son mucho más rápidos. El contexto del navegador paraleliza la ejecución con una sola instancia, lo que significa que solo necesitas lanzar un navegador pero luego crear entornos de ejecución paralelos. Cada uno de ellos está aislado de los demás y puedes tener varias páginas abiertas dentro de un contexto de navegador. Esto hace que tus pruebas sean significativamente más rápidas y te brinda más capacidades como acabamos de mencionar.

Capaz, confiable y rápido. Estas son básicamente las tres ideas principales detrás de Playwright. Hemos hablado de cómo Playwright permite una automatización capaz sin compromisos, cómo permite una automatización confiable sin tener que preocuparse por la inestabilidad o los tiempos de espera, y cómo permite una ejecución rápida, al igual que tus pruebas unitarias.

Para usar Playwright, simplemente usa npm, la instalación de Playwright puede configurarte con la última versión estable. Cuando instalas Playwright por primera vez, descargará tus navegadores, lo que significa que estás listo para realizar pruebas en múltiples navegadores. Si prefieres usar algo diferente a JavaScript, también puedes usar Playwright en otros lenguajes. Playwright se adapta a tu conjunto de herramientas preferido, lo que significa que puedes usar Playwright en JavaScript, Python, C-Sharp o incluso Java. También puedes usar Playwright con cualquier framework de pruebas y cualquier biblioteca de aserciones y implementarlo en tu entorno CI-CD preferido.

Y finalmente, ya sabes, para obtener más información sobre Playwright, solo para concluir con algunos enlaces interesantes. El primero es nuestro sitio web de documentación en playwright.dev. También nos puedes encontrar en GitHub en la organización de Microsoft bajo el nombre del repositorio Playwright. Y finalmente, puedes unirte a nuestro Slack para interactuar con otros usuarios que están utilizando Playwright para sus pruebas de extremo a extremo y también comunicarte con el equipo de Playwright. Todos estamos en Slack. Muchas gracias por asistir a esta charla.

¡Hola, bienvenido! ¿Estás satisfecho con estos números, el 18% de las personas que dicen que lo van a probar? Sí. Siempre me emociona ver a las personas probar nuevas herramientas. Playwright es algo que lanzamos el año pasado y hemos estado viendo un buen resumen anual con nuestro resumen de estrellas en ascenso y la encuesta sobre el estado de JavaScript. Y es emocionante ver el interés y la emoción en torno a Playwright. Estoy seguro de que solo crecerá y estaremos constantemente rastreando esos números y asegurándonos de satisfacer ese interés con el producto.

Sí, estás hablando de adaptaciones. ¿Puedes compartir algunas ideas, tal vez algunos secretos sobre las empresas que están utilizando Playwright? Sí, lanzamos Playwright como un repositorio de código abierto hace casi un año. De hecho, el 21 de enero del año pasado y lanzamos la versión 1.0 en mayo. Así que hemos estado listos para producción durante aproximadamente siete meses. Y desde entonces hemos tenido miles de desarrolladores y probadores que utilizan Playwright en diferentes lenguajes de programación. Puedes usar Playwright en JavaScript o Python y recientemente también lanzamos soporte para Java. Hay varios equipos internos que están utilizando Playwright. Por ejemplo, el equipo de VS Code está probando todo en Playwright. El equipo de Bing ejecuta alrededor de 40,000 pruebas en Playwright y también hay varios equipos externos que están utilizando Playwright. Adobe es un gran cliente. Tienen varios equipos internos que utilizan Playwright. En cuanto a proyectos de código abierto, la biblioteca material UI es un gran usuario de Playwright. Recientemente actualizamos nuestra página de inicio, así que si vas a Playwright.dev, en realidad muestra los logotipos de los clientes y ese es un buen lugar para ver los nombres importantes que están en el tren de Playwright. Bueno, probablemente después de hoy podremos agregar algunos logotipos en la página de inicio del sitio web.

Quiero hacerte dos preguntas de nuestra audiencia. La primera es de Aaron McAdam. ¿Para qué casos de uso en particular es bueno Playwright en comparación con Cypress? Claro, sí. Sabes que Cypress es una herramienta increíble y estamos muy impresionados con su experiencia de desarrollo. En general, hemos tratado de enfocarnos, al principio, en algunos de los escenarios que Cypress no puede automatizar completamente. Por ejemplo, si quieres ejecutar escenarios de automatización que abarquen diferentes dominios, múltiples páginas, iframes de diferentes dominios, Playwright es muy adecuado para eso. Si quieres tener pruebas que involucren eventos de entrada nativos, como movimientos del mouse o eventos táctiles, algunas de estas capacidades son mucho más fáciles de hacer en Playwright. En general, Playwright tiene muy pocas compensaciones y nuestra propuesta realmente es la automatización sin compromisos, por lo que si tus pruebas requieren herramientas de automatización altamente capaces, Playwright es la herramienta adecuada para ti. Además de la cuestión de las capacidades, Playwright también se enfoca en algunas brechas en el mercado en las que Cypress no se enfoca. Por ejemplo, si prefieres un lenguaje diferente, si tu equipo prefiere usar algo como Python o Java para las pruebas automatizadas, puedes usar eso con Playwright mismo y obtener la mejora de velocidad y confiabilidad que Playwright ofrece en JavaScript.

Entonces, otros lenguajes también son posibles. Incluso el soporte multi-navegador en Playwright es mejor en el sentido de que realmente puedes probar para WebKit, que es el motor de navegador utilizado en Apple Safari. Y notablemente, el soporte de Playwright para WebKit es multiplataforma. Esto significa que realmente puedes usar WebKit testing en Mac OS o en Linux o Windows. Entonces, si tienes una aplicación web móvil, que es utilizada por usuarios en Safari, y tienes un agente de CI/CD en Linux, puedes usar Playwright para ejecutar tus pruebas automatizadas para WebKit. Entonces, mejor soporte de navegadores, mejores enlaces de lenguaje y capacidad, automatización realmente sin compromisos es realmente nuestra propuesta para Cypress. Sí. Muy bueno que también puedas ejecutar este WebKit en una máquina con Windows. Creo que eso realmente ayuda si tienes un gran equipo donde las personas están usando Mac OS y Linux y Windows, por supuesto. Muy poderoso, supongo. La siguiente pregunta es de Danny. ¿Puedes compartir algo sobre tu hoja de ruta para el próximo año? Sí, claro. Creo que lo sorprendente en realidad es que hemos visto mucho impulso increíble durante el último año. Y con cualquier tipo de nueva herramienta, hay toneladas de comentarios de los usuarios, toneladas de problemas en GitHub o mensajes de la comunidad en Slack o simplemente usuarios comprometidos que se unen a las conversaciones con nosotros. Y eso es esencialmente lo que nos ayuda a dar forma a nuestra hoja de ruta para este año. Nuestro enfoque actual se centra en hacer que la experiencia de inicio de la autoría de tus pruebas sea aún más fácil. Y hacer que la depuración de tus pruebas sea más fácil. Entonces, una de las cosas que lanzamos en vista previa el año pasado fue un runner de pruebas, un runner integrado de pruebas para Playwright. Lo que significa que en realidad no necesariamente tienes que usar algo como Mocha o Jest y descubrir esa integración por ti mismo. Con el runner de pruebas integrado, en realidad obtendrás una herramienta completa de pruebas de extremo a extremo que simplificará significativamente la experiencia de inicio. De manera similar, mantener tus pruebas a lo largo del tiempo es obviamente la parte más difícil cuando se trata de pruebas de extremo a extremo y una mejor depuración es algo que muchos de nuestros usuarios han solicitado y algo que siempre hemos querido construir, pero esto es una prioridad para este trimestre. Hemos estado haciendo lanzamientos mensuales. Playwright 1.8 estuvo en vivo la semana pasada. Playwright 1.9 se lanza en febrero y en realidad tiene una increíble interfaz de depuración que realmente te ayudará a mantener tus pruebas a lo largo del tiempo. Entonces, muchas mejoras en la autoría y depuración, realmente, que estarán en vivo durante el próximo trimestre más o menos. Y esa es realmente nuestra prioridad. Entonces, esa es nuestra hoja de ruta para Playwright. Y las personas pueden influir en ella uniéndose a tu servidor de Slack, entiendo. Entonces, Danny, si quieres influir en ella, puedes hacerlo. Sí, sabes, creo que esa es la belleza del software de código abierto, ¿verdad? Quiero decir, problemas en GitHub o Slack, sabes, nuestro desarrollo de productos y hoja de ruta es completamente transparente y siempre estamos buscando comentarios. De acuerdo. Entonces, Danny, si quieres agregar algo a la hoja de ruta, puedes hacerlo tú mismo. Para el resto de las preguntas, Arjun ahora va a ir a su sala de oradores. Y si quieres hablar más con él sobre Playwright, ahora es el momento. Arjun, quiero agradecerte mucho por unirte aquí. Y espero verte de nuevo pronto en el próximo gran evento. Gracias por tenerme aquí.