Frameworks de Pruebas, Frameworks Móviles y los Navegadores Aman a los Desarrolladores y Testers

♪♪♪ Hola a todos. Mi nombre es David. Y hoy voy a hablar sobre testing frameworks, marcos móviles, navegadores, y cómo cada una de las personas que trabajan en ellos aman a los desarrolladores y probadores que utilizan sus productos. La razón por la que sé esto es, como dijo Nathaniel, he estado en la industria durante un tiempo. Pasé casi una década trabajando en Firefox. He estado haciendo automatización de navegadores durante casi dos décadas. Y así que cada vez que veo estas cosas y vengo a estas conferencias y veo lo que la gente está haciendo y mostrando, todo lo que veo es el amor que tienen y quieren mejorar todo. Y quiero que nos importe. Quiero que todos en esta sala digan, en realidad, es agradable ver que les importa.

Y entonces vamos a empezar con algo que creo que es como un árbol. Testing es difícil. Cuando miramos cómo queremos hacer nuestro trabajo, empezamos con testing y decimos, en realidad, ¿sabes qué? Testing es muy, muy difícil. Las personas construyen carreras en torno a ello, ¿verdad? Y aún así dicen, no tengo idea de lo que estoy haciendo. Y está bien.

Y la razón principal por la que testing es tan difícil es que los sistemas contra los que trabajamos son increíblemente complejos. Pensamos en JavaScript. Es un lenguaje asíncrono. Hemos estado haciendo esto. Pero cuando pensamos en testing, pensamos secuencialmente. Queremos ir de este paso a este paso a este paso. Así que hace muchos años cuando empecé mi carrera, había un infierno de callbacks. Y lo intentabas y esperabas que las cosas se ejecutaran en el momento adecuado. El lenguaje ha mejorado y es mucho, mucho mejor. Pero luego tenemos otras cosas que se interponen. Tenemos navegadores. Tenemos web apps. Tenemos todo, desde múltiples capas a través de todo el sistema que tenemos que probar. Y pensamos en cómo lo hacemos y decimos, en realidad, esto es realmente difícil. Pero, hemos tenido como numerosas personas pensando en cómo abordamos estos problemas. Y han intentado simplificarlos a medida que avanzan. Y han surgido con términos bastante geniales como la pirámide de testing, unit testing, pruebas de integración y así sucesivamente. Y voy a desglosarlo. Porque creo que es importante que a veces las palabras importan. A veces no creo que importen tanto.

Y entonces, con el unit testing, esto es donde creo que la gente se obsesiona un poco, pero han intentado desglosar el problema en algo pequeño. Y es una prueba pequeña. Porque a veces la gente no puede hacerlo a nivel unitario. Y tenemos estas pruebas de integración donde probamos nuestros contratos. Y aquí es donde empezamos a ver algo del verdadero amor que la gente tiene.

Obtenemos herramientas como Mocker y cosas así que han crecido, y herramientas más nuevas, VTest, que han surgido para permitir a las personas hacerlo. Testing en JavaScript cuando comencé mi carrera fue mucho de simplemente hacer clic manualmente, asegurándonos de que las cosas funcionaran como lo anticipamos. Y no fue tan fácil.

Y luego tenemos herramientas geniales que están saliendo que nos permiten pensar un poco más grande, pero no tan grande como una prueba de extremo a extremo. Y tenemos esas pruebas de componentes. Hemos visto el mercado explotar con personas tratando de probar sus frameworks de front-end, que son realmente difíciles de probar porque son complejos. Tienen su propia complejidad incorporada.

Y luego tenemos estas pruebas medianas a grandes, como me gusta llamarlas. Y las pruebas medianas a grandes son, al menos estás iniciando un navegador, pero no estás haciendo una prueba completa de extremo a extremo. Y luego tenemos nuestras pruebas de extremo a extremo. Y entonces tiene toda esta complejidad. Y luego lanzas diferentes navegadores, ¿verdad? Solo he mostrado aquí variaciones de Chromium, pero tienes Firefox, tienes Safari, y luego tienes navegadores móviles encima de eso. Y esta complejidad es algo en lo que todos empiezan a pensar, pero cuando se trata del caso de resolverlo, mejorarlo, hacer ese trabajo, es muy difícil. Pero tiene que haber alguien que se preocupe y quiera hacerlo.

Pero tenemos toda esta complejidad. Así que tenemos nuestros frameworks, tenemos navegadores, y a veces los navegadores no son siempre los navegadores que esperamos que sean, ¿verdad? A principios de año, el equipo de Chromium dijo, oh, por cierto, Headless no es lo que crees que es. Headless es un navegador totalmente diferente en Chrome. Así que todas tus pruebas que has estado haciendo, pensando que has estado haciendo lo correcto, tal vez no sea realmente cierto, y lo sentimos por eso. Pero lo arreglamos, ¿verdad? Entonces, lo siento por eso. Así que ahora, no solo tienes variaciones de Chromium, navegador Headless en el que estás pensando, y estás tratando de mejorar tus pruebas, y no está yendo como quieres. Pero esta es una primera señal de que el equipo de Google realmente se preocupa por nosotros. Han visto el problema. Han dicho, en realidad, esto está causando más problemas de los que nos importan. Así que vamos a solucionarlo. Y esta es otra señal de que nuestros desarrolladores nos aman.

Pero luego, pasamos directamente de que nos aman a que nos odian de nuevo. Actualizando cada cuatro a ocho semanas, ¿verdad? Cuando comencé en Mozilla, el año anterior se había lanzado Firefox 3.6, soy tan viejo, y estábamos a seis meses de que se lanzara Firefox 4. Mozilla decidió tener este maravilloso grupo de masterclass donde se reúne toda la empresa. Y en esa etapa, Mozilla era unas 350 personas. Así que éramos pequeños.

Invitaron a un Googler. El Googler dio una charla a toda la empresa, y dijo, por cierto, vamos a estar enviando Chromium, porque Chrome era nuevo en el mercado. Vamos a estar enviando cada 12 semanas. La web no se está moviendo lo suficientemente rápido. Necesitamos que se mueva más rápido. Internet Explorer había renunciado. Y estaban haciendo lo que necesitaban al mínimo indispensable. Firefox estaba creciendo, construyendo cosas. Y luego el equipo de Chromium dijo, sí, necesitamos hacer esto más rápido. Y solo ha ido más rápido desde entonces. Las ocho semanas son normalmente alrededor de la época de Navidad o alrededor del 4 de julio, cuando los equipos de EE. UU. necesitan tomar un descanso, y no quieren estar enviando entonces, porque si algo sale mal, alguien va a tener que trabajar durante los períodos de vacaciones.

Entonces, he hablado un poco del amor de los desarrolladores, los desarrolladores de Chromium, pero ¿dónde está el amor para la testing community? ¿Dónde estamos viendo esas cosas que hacen nuestra vida más fácil, mejor, más rápida, más productiva? ¿Y dónde estamos viendo esos elementos? Y los vemos con las tooling de hoy en día que te permiten, necesito configurar un nuevo proyecto. ¿Cómo lo hago?

Entonces, configurar dispositivos, configurar navegadores, ¿verdad? He estado trabajando en Selenium durante unos 16, 17 años, ¿verdad? De una forma u otra. En ese tiempo, nunca te dimos las tooling para descargar un navegador, configurarlo, principalmente porque asegurarse de que fuera consistente en todas partes era difícil. Y los proyectos de código abierto son en su mayoría dirigidos por voluntarios. Hay algunas excepciones, pero configurarlos era difícil, pero intentamos hacer todo lo demás mientras tanto. Así que, trabajamos con el W3C y conseguimos drivers y estandarizamos todo y los pusimos en su lugar. Y luego conseguimos configurar las dependencias. Estoy seguro de que todos han visto como con el testing de componentes, queremos asegurarnos de que tienes todo lo que necesitas. Pero los frontend frameworks tienen sus propias especialidades. Así que, se trata de descargar esto, descargar esto, sin saber cuándo hacerlo.

Puppeteer comenzó famosamente con esto, en realidad descargaremos el Chromium para ti. Nos aseguraremos de que puedas descargarlo, ejecutarlo en tu primer intento. No podías hacer eso con Selenium, a menos que ya tuvieras un navegador y supieras cómo iniciar ese navegador. Pero había un poco de complejidad allí. Lo hemos visto crecer con Cypress y Playwrights, Nightwatch, JS. Trabajo en eso ahora. WebDriver I-O, todos han dicho en realidad, vamos a configurar todo y mejorarlo. Así que, puede que no te digan que te cuidan, que te quieren, pero sus acciones están empezando a demostrarlo. Y hemos llegado a la etapa en la que podemos mejorar las cosas.

Entonces, en este caso, como MPM y Nets, lo vemos con React y otros proyectos hoy en día, donde puedes simplemente decir, quiero configurar un proyecto. Podrías hacerlo. Entonces, la imagen de la derecha, si no puedes verla, está bien. Pero las últimas tres líneas son como, ¿quieres hacer testing de extremo a extremo? ¿Quieres hacer testing de componentes? ¿Quieres hacer testing de web móvil o de aplicación móvil? Y luego respondes un par de preguntas. Nos dices dónde vamos a ejecutarlo, y lo ejecutamos. Y nos aseguramos de que todo esté en su lugar. Te damos ejemplos de pruebas. Esto se ha convertido ahora en una forma estándar para que los frameworks configuren todo, porque empezar en un espacio de JavaScript es difícil, porque pensamos secuencialmente, y tratamos de hacer todo secuencialmente. Y tratamos de resolver estos problemas en un lenguaje que es asíncrono y no siempre funciona secuencialmente de la manera que queremos. Y así trata de mejorar estas cosas. La otra cosa que se está intentando mejorar a lo largo del espacio es el principio de menor asombro.

O prefiero el principio de menor sorpresa. Entonces, cuando obtienes algo, deberías saber intuitivamente cómo usarlo. Si trabajas en ello, como si vas a un cliente de correo y quieres enviar un correo electrónico, debería ser obvio que hay un botón de redactar o un botón de nuevo correo electrónico, cosas así.

Si estás trabajando en una API, deberías poder hacer esto, punto, hacer aquello, punto, y debería permitirte avanzar si lo deseas de esa manera, o simplemente piensas, creo que esto es lo que necesito. Necesito extraer esta información. Y debería ser intuitivo hacerlo.

Donde algunos frameworks han comenzado a fallar, y esto es principalmente cuando se vuelve a cómo Selenium nunca te permitió descargar y siempre te obligó, otros frameworks decían, lo descargaremos por ti, es que actualizar esos navegadores hoy en día significa que tienes que actualizar su framework, lo que luego puede causar otros problemas, pero no necesariamente porque no te quieran, es que su amor podría mostrarse de una manera diferente. Y así, a veces, actualizar el framework puede romper tus pruebas. Sé que he visto esto antes con los usuarios de Puppeteer. Decían, estoy atascado en una versión muy antigua de Puppeteer porque cada vez que lo actualizo, mis pruebas fallan. Simplemente no puedo manejar eso. No tengo tiempo para arreglar mis pruebas. Y así deberías poder, a través de tus tooling, lo que sea, poder actualizar pequeñas partes, tener la confianza y seguir adelante.

Y esto es donde, más o menos, es un poco un caballo de batalla mío en este momento. Los motores de navegadores no son iguales a los navegadores. Si piensas en la diapositiva de Chromium de antes, teníamos seis versiones diferentes de Chromium allí, ¿verdad? Si hablo con Brendan Eich, quien es el CEO de Brave, él te dirá una o dos cosas que son iguales a Google Chrome o Chromium, pero Brave es único. Lo mismo con Opera, Vivaldi, Edge, ¿verdad? Todos toman sus cosas diferentes. Entonces, ¿cómo resolvemos esto? Entonces, en el espacio de Selenium, en el que paso mucho tiempo, tenemos herramientas como Selenium Manager. Así es como el proyecto Selenium intenta mostrarte que les importa, es que quieres actualizar tus controladores para Chrome porque Chrome driver tiene que usar el protocolo de depuración de Chrome, que cambia con cada versión de Chrome. Y necesitas actualizar eso. ¿Qué tal si simplemente eliminamos ese dolor, lo resolvemos por ti? La otra cosa que la gente tiene, que estábamos viendo, es que, como, el equipo de Puppeteer se estaba frustrando con la forma en que la gente estaba planteando problemas. Este error está ocurriendo con Puppeteer en Chromium. Y ellos dirían, bueno, no puedo reproducir esto en Chrome. Y entonces lo que hicieron, el equipo de Chromium, fue que crearon Chrome para Pruebas. Y Chrome para Pruebas es para evitar que uses Chromium en tu entorno de pruebas porque no está destinado a ser utilizado como un navegador de pruebas porque no hay forma de ir desde tengo este error y rastrearlo hasta el commit que causó ese error. Porque las cosas están cambiando tan rápido en esa base de código que es bueno tener una forma estándar de hacerlo. Entonces, Puppeteer, Selenium, cosas así, lo usan. Y ha surgido a través de la colaboración, mejorando lo que queremos, que la gente empiece a preocuparse. Y luego viene el otro lado de eso, ¿verdad? Encoger escritorios no es móvil. Es un poco controvertido para algunas personas, pero es cierto. Y la razón principal es cómo los sistemas operativos renderizan las páginas web. Se vuelven complejas, cosas así. Si pasas algún tiempo con un desarrollador de Chromium que está trabajando en Android, o un ingeniero de Firefox trabajando en Android, o un ingeniero de Safari trabajando en iOS, puede ser difícil. Pero la forma en que los frameworks están empezando a mostrar a la gente que se preocupan y te quieren es que vemos este problema difícil, lo configuraremos por ti. Entonces, uno de los proyectos en los que trabajo, Nightwatch.js, configura simuladores y emuladores por ti si quieres hacer pruebas en móvil. Y no depende de Appium para hacer cosas si te importa solo la web. Porque Chrome driver, Gecko driver, Safari driver, funcionan bien con los navegadores móviles. Entonces, usemos navegadores móviles. Te daré una cosa, escalar en móvil es difícil. Pero escalar en navegadores de escritorio también es difícil, solo de una manera ligeramente diferente. Quizás de una manera menos costosa, pero sigue siendo difícil. Y entonces la gente te está dando su amor y te está dando los frameworks y las herramientas. Y todo esto es gratis hoy en día, gracias al código abierto.

Creo que una de las cosas que sería increíble para las personas en esto, alrededor del mundo, es compartir sus ideas de características. Creo que me gustaría esto o aquello. Estos son los puntos de dolor que tengo regularmente con tu framework. Hay mucho ruido que viene en muchos frameworks y proyectos. Pero cuando hay alguien diciendo, oye, me encanta esta idea, ¿podrías ayudarme a hacerla? Estoy bastante seguro de que cada proyecto que usas estaría dispuesto a ayudar. Así que comparte tus ideas, porque compartir tus ideas es mostrar tu amor a cambio.

Y con eso, he llegado al final de mi charla. Gracias a todos. Así que sí. Uno de los beneficios de ser un MC es que puedo hacer una pregunta primero. Una pregunta que me he estado preguntando es, como dijiste, has estado en, especialmente en la automation de navegadores durante más de 20 años, ¿verdad? Así que has estado aquí por un tiempo. Has visto llegar muchos barcos. Has visto irse a muchos barcos. ¿Hay algún barco que veas que simplemente entra en la estación, sale de la estación, luego vuelve a dar la vuelta, que tal vez deberíamos empezar a poner en su lugar permanentemente?

Yo, no realmente. Creo que lo interesante que está sucediendo es que el espacio de JavaScript parece muy voluble a veces, ¿verdad? Y, pero cuando lo miras, algunas de las cosas que siempre están ahí, la vieja guardia, todavía están ahí. Simplemente podrían no obtener la publicidad que obtenían, digamos, hace cinco, 10 años. Y así como si solo fueras por puro sentimiento, la gente te dirá que, oh, Cyprus y Playwrights están creciendo y están haciendo esto. Están creciendo y son herramientas fantásticas, ¿verdad? Pero al mismo tiempo como los viejos guardias, Lenium, cosas así, todavía están creciendo como un 25% trimestre a trimestre, ¿verdad? Y así que no veo cosas así. Las cosas que he visto son cómo las personas abordan el problema. Entonces a veces era como, oh, podemos simplemente inyectar JavaScript en la página. Eso será bueno. Y comenzamos con eso originalmente con Lenium y nos alejamos de eso. Cyprus luego lo trajo de vuelta. Y así causa algunos problemas, pero no. Pero es la singularidad de la web, siempre hay algo avanzando, no necesariamente dando vueltas en círculo. Sí, totalmente. Siempre avanzando, me gusta.

Bueno, tenemos un par de preguntas entrantes. La primera pregunta es sobre un framework diferente. Entonces, ¿qué crees que es diferente en el enfoque del equipo de Nightwatch en comparación con otros frameworks de front end end-to-end como Cyprus o Playwright? Esta es una adición atrevida a la pregunta.

¿Por qué es mejor? Entonces, la forma en que Nightwatch y WebDriver son filosofías centrales, estar donde está tu usuario, ¿verdad? Entonces, si vas a hacer pruebas, haz pruebas de componentes, asegúrate de que esté en un navegador, no usando jsdom, porque eso en realidad causa otros problemas. Y es como ese problema de Chromium versus Chrome que puede surgir y tienes estas diferencias.

Lo que creo que es como Nightwatch es, personalmente, creo que Nightwatch es mejor que Cyprus porque Cyprus usa como, la forma en que habla con el navegador está usando tecnología más antigua como Selenium RC. Y si escribes cualquier JavaScript en una página, estás limitado por el sandbox en el navegador porque es un sistema de security, ¿verdad? Está tratando de mantener a todos a salvo y no está diseñado necesariamente para automation donde la forma en que Nightwatch y Playwright lo hacen es que habla a través del backend del navegador y dice, oye, ¿puedes manipular estas cosas para nosotros? Y entonces es más realista. Y en ese caso, creo que es realmente bueno. Creo que hay muchas similitudes entre Playwright y Nightwatch y especialmente con el trabajo que se está realizando en el W3C para WebDriver Bidi para estandarizar algunas de esas ideas básicas para que Mindwatch pueda mejorar a medida que avanza y sea estándar. Sí, gracias. Gracias. Esa fue una muy buena pregunta y una gran respuesta. Tenemos otra y esto está relacionado con algo de lo que hablaste sobre el navegador. Entonces, ¿esta prueba reemplazó las pruebas del navegador? Entonces, si no, ¿por qué probamos headless ya que ningún usuario final va a estar en headless? Si es así, entonces, ¿por qué hacer pruebas cruzadas de navegador? No estoy seguro de entender bien, pero también puedes leerlo allí a la derecha. Vale. ¿Puede headless reemplazar? No, no creo que pueda. He estado en el campamento que intentaba decirle a la gente cuando la gente se movía a headless, lo mismo con Richard Bradshaw del Ministerio de Pruebas o ex-Ministerio de Pruebas fue que headless no es donde están tus usuarios. Es genial si estás desarrollando localmente y no quieres ver navegadores apareciendo todo el tiempo, ¿verdad? Eso puede ser molesto. Y entonces está bien. Pero en el momento en que entra en tu tubería de CI CD debería estar donde están tus usuarios, los mismos navegadores, lo que sea. Y tienes una matriz y simplemente construyes y pruebas a través de ella. Y deberías hacer eso tanto como sea posible para que puedas atrapar errores, ¿verdad? Entonces, como mi error favorito de motor de navegador versus navegador fue uno donde hace un par de años, IndexedDB estaba roto en Safari, ¿verdad? Realmente, realmente roto.

Pero si estuvieras testing y como Playwright con WebKit, nunca te encontrarías con ese error porque WebKit no lo tenía, ¿verdad? Y entonces iOS Safari tampoco lo tenía. Pero solo estaba en el escritorio, ¿verdad? Y entonces tenías este extraño error que tu CI CD habría estado pasando. Y esto va en contra de mí, el principio de la menor sorpresa o menor asombro, ¿verdad? Como que no deberías estar obteniendo sorpresas así. Y no hay forma de rastrearlo.

Entonces, uso navegadores con cabeza tanto como sea posible, pero entiendo que hay compensaciones, ¿verdad? Entonces. No, totalmente, sí. Y me encanta el camino de la menor sorpresa. Lo usaré de nuevo. En el futuro. Y estamos trabajando en navegadores y alguien pregunta, especialmente con la forma en que funciona la web, como, vamos a tener solicitudes del servidor. Entonces, ¿deberíamos tener solicitudes simuladas de un servidor o no? ¿Y por qué? Creo que la pirámide de testing aquí entra muy rápido. Como cuando tienes tus pruebas de extremo a extremo, no uses simulacros, pero si estás haciendo pruebas de componentes, haz simulacros, ¿verdad? Como poner todo adentro. Haz esas pruebas lo más rápido posible porque realmente quieres fallar lo más rápido posible, ¿verdad? Como ThoughtWorks hace décadas, cuando sacaron sus CI, las tuberías, decían que, sí, las compilaciones no deberían tardar más de 10 minutos porque la gente se distrae, ¿verdad? Como los teléfonos móviles hoy en día, la gente dice, oh sí, estaba bien construyendo, hagamos esto. Y es como, oh espera, he perdido una hora, ¿verdad? Como tener esos ciclos de retroalimentación rápida definitivamente tienen simulacros y luego, pero es un equilibrio. No lo hagas en todas partes. No, totalmente.

Muy bien, tenemos tiempo para una última pregunta rápida, que es especialmente sobre la prueba del tiempo. ¿Crees que Chrome para testing pasará la prueba del tiempo? ¿No es mejor estar donde está tu usuario, que en mi opinión es el punto de tu charla, ¿verdad? Sí, creo que va a resistir la prueba del tiempo, ¿verdad? Como cuando se trata de testing, necesitamos, estoy tratando de pensar en la palabra correcta aquí. Necesitamos asegurarnos de que nuestras pruebas son deterministas. Esa es la palabra que estaba tratando de pensar, ¿verdad? Chrome para testing permite el determinismo, pero todavía puedes, va a ser el mismo Chrome que se envía, pero tienen, han sacado el actualizador automático y entonces estás usando lo que tus usuarios son y ahora no tienes las actualizaciones automáticas, pero luego herramientas como Puppeteer, Selenium Manager, cosas así, deberían estar actualizando esas a medida que avanzan. Entonces estás manteniendo donde están tus usuarios, pero también tienes un navegador determinista en tu sistema. Ahora, totalmente. Muy bien, no tenemos tiempo para más preguntas. Sin embargo, podrás encontrar a David durante todo el día. Y también estará en la sala de discusión de los oradores más tarde. Así que definitivamente acércate y saluda y haz cualquier otra pregunta que tengas. Pero démosle una ronda más de aplausos. Gracias. ♪♪♪