Creando un Test Runner: ¿Qué Sucede Detrás de las Pruebas?

Hola a todos, es un placer estar aquí. Y hoy les mostraré cómo funcionan detrás de escena algunos de los corredores de caché más populares. ¿Y quién es Wesley? Bueno, soy Wesley, encantado de conocerte. ¿Y quién es nuestra elección para la cena? Bueno, elige ambos y elegirás un corredor de caché un poco diferente al habitual.

Entonces, ¿por qué creo un ejecutor de pruebas desde cero? Volvamos en el tiempo primero. Antes teníamos TypeScript y Node, pero ahora el lenguaje involucrado en su ecosistema. Necesitamos entender cómo funcionan nuestras aplicaciones que provienen de Node 8 con BAM, con Gnu, etc. Y ese es un buen ejemplo.

Acabo de verificar si la versión de Gnu es un springy, pero usando solo modelos Gnu y AR, y fallará. Pero, está bien, no necesitas leerlo. Y, pero mira este error. Acabo de instalar un token inesperado. Mira, esta es una prueba realmente simple, y el error es realmente grande. Es porque solo necesita usar una característica experimental de Node.js para ejecutar un archivo de modelo AR.

Mientras que Gnu es un modelo AR por defecto. También sucederá con BAM. Ahora, ejecutemos una prueba que se ejecutará, pero no funcionará exactamente. Una prueba realmente simple de nuevo. En este caso, solo estamos verificando la versión de BAM como un springy. Pero, el error es diferente ahora. Como CommonJS es natural para gestos en este caso, podemos ver una razón diferente ahora. BAM no está definiendo. Ok, pero revisa el comentario aquí.

BAM is calling gestures. How BAM is not defining? Hay dos razones principales para eso. La primera es mishbang. Mishbang funciona como si necesitara definir un CLI para ejecutarse con un binario. Por ejemplo, quiero que mi archivo JS se ejecute con Node.js, e incluso si no llamo a Node.js para ejecutar este archivo. Por ejemplo, el stage.node.nodemodels.gest es una línea en JS, puedo simplemente ejecutar gest. Esta es la magia de Mishbang. Pero, viene con una paradoja.

Y, esta paradoja es como. BAM, gest. BAM, call, gest. Gest, being a, calls Node.js Mishbang. Entonces, ¿qué está realmente mal con esto? Ahora, ese es un ejemplo superficial de cómo gest funciona detrás de escena. Crea un contexto de máquina virtual para aislar la prueba. Entonces, este aislamiento es un problema. Porque, gest de hecho se ejecuta a través de BAM o Dyna.

Pero, cuando pasa la prueba a una VM, no propaga el BAM. Como gest se ejecuta a través de Node.js Mishbang, pierde el contexto en el proceso de aislar la prueba. Trae un conflicto complejo porque gest realmente se está ejecutando con el tiempo de ejecución o lo colorea. Pero, la prueba en sí probablemente se ejecute a través de Node.js. Y, es como, bueno, es como definir la prueba. Entonces, hay algunos conflictos en el modo de procesamiento de pruebas. Entonces, muestro gest porque es realmente popular. Pero, sucede principalmente con todos los proyectos CLI, no solo para ejecutores de pruebas. Y, también sucede con los trabajadores. Entonces, para mí, es un problema real porque mantengo muchos proyectos. Y, realmente quiero que mi proyecto funcione con todos los tiempos de ejecución. Y, quiero asegurarme de que use un interruptor de prueba que se ejecute en todos ellos usando el mismo interruptor de prueba. Y, un punto más.

El gráfico de dependencias es realmente difícil para mí. Solo para usar muchos frameworks. Dependencia, funciona como la dependencia de la dependencia de la dependencia y una y otra vez. Así que, es suficiente. Una de las dependencias de prueba debería romper el comportamiento a través de diferentes tiempos de ejecución. Y, ¿cómo podemos controlar tantas dependencias? Y, es la razón por la que nuestro ejecutor de pruebas aquí necesita ser muy dependiente. Y, dimensionarlo en específico es el tamaño de ambos ahora.

Así que, una motivación más. Honestamente, realmente me gusta esta parte de la filosofía del ejecutor de pruebas. Porque, no se trata de malas implementaciones ni nada de eso. Es más como me gustaría probarlo exactamente como escribo mi código en JavaScript, ya sabes. Pero, mira. Cómo los principiantes ven una prueba, por ejemplo, quiero ver si uno es igual a uno. Pero, primero necesitas configurar tu espacio de trabajo. Tienes que ajustar. Este ejemplo es complejo porque estamos usando una extensión NGIS.

Así que, solo necesitas entender esta extensión. Necesitas deshabilitar muchas cosas para los modelos AS. Y, recordemos. En este ejemplo, soy un desarrollador junior. Y, ¿qué está funcionando? ¿Qué es este gadget de rechazo? Probablemente no sé qué es un rechazo. Así que, una vez que configuro mi espacio de trabajo, finalmente puedo crear mi prueba. Y, eso está bien. Pero, como estoy usando el modelo AS, necesito habilitar la característica experimental de Node para ejecutar. Ves que no es tan simple.

Entonces, un desarrollador viene de las pruebas. Y, sé que es un comportamiento específico de Jest. Mucho tiempo de ejecución es solo instalar y ejecutar. Pero, Jest en este caso está presente en prácticamente todas las empresas en las que trabajo. Y, hagamos una pausa un momento. ¿Cómo funciona el flujo de JavaScript? Simplemente escribimos. Si es una promesa, podemos esperar. Y, finalmente, está hecho. Así que, para mí, es realmente simple. Incluso si soy un desarrollador junior. Pero, eso es algo en mi mente. Si sé JavaScript, sé cómo probar JavaScript, ¿verdad?

Y, no, no lo sé. Porque las pruebas no siguen el mismo flujo de JavaScript. Descripción. Si la capacidad de lanzamiento no se muestra, incluso un problema, es un comportamiento esperado. Pero, para un desarrollador principiante, es confuso. Porque a muchos desarrolladores les lleva años entender cómo funcionan las promesas. Y, incluso las pruebas no funcionan exactamente de la misma manera. En la descripción, tenemos el comportamiento esperado para un desarrollador junior. Y, 1, 2, 3, 4, 5. Pero, en la realidad, será 3, 1, 4, 5, 2.

Y, está bien, hay algo interesante aquí. Console.log 5 debería ser el último. Pero, se ejecutará antes que la prueba misma. Y, es un problema para los usuarios que aún no saben cómo probar. Y, hay una prueba de concepto. Así que, puedes ver que es real y se ejecuta en node 25. Y, como dije, el último paso de la prueba en la diapositiva anterior se ejecuta en el segundo punto. Antes de la prueba. Así que, para las pruebas, necesitamos crear un boilerplate o un hook para indicar explícitamente quién se ejecutará antes y después de la prueba.

Por ejemplo, necesitamos usar un BeforeAllConsoleLogStarted y un AfterAll para un ConsoleLogDone. Y, ahora tenemos dos pruebas asíncronas y funciona como una prueba síncrona. Ahora, puedes ver que para un desarrollador senior es como, está bien, ¿cuál es el problema? Debería ser así, ¿verdad? Bien, sí. Pero, para un desarrollador junior, es como una barrera.

Y, de acuerdo, detengamos el preámbulo por ahora. Espero que te muestre por qué, en la era de la IA, creé un test runner en lugar de un proyecto increíble usando IA. Y, por favor, no es para criticar a ninguno de los test runners aquí. Es para aprender y entender, especialmente mis motivaciones personales, para crear mi propio test runner.

Entonces, ¿cómo crearía mi propio test runner? El primer paso es necesitar ejecutarse en todos los runtimes y necesita aislar el proceso y devolver el código JavaScript natural a la prueba. Y, como un extra, podemos hacerlo sin configuraciones y usar solo matribs de los runtimes. Entonces, ¿cómo podemos ejecutar la misma prueba en todos los runtimes? Veamos cómo funciona cada runtime uno por uno. Y, es interesante porque el motor funciona con TypeScript por defecto. Node funciona con TypeScript después de Node 22 y, en este caso, usaré VSS porque funciona con versiones anteriores de Node.

Una vez que sabemos cómo invocar un archivo usando cada runtime, podemos crear un subproceso, por ejemplo, usando Spawn. De esta manera, podemos usar Node.file.file.genu.run. Y, en las opciones, podemos usar un valor predeterminado para todos. Y, la misma idea para TypeScript, por ejemplo. Y, no ejecutará exactamente una prueba. Ejecutará un archivo JavaScript o TypeScript. ¿Y qué hay del paradoja de CacheBank? Bueno, podemos simplemente usar una lógica realmente básica para obtener un runtime, propagarlo adecuadamente a través de todos los subprocesos. Y, asegurará que cada prueba se ejecute en el mismo runtime que rastrea nuestra ejecución de prueba.

Y, aquí hay un ejemplo del ejecutor de pruebas. Mira, tenemos un archivo.js. Identificamos nuestro runtime, creamos un subproceso basado en quién es el runtime que rastreará nuestra ejecución de prueba. Y, ok, lo entendiste. Y, simplemente, resolvimos nuestro problema con TypeAnd, nuestras VMs, nuestros workers. Node, por ejemplo, usa el enfoque de fork. Es muy similar, pero, en nuestro caso, se adapta mejor porque necesitamos ejecutar en diferentes runtimes. Y, Node siempre se ejecutará usando Node, por ejemplo.

Así que, hablemos de rendimiento ahora. Entonces, podemos encontrar y listar todos nuestros archivos de prueba, crear una concurrencia, entender cuál es el mejor recurso. Por ejemplo, las CPUs disponibles. Elegir una forma en que evitaremos la sobrecarga. Y, además, para cada subproceso que termina, desaparecerá de la memoria. Como puedes ver, esto es antes de usar la forma predeterminada, y esta es la nueva forma con nuestro test runner. Entonces, en este ejemplo, puedes ver el scribe 1, 2, 3, 4, 5. Y, mira, a la derecha, es exactamente como en JavaScript. Y, en un ejemplo real, puedes ver, a la izquierda, un ejemplo de Node. Necesitamos preparar la conexión que usamos antes para crear la conexión. Entonces, después, para finalizar la conexión. Entonces, podemos probar. Y, el assert para Node en este caso, solo se muestra si la prueba falla. Y, para nuestro test runner, es como JavaScript.

Verás, el escriba, conexión, esperar para alcanzar la conexión, nuestra prueba, y esperar al final de la conexión. Y, está hecho. Como puedes ver, nuestro assert muestra el mensaje. Así que, para un usuario realmente principiante, es realmente democrático introducir en la prueba, porque no necesitan aprender muchas curvas, por ejemplo. Solo necesitan entender el assert. Y, Poco usa exactamente la misma manera de usar el assert nativo.

Como puedes ver, incluso con dos líneas, el informe es completo. Y, comenzar no se trata realmente de probar. Se trata de la experiencia del desarrollador, porque cuando vemos algo que podría ser diferente, incluso si es solo para nosotros, probablemente alguien más necesite nuestra solución también. Por eso creo muchos proyectos. Elegir uno es mi favorito.

Pero, en mi mente, la gente odiaría mi proyecto, y lo aman. Así que, aquí te muestro cómo convierto problemas en lo que necesitas para crear algo nuevo, que nuevas personas puedan usar, que tenga un propósito, y tenga una filosofía detrás. Y, es importante porque cuando creamos proyectos complejos, estamos creando sobre aquí. Así que, realmente gracias. Espero que te haya gustado. Por favor, siéntete libre de conectarte conmigo. Adiós.