Evolution of Web Testing Tools

Hola a todos. Espero que estén teniendo una gran conferencia hasta ahora. Mi nombre es Jessica Saxe y gracias por venir a mi charla, los últimos 20 años de pruebas web. Mi objetivo con esta charla era responder a la pregunta que me hacen todo el tiempo, Jessica, ¿por qué tenemos otro test runner? Usé un test runner hace 10 años. Hacía exactamente lo mismo que hacemos ahora. ¿Qué tiene de bueno esta nueva herramienta? ¿Qué estaba mal con lo anterior que usamos? Lo usé. Funcionó. Y la respuesta que tengo para la gente es que nuestras necesidades cambiaron. Y esta charla básicamente explica eso.

Como, ¿qué cambió particularmente, Jessica? Todavía estamos lanzando sitios web. La renderización del lado del servidor era algo en los 90 cuando la gente escribía aplicaciones web en C. No estoy bromeando. Es. Se llama CGI. La interfaz común de puerta de enlace. De todos modos. Entonces, esta charla desglosa la historia de la web en el contexto y lente de las pruebas. ¿Verdad? Entonces, cada error que normalmente tendrías en, como, una charla de historia web de, como, oye, al principio, ya sabes, usábamos C para escribir aplicaciones web. Está la pregunta paralela. Bien. Los escribiste en C. ¿Cómo te aseguraste de que funcionaran antes de enviarlos? Entonces, esta charla tiene una versión muy larga. Dura alrededor de una hora y media, aprendí, porque esta no es la primera vez que grabo esto. No vamos a hacer una hora y media. Vamos a pasar por esto en unos 18 minutos. Y para hacerlo, vamos a dividir la historia de la web en tres partes. ¿Verdad? Entonces, la primera mitad, entre el lo llamo el principio. El principio hasta alrededor de 2007 sería, como, la era del click-through, donde haces clic en cosas, te acercas al escritorio de tu compañero de trabajo y dices, oye, esta es la aplicación web, y ellos dicen, eso se ve genial. Y luego tenemos las dos eras de, como, la guerra de navegadores uno, donde estamos tratando de luchar contra IE y Netscape. Y hay muchas inconsistencias de plataforma en ese lado.

Y luego tenemos la segunda guerra de navegadores. Todos están como, oh, Firefox es genial. Comenzamos con Firefox es genial. {{^}}Y luego terminamos con Microsoft Edge es como, está bien, Chromium. Así que, esas tres eras del desarrollo web son realmente importantes e influyentes. Pero en cuanto a cómo afectan la calidad, podemos resumirlas en que la consistencia de los navegadores era difícil. Y ahora tenemos herramientas de extremo a extremo y laboratorios de automatización de navegadores, como laboratorios de dispositivos, como Sauce, que permiten iniciar navegadores en una VM en algún lugar y hacer clic en cosas. Pero en general, esas inconsistencias de los navegadores ya no nos afectan tanto debido a la consolidación en Chromium.

Así que, eso es, ya sabes, 20 años de historia de la web, como, un poco resumida. Pero ahora, alrededor de 2007 a 2024, las cosas se ponen interesantes en cuanto a las motivaciones de los test runners de navegador y los test runners de node. Así que, eso es en lo que nos vamos a centrar para el resto de esta charla. Así que, cuando me preparé para esta charla, entrevisté a tantas personas como humanamente pude. Publiqué en Twitter. Recibí cientos de respuestas. Envié mensajes, ya sabes, a los escritores y autores de algunos de estos marcos realmente antiguos. Había un test runner del que ni siquiera sabía llamado JS test driver. Fue escrito en Java por Google o en Google por alguien que era, ya sabes, inteligente y googly. Y eso terminó siendo el primer test runner registrado que pude encontrar donde alguien pudo hacer el flujo de trabajo de tener un IDE, iniciar un navegador, y al cambiar un archivo, escribir código y verlo ejecutarse nuevamente. Así que, ese flujo de trabajo de extremo a extremo de como tu código JavaScript se está ejecutando en un navegador después de presionar comando JS. Esa cosa. Eso fue posible alrededor de 2007. Abrió el camino, ideológicamente abrió el camino, para otra herramienta con la que la mayoría de la gente comenzó.

Así que, la mayoría de la gente comenzó a escribir pruebas con Karma o Jasmine o Mocha. Y esas cosas comenzaron alrededor de 2011. Y Karma también fue escrito en Google. Tenía un nombre diferente. Esta es una charla de historia. Así que, voy a hablar sobre algunas de las cosas nerds. El nombre original de Karma era Testacular, el test runner con pelotas. Ese era el nombre oficial.

Y pensé en eliminar esto de la charla tantas veces. Pero lo encuentro tan divertido. Todavía le rinden homenaje en la página de inicio de Karma. Cada vez que ves Karma, el test runner Espectacular, es una especie de broma de vuelta a el nombre, que Google había cambiado después de que la comunidad, a saber, Ryan Florence, dijera, hey, por cierto, ¿crees que tal vez podríamos elegir algo menos juvenil? Porque estoy tratando de que la gente tome en serio las pruebas unitarias y ya estoy teniendo dificultades con eso sin todas sus bromas.

Así que, Karma fue la primera experiencia que la gente tuvo donde un runner basado en node realizaría generalmente el mismo flujo de trabajo que JSTestDriver. Pero era diferente debido a los requisitos de infraestructura, ¿verdad? Ya no necesitas Java en tu máquina de integración continua. Tienes un runner basado en node. Así que, acabas de reducir la complejidad del runner de CI, como, mucho. No necesitas la JVM. Eso es grande. ¿Verdad? Eso es como un gigabyte. Ahora puedes hacer todo lo que necesitas dentro de tu ejecutable de node. Genial. Así que, eso es Karma. Ese es el comienzo de las pruebas y la cultura de pruebas de JavaScript. Y se popularizó porque el equipo de Angular, ya sabes, adoptó Karma y dijo, hey, todos, esto es prueba unitaria de JavaScript. Así es como puedes escribir pruebas en JavaScript. Y eso fue algo enorme.

Fue la primera vez que la gente, los desarrolladores web, pensaron, está bien, tal vez valga la pena escribir pruebas. Porque antes de eso, habían estado en este infierno de matriz de regresión de pruebas manuales tratando de encontrar las versiones correctas de navegadores para probar en qué sistemas operativos y qué peculiaridades de CSS trabajar. No estaban pensando en pruebas unitarias funcionales. Eso simplemente no era algo que la gente hiciera. Porque el costo y la sobrecarga de obtener realmente la aprobación final, esa casilla final para decir, sí, funciona, la mayor parte de ese costo estaba en el proceso de prueba manual. Así que, escribir pruebas unitarias no era útil para Velocity. ¿Verdad? Así que, si fueras a proponer, hey, me gustaría escribir pruebas unitarias antes de 2011 a tu jefe, ¿verdad? Porque es técnicamente posible. Si fueras a hacer esa propuesta antes de 2011, ellos dirían, ¿por qué? ¿Por qué querrías escribir pruebas automatizadas para una característica que vas a tener que probar manualmente en cada navegador? No había un entorno estandarizado que hiciera que las pruebas unitarias realmente mejoraran tu Velocity o realmente la estabilidad de manera significativa.

Pero una vez que Karma llegó, el costo de sobrecarga de configurarlo y probarlo y hacer integración continua no era tan malo. No fue un gran impacto en la Velocidad o productividad. Así que, la gente comenzó a hacerlo. Así que, Karma vivió por mucho tiempo.

Fue el principal test runner hasta Jest. Pero Jest, aunque fue escrito en 2011, era de código cerrado cuando Facebook lo escribió por primera vez. Y fue de código abierto en 2014. Y solo eclipsó a Karma en 2016. Así que, tomó un tiempo para que Jest superara a Karma.

Y entre esos dos runners, y luego, ya sabes, Mocha y Jasmine, todos comenzaron por ahí. ¿Verdad? Así que, los runners basados en node, como Jest, están en su propia era. Y yo marco eso como la creación de JSDOM, que ocurrió aproximadamente, ¿qué fue?

Y JSDOM es como una biblioteca de emulación para que cuando estés en Node, la palabra window no, ya sabes, lance un error cuando la escribas en la consola. Asigna diferentes cosas que esperaríamos que funcionaran en un navegador. Como, no sé, crear un evento o crear un nodo DOM. Esas cosas ahora son posibles si cargas JSDOM en el ámbito del módulo superior.

Entonces, una vez que esa biblioteca de emulación, como, se hizo posible de usar, muchos desarrolladores diferentes comenzaron a escribir test runners. ¿Verdad? Entonces, tuvimos Ava, tuvimos Tape, tuvimos Mocha, y luego, tuvimos Jest de Facebook. Y estos fueron geniales en comparación con Karma. Por el simple hecho de que para que Karma funcionara en CI, necesitabas un navegador. ¿Verdad? Karma era genial si solo lo ejecutabas localmente. Era encantador. Abrías tu navegador, Karma abría tu navegador por ti, y veías las pruebas ejecutarse y decías, esto es genial, puedo depurarlas en el navegador, el mismo entorno en el que tu aplicación va a ejecutarse, puedes depurar tus pruebas. Y eso era súper impresionante. Excepto cuando ibas a ejecutar en CI, no estabas ejecutando en tu navegador en CI, estabas ejecutando en esta cosa llamada Phantom JS.

Y Phantom JS era un navegador sin cabeza escrito en C++. Así que le gustaba fallar todo el tiempo. Era muy quisquilloso en arquitecturas. Y era difícil de depurar localmente cuando había fallos. Tendrías diferencias entre la caja de Linux en la que lo ejecutabas y tu caja OSX o Windows en la que estabas tratando de depurar el problema. Había mucho cambio en el entorno y lo hacía muy difícil de usar. También era más lento. Tendría problemas de reconexión. Era simplemente más lento que la alternativa, que era un test runner basado en node en un DOM emulado basado en node. La estabilidad en Jest y otros runners basados en node superaba con creces el beneficio de trabajar en tu propio entorno de navegador. Y eso es sinceramente una pena. Es una pena que creo que todavía estamos tratando de resolver. Y es por eso que la tercera era de TestRunner, el TestRunner consciente del entorno, espero que resuelva los problemas de emulación basados en node. Así que, hasta ahora, tenemos Karma. Karma es superado por Jest principalmente debido a problemas de estabilidad de PhantomJS.

Pero principalmente debido a la inestabilidad de PhantomJS, Jest se apoderó del mercado. Y Jest fue genial hasta que tuvimos problemas con la carga de módulos y las transformaciones. Y esto fue lo que realmente provocó la siguiente generación de TestRunners que estás viendo en el mercado ahora mismo.

Entonces, ESM, ya sabes, los TLDRs, ESM es por qué la declaración de importación funciona o no en tu base de código o por qué el await de nivel superior funciona o no en tu base de código. Entonces, Jest luchó con obtener soporte ESM durante años. ¿Como, más de cuatro años? Todavía no sé si realmente tiene soporte de módulos. Dejé de buscar. Y esto es como la industria a la que presto atención. Y dejé de buscar.

Entonces, Jest luchó con el soporte ESM y luchó muy, muy fuertemente con la transpilación de archivos que no eran ReactJSX o archivos JSX. Como desarrollador de Vue, siempre luchamos con transformar componentes de archivo único de una manera que fuera similar a producción para el compilador de Vue. Tendríamos que reimplementar el compilador SFC de Vue específicamente para Jest. Y hay otros frameworks como Svelte o Solid u otros frameworks de front end que no se comportan como React o tienen diferentes extensiones de archivo que necesitan diferentes transformaciones. Y Jest requería que reimplementaras tu compilador solo para tu test runner. Solo para ese test runner.

Sabes, si hubiera reutilizado Webpack, genial. Si hubiera reutilizado cualquier cosa que fuera fácil. Fácil de conectar. Eso habría sido genial. Pero cuando Jest fue escrito, Jest fue escrito en una época donde había empaquetadores. Browserify. Grunt. Babel. Webpack. Parcel. Había muchas maneras diferentes en que la gente intentaba cargar código y transformar código. Y entonces, cuando Jest fue creado, creo que simplemente eligieron una opción que no era opinada. Dijeron, elijamos una abstracción. Elijamos una abstracción y sigamos con eso. Y esa fue una gran elección para el momento.

una abstracción y sigamos con eso. Y esa fue una gran elección para el momento. Pero ahora, a medida que realmente estamos añadiendo más y más lógica de negocio y complejidad a nuestros empaquetadores, es más seguro que nuestras pruebas reutilicen esa configuración. Y es aquí cuando los runners conscientes del entorno con V test siendo el niño corona aquí. Con V test siendo el mejor ejemplo, es cuando los runners conscientes del entorno realmente brillan. Es la idea de, oye, ¿y si reutilizamos nuestra configuración de construcción, pero también para nuestras pruebas?

¿No tendría mucho sentido? Y los compiladores y las herramientas de construcción que hacen esto tienen la ventaja de poder soportar muchos entornos de ejecución diferentes también. Entonces, si puedes decir, oye, voy a eventualmente ejecutar esta función en una función edge de Vercel o un entorno de trabajador de Cloudflare, puedes hacer que tu entorno node o tu VM sea tan restringido o tan abierto como desees. Y eso te da el entorno similar al de producción que necesitas. Y supera todos los problemáticos falsos positivos o falsos negativos que podrías obtener si estuvieras en un entorno que estaba un poco desviado. No es exactamente lo que vas a enviar. Si no recuerdas, ya sabes, deshabilitar ciertos métodos de node porque vas a enviar código de navegador a un usuario. Si no recuerdas restringir tu entorno, tu entorno de prueba, podrías accidentalmente enviar código roto.

A menos que lo revisaras manualmente. No puedes confiar en tu entorno de prueba si no está muy cerca de ser como producción. Y Jest y otros runners basados en node que no se conectan a tu sistema de construcción o tu sistema de módulos tienden a promover esa desviación. Y así, a medida que más y más runners de prueba como VTest o como BUNZ test o node test, a medida que más y más de estos runners de prueba conscientes del entorno surgen, creo que promueven una forma más segura de probar y construir tus aplicaciones. Y así, ahora, nos estamos alejando de Jest y otros como separados no tengo una buena palabra para ello. Agnósticos. Son bien intencionados y agnósticos a los entornos que eran de la época. Pero creo que el cambio que estamos haciendo ahora con los runners conscientes del entorno, realmente nos está encontrando donde estamos en cuanto a el hecho de que JavaScript literalmente se ejecuta en todas partes y vamos a transpilar nuestro JavaScript para cualquier número de entornos. Y la persona que mejor sabe o el proceso que mejor sabe sobre eso va a ser la cosa que está compilando.

Y para que esa cosa tenga tanta información como sea posible sobre cómo estructurar un entorno de prueba, creo que esa es la jugada inteligente. Para la arquitectura y el diseño del test runner.

Así que, esa es mi parte. Esa es mi parte sobre los test runners conscientes del entorno y los test runners basados en node. Y en los tiempos anteriores, era, ya sabes, no hablábamos ni siquiera de los test runners de librerías que nadie usaba excepto los chicos de Yahoo UI.

Porque un tiempo comencé la charla diciendo que nadie realmente probaba antes de 2011. Eso es cierto para los desarrolladores de aplicaciones. Pero hay una historia de nicho muy extraña de personas de 2011 y antes que eran como las personas que escribieron jQuery, ¿qué hicieron? Y escribieron pruebas unitarias y eran como las únicas personas que escribían pruebas unitarias de JavaScript. Pero era posible. Era 100% posible. Pero lo he omitido. Lo he omitido por brevedad. Está en las diapositivas.

Si te apetece investigarlo, puedes revisar mi presentación de diapositivas. Tiene mucho más contenido del que puedo incluir en una charla. Pero voy a dejarte con un poco de un ejercicio mental. Así que, hay algo que me gusta hacer de vez en cuando. La premisa de esta charla, ¿verdad?, era si tomas una línea de tiempo, si tomas una línea de tiempo de la historia del desarrollo web y la historia de probar las cosas que se estaban desarrollando, debería haber una pista paralela, ¿verdad?

, de cómo pruebas las cosas que envías? O ¿cómo pruebas antes de enviarlas? Así que, cada avance tecnológico tiene una pregunta paralela de cuáles son las implicaciones para probarlo.