Cenizas a Cenizas, Especificación a Especificación: El Renacimiento de las Pruebas Modernas

Nos hemos reunido hoy, mañana, gracias. Lo siento. Así que nos hemos reunido hoy para montar la partida de Mocha, Jest y Karma. ¿Quién sabía sobre Karma? Nadie. Una vida tan corta. Mocha, amábamos tu minimalismo, pero necesitabas algo de fontanería para conectar otras herramientas.

Luego vino Karma. Karma. Querido, dulce Karma. Hiciste lo mejor para traer simetría entre las pruebas y la producción ejecutando pruebas en el navegador, pero seguías esperando que el navegador se volviera a conectar, y nunca llegaste más allá de la Comunidad Angular. Luego vino el niño dorado, el salvador, Jest. ¿Quién ha oído hablar de Jest? Sí. Bueno, nos prometiste cero configuración, bromista. Nos empujaste a las pruebas de instantáneas. Nos encantan tus bromas. Jest, luego vino la gran migración. ¿Recuerdas la gran migración? Módulos ECMAScript.

Todos nos subimos al barco con Vite y otras herramientas, y te dejamos varado en el desierto de CommonJS. Así que estamos aquí para montar, pero también para celebrar Vitest como el marco de pruebas más descargado y utilizado. Y no es gracias a mí. Bueno, un agradecimiento especial al equipo V, así que equipo voz cero, que ahora es Cloudflare. De todos modos, gracias a todos los involucrados en Vitest, por cierto. Así que pueden darles un aplauso. Y eso es todo. Gracias. Bien. Entonces, ¿también tiré mi clicker? Oh, no. Así que las pruebas no tienen que ser dramáticas. Aunque hay una pregunta hoy, ¿todavía necesitamos pruebas? Tal vez. Bueno, podemos hablar sobre eso.

Y puede ser incluso el pilar de tu estrategia de desarrollo asistido por IA. Y no es mi tema hoy, lamentablemente. Hoy solo nos estamos enfocando en Vitest y algunas otras herramientas.

De todos modos, mi nombre es Yunus. Uso Internet y redes sociales, así que tengo cuentas allí y publico cosas allí, para que puedas seguirme. Tengo un canal de YouTube donde comparto algunas de mis experiencias y cosas y recetas. Y vivo en Lyon, en Francia. ¿Hay gente de Francia aquí? Sí. Siempre juntos. Todo el día, todo el día. Bien, bueno.

Y soy un cocinero de software. Y me encanta describir nuestro trabajo como cocineros de software porque siempre estamos tratando de encontrar los ingredientes adecuados. Y la gente dice, oh, realmente deberías probar esto. Deberías poner esta especia en todas partes. Como, no, tal vez eso sea demasiado. Así que un poco de IA aquí, tal vez demasiado. Un poco de ese marco de pruebas, tal vez demasiado, etcétera.

Así que tienes que encontrar el equilibrio adecuado. Y entre los ingredientes que más me gustan, bueno, es raro decirlo aquí, pero está Angular, como mencionaste, y NX. Y resulta que soy un GDE y campeón de NX, lo cual es más como si estuviéramos construyendo el enlace entre estas herramientas y la comunidad. Y por cierto, ¿quién está usando NX aquí? Oh, bien, bien, bien. Cuéntales a tus amigos sobre ello porque es realmente genial. Y estaré en el stand allí. ¿Cómo lo llamas? Como la caja de preguntas y respuestas está allí. Así que si tienes alguna pregunta sobre NX, estaré encantado de hablar sobre ello. No es solo una herramienta de repositorio moderno, sino que es más como lo llamo un compañero de construcción, ya sabes, en tu cocina.

Y para ganarme la vida, doy entrenamientos y coaching, y entreno a equipos para mejorar como el flujo de trabajo de desarrollo y la estrategia de pruebas y la arquitectura, etcétera. Y trato de hacer todas estas cosas lo menos aburridas posible porque el software no siempre es emocionante. Y mi empresa es Marmcode. Y encontrarás mis masterclasses y más sobre mis ofertas de coaching allí. Pero ese es otro tema.

Así que hoy lo que quiero hacer es buscar recetas y filtrarlas, y luego la aplicación muestra las recetas. Eso es todo. Y quiero probar esta cosa. Y estoy ejecutando mi prueba con Jest. ¿Quién está usando Jest hoy? ¿Y quién está usando VTest? Bien, bien. Así que vamos a cocinar. Solo necesito mi delantal. Ya sabes, codificar siempre se ensucia. Nunca se sabe. Va a funcionar. Bien, necesito un ID aquí. Aquí vamos. Así que aquí tengo como un espacio de trabajo. Tengo mi aplicación aquí, y tengo mis pruebas que están escritas allí. Y solo intentaré ejecutarlas. Y estoy usando, está en modo.

Está bien. Y estoy usando PMPM test que ejecutará pruebas de NX, que ejecutará VTest, no importa. Y ejecutaré mis pruebas así. Uh-oh. La prueba no está pasando. Oh, no, no lo hice. Oh, está bien. Así que mis pruebas todavía están usando Jest, y no migré. Oh, Dios. ¿Me llamaste? ¿Por qué no usas un codemod? Toma unos minutos migrar la mayoría de tus pruebas. ¿Por qué no? Buena idea. Pero antes de migrar Jest a VTest, una solución.

¿Hay personas que están usando Jest que quieren migrar a VTest y simplemente no tienen el tiempo o los tokens para eso? Entonces, bueno, sobre los tokens, también es otro tema porque las pruebas para mí son como el pilar, la fuente de la verdad. Así que es algo que quiero revisar más a fondo que cualquier otra cosa. Y seré muy cuidadoso con solo algo que migra miles de pruebas. Así que un buen paso es si estás en esta situación de migración, aquí tengo mi configuración de Jest, y solo filtraré las pruebas que se llaman Jest.

Y renombraré las pruebas que están rotas porque usan APIs específicas de Jest. Voy a renombrar esta. Creo que esta también está rota. Y esta también. Y eso es todo. Y aquí puedo simplemente ejecutar Jest para mis antiguas pruebas de Jest, y puedo ejecutar VTest para mis nuevas pruebas. Así que eso es solo un pequeño consejo. No tienes que hacer un gran cambio. No tienes que migrar inmediatamente. Puedes migrar progresivamente. Ahora, sobre el modo de código, otro enfoque que se nos dio es simplemente ejecutar este modo de código real, pero aún funciona. Y migrará muchas cosas de Jest a VTest. Porque una cosa afortunada es que el equipo de VTest lo hizo fácil al intentar imitar la API de Jest tanto como sea posible para que la migración sea sencilla. Y ahora ejecutemos las pruebas.

Oh, no. Está bien. Ahora está pasando. Lo siento por eso. Y ahora estamos contentos con esto. ¿Y sabes por qué? Tengo algunas pruebas aquí que fueron migradas como esta. Y uno de los cambios es que estaba usando temporizadores falsos para simular el tiempo. Y cambió de Jest a VTest. Así que algunas migraciones son fáciles como esta.

Pero, ¿cómo crees que esta prueba aquí, la especificación de búsqueda de recetas, sobrevivió? Es una prueba que prueba toda la página de búsqueda, pero sin llamar al backend. ¿Cómo pude tener el mismo código que funciona con Jest y VTest y aún estar simulando cosas? Bueno, funciona. Porque aquí, lo que estoy haciendo es que siempre estoy sobrescribiendo lo que uses, contactos de React o lo que sea que uses, como un sistema de inyección de dependencias o incluso un sistema de singleton, tan simple como este.

Solo estoy sobrescribiendo mi capa de abstracción que realiza las llamadas a la API o lo que sea que esté haciendo bajo el capó. No lo sé. No me importa. ¿Es GraphQL, HTTP? No importa. Lo estoy reemplazando con una implementación diferente, que es una falsificación. Y recomiendo mucho este patrón. No tengo tiempo para profundizar realmente en esto. Pero no involucra nada específico del framework. Es solo como otra implementación que imita el comportamiento, no solo la API, no solo la estructura.

¿Cuántas veces pasas depurando mocks donde tienes como toda una respuesta allí en una carpeta de fixtures y está rota y tienes que actualizarla? Y otro patrón aquí es que para evitar el aburrimiento de crear datos o dejar que los agentes generen datos estúpidos como este que no son consistentes o no tienen sentido, etcétera, estoy usando object mothers, que son un patrón, un patrón muy antiguo, que te ayuda a construir cualquier tipo de objetos para tus modelos pero de una manera significativa. Así que las pruebas son legibles y no están desordenadas y son fáciles de mantener. Así que eso ayuda mucho. Así que este es el tipo de patrones que ayudan. Y ahora la cosa es que tengo mis pruebas ejecutándose en VTest, nada cambió. Están pasando.

Está bien. Y uno de los mayores problemas es ¿qué pasa si tengo un error o algo? ¿Cómo depuro? Así que usualmente aquí estoy usando testing library, por ejemplo, React testing library. Así que un enfoque es hacer esto. Y luego ejecutas tu prueba. Y este es el resultado. Pero no soy un analizador de HTML. No sé si tienes, hay algunos aquí. Pero no soy bueno analizando HTML, así que no es muy útil para mí. Y entonces podrías haber notado los pequeños cuadrados verdes.

Es en realidad una herramienta llamada Wallaby JS. Es increíble porque funciona con VTest, con otras herramientas. Y no es gratis excepto para open source. Pero puedes depurar cualquier valor que tengas donde quieras. Así que, por ejemplo, si estoy aquí y puedo simplemente decir cuál es el valor de los datos aquí. Lo siento. ¿Cuál es el valor de los datos? Y puedes verlo inmediatamente aquí. Y puedes navegarlo. Y es en vivo. Así que ayuda mucho. También puedes decir, oh, ¿qué hay en el filtro?

Entonces puedes, por supuesto, controlar en qué prueba enfocarte para que no te distraiga el ruido de todo lo demás. Y puedes depurarlo así y ver qué está pasando. Oh, no filtré. Filtré una prueba que no pasa por esto. No es la correcta. De todos modos, bueno, aquí tienes.

Así que tienes el estado. Y puedes revisar los datos. Y estás haciendo un trabajo realmente excelente. Y no están hablando mucho sobre su herramienta, pero es realmente genial. De todos modos, entonces, pero el problema es ¿qué pasa si es un problema de UI? ¿Cómo depuro eso?

Así que ese es uno de los problemas. Así que tal vez si ejecuto la prueba en el navegador, eso ayudará. Bueno, con VTest, una de las características asombrosas es que tienes diferentes proyectos. Puedes configurar diferentes proyectos y tener diferentes configuraciones para diferentes archivos. Por ejemplo, aquí estoy usando archivos que se llaman browser.spec que se ejecutan en el navegador.

Por ejemplo, aquí estoy usando archivos que se llaman browser.spec que se ejecutan en el navegador. Archivos que se llaman y.spec, estos son como pruebas de integración que llaman al backend. Tienen diferentes extensiones. Y tienen diferentes configuraciones. Algunos de ellos se ejecutan en el navegador. Algunos de ellos se ejecutan en Node.js. Algunos de ellos se ejecutarán con un tiempo de espera diferente.

Así que ahora solo tengo que renombrar esta prueba a browser.spec.ts. Lo siento. Si lo ejecuto así, no va a aparecer porque es sin cabeza. Y ahora puedo ver mi prueba ejecutándose en el navegador. Puedo incluso ejecutarlas de nuevo. Genial. Y puedo interactuar con ella y puedo depurar más, lo que sea. Así que eso es bastante bueno.

Bien. Y el teléfono. ¿Es tuyo? ¿No? Lo siento. Está bien. Lo siento. Sí. ¿Qué? ¿No me queda mucho tiempo? Bien. No importa. Entonces, ¿qué quieres? ¿Nadie puede agregar recetas hoy? ¿Qué? Las pruebas están pasando. Hay como, no sé, como 100 personas o más que pueden – ¿puedes – las pruebas están pasando. Puedes verlas pasar, ¿verdad? Sí. Ella no te escucha. Es mi gerente. ¿Ves? ¿Pero nadie compró ninguna receta hoy? Bien. Me encargaré de esto.

Así que vamos a depurar esto. Hay – creo que pusieron el banco. Está en Ashes React 3. El error está aquí. Y tienen una reproducción, así que voy a intentar ejecutar la prueba de nuevo. Y la prueba sigue pasando. No sé qué hacer.

Así que una cosa que he observado es que aquí, para hacer clic en los botones, estoy usando testing library user events. ¿De acuerdo? Pero puede que hayas notado que hay un user event de VTest browser. ¿Quién sabe la diferencia? Solo para saber si soy útil. Bien. Bueno.

Así que es la misma API. Nada ha cambiado. Voy a ejecutar la prueba de nuevo. Y – oh, la prueba está fallando. Clásico. ¿Quién eres tú? Soy el otro. Escúchame. Solo desactiva la prueba. No escuches estos susurros. En la tierra de VTest, las pruebas tienen ojos. Ven lo que los usuarios ven. Tocan lo que los usuarios tocan. Y lo que está roto no puede esconderse.

¿Por qué siempre tiene que ser críptico? Bien. Así que, de hecho, lo que está sucediendo aquí es que VTest está utilizando Playwright en segundo plano para interactuar con la UI. Entonces, Playwright tiene verificaciones de accionabilidad porque está utilizando los protocolos de Chrome DevTools para controlar el navegador. Y por lo tanto, tengo un error porque el botón siguiente está oculto porque han cambiado el CSS.

Así que cada vez que intenta hacer clic en el botón de añadir, en realidad está haciendo clic en la imagen de la ensalada. Lo que me ayudará tal vez es esta nueva función que aún no está aquí, que es TraceView. Probablemente vendrá en VTest 5 porque está en beta ahora mismo. TraceView. Voy a ejecutar la prueba de nuevo. Y mira esto. Puedo ver el rastro de la prueba aquí. Y veo que cuando está haciendo clic, ¿puedes ver el botón?

Así que realmente está capturando problemas de CSS y de diseño, que son problemas que ocurren. Y esto es solo porque en algunos componentes compartidos en mi biblioteca de UI que usé en toda mi organización, tengo un problema de CSS aquí. Porque alguien añadió este odio a este objeto, a la tarjeta. Y ahora si ejecuto mi prueba de nuevo. Oh, espera un segundo. Hmm. ¿Es el rastro? No lo sé. De todos modos. Así que ahora está pasando. Y ahora la receta está ahí. Así que es capaz de hacer clic y puedo ver que realmente hace clic en el botón correcto. Pero sí, no es sorpresa que esté en beta, ¿verdad? Así que puedes ver que está haciendo clic allí. Oh, interesante. Está en beta. Y lo que trae otro tema. Me pregunto si podrías ejecutar tus pruebas, la misma prueba, pero en Playwright. ¿De acuerdo? Así que aquí, esto es algo que estoy construyendo con un amigo. Se llama test or not. Y simplemente llamas lo que quieras.

Como renderizas un componente así. Y esto es solo play write. Y luego he terminado. Así que mi prueba es que mi componente está realmente montado aquí. Y luego puedo pedirle a un agente que termine la prueba. O puedo usar el record at cursor y decir, está bien, quiero hacer clic en el botón de añadir. Y quiero, no sé, escribir aquí o algo. Y puedo hacer afirmaciones. Oh, lo siento. Y puedo ver mis pruebas ejecutándose aquí. Y la prueba está ejecutándose. No hice ninguna afirmación. Y puedo hacer afirmaciones en el DOM.

Incluso puedo hacer afirmaciones en, adivina qué. Puedo llamar lo que quiera en el navegador. Así que puedo decir, voy a seleccionar las recetas de mi tienda RTK. Y aquí tengo las recetas. Y estoy comprobando que la primera receta tiene un nombre burger. O hay una receta con un nombre burger. Y miraré. Y mi prueba está pasando. Y tienes todas las bondades de play write donde cada vez que seleccionas algún selector como este, y te preguntas si es la forma correcta de hacer clic o no.

Y puedes probar cosas como, está bien, ¿esto funciona? Oh, no, no es el botón correcto. Vamos a elegir el primero. Oh, ahora está eligiendo el único. Así que eso es bastante genial. Y esto es Testronauts. Y eso es todo. Así que solo tengo que encontrar mi pequeña diapositiva. Y, lo siento, solo quería hacer.

Y una última cosa. Oh, lo siento. No. Modo de pánico. De todos modos. Delantal. Está bien. Así es como funciona. Como dije, tienes como toda la magia porque VTest está usando realmente solo el motor de automatización de Playwrights para controlar el navegador. Así que por eso es capaz de hacer realmente las afirmaciones. Oh, no. Lo siento por eso. Bien, bueno. Así que obtienes esta es la interacción. Tus pruebas están ejecutándose en el navegador. Y cada vez que haces clic, pasará por VTest y VTest controlará Playwrights e interactuará con tu navegador y tendrá todas las afirmaciones. Y si quieres probar, puedes intentar Testronaut. No ahora mismo porque todavía tenemos un pequeño problema que solucionar para React. Y estará aquí muy pronto. Así que es toda magia. Y solo dale una oportunidad. Y eso es todo. Puedes encontrar las diapositivas y también un formulario de retroalimentación sobre cuáles son tus desafíos con las pruebas y el desarrollo asistido por IA. Y puedes ganar una licencia para Wallaby si tienes curiosidad al respecto. Así que solo pon tu correo electrónico allí. Puedes encontrar las diapositivas. Mi libro de cocina gratuito sobre pruebas y NX. Y mi masterclass. Y hay un early bird, pero ese no es el precio correcto. Está bien.

Ahora estamos bien. Muchas gracias. Gracias. Fue una gran charla. No solo una gran charla, los props. Es tan divertido porque hice la broma sobre el enterrador y la música. Realmente no tenía idea de que iba a comenzar con eso. ¿Podemos darle un aplauso más? Realmente disfruté eso. Gracias. Gracias.

Muy bien. Tenemos un montón de preguntas. En primer lugar, hubo muchas cosas realmente, realmente buenas que mostraste, tantas herramientas que la gente quiere tener en sus manos. Y realmente pasaremos por tantas como podamos en el corto tiempo que tenemos. Así que la primera pregunta es, ¿hay una manera fácil de ver las diferencias de cobertura de pruebas con VTest para que puedas medir el impacto de los cambios en la cobertura? Entonces, cuando estás cambiando. Sí. Entonces, quieres decir que esa es una muy buena pregunta. No sé para el diff, no estoy seguro. Como en tu PR, no estoy seguro de eso. Es por otra cosa. Creo que estamos obsesionados con la cobertura de código y deberíamos estar más enfocados en la cobertura funcional, lo que trae otro tema más largo. Y la cobertura de código puede ser complicada, especialmente cuando involucras agentes en eso y dices, oh, por favor, dame un 100% de cobertura. Lo lograrán, pero no va a ser muy útil. Pero lo revisaré y solo envíame un correo electrónico o llena el formulario y haz la pregunta para que sepa quién eres y pueda mostrarte cómo hacerlo. Porque anteriormente estaba usando una herramienta y no puedo recordar su nombre, porque hay herramientas para eso. Pero con VTest, no sé si hay el sistema de diff. Justo. Y sé que hay tantas cosas donde la respuesta va a ser, depende, o querrás hacer un seguimiento, así que recuerda que después puedes ir a verlo en el bloque de preguntas y respuestas afuera en el pequeño, no sé, ¿cómo lo llamaste? La pequeña sala de ladrillos. La pequeña caja. Incluso si te unes en línea, habrá una laptop con Zoom para que el orador pueda unirse y responder esas preguntas también.

Entonces alguien preguntó, como mostraste con React, con una página web, ¿alguna idea sobre bibliotecas de pruebas o formas en que podemos usar esto con React Native? ¿Has tenido alguna experiencia con esto? Sí, con React Native es más desafiante porque tienes, si usas, ¿cómo lo llamas? El simulador web. ¿Te refieres a un emulador? No es un emulador, pero como usarlo en la web. ¿Como la vista web? Sí, como tienes una capa donde puedes renderizar en el navegador, pero no es tan realista, así que tendrás que simular muchas cosas, por lo que no va a ser realista, así que no tendrás esta experiencia con VTest. Hay otras herramientas como Detox, creo, no soy un experto en React Native, pero creo que Detox funciona para eso. Justo, justo. Sé que hay mucha complejidad en algunas de estas preguntas, y recuerda que siempre puedes obtener más seguimiento después.

Esta es una pregunta general, y tal vez sea un poco una pregunta de filosofía de pruebas, que es ¿cuáles son buenas reglas generales para la velocidad y el alcance de las pruebas unitarias, verdad? Así que muchas personas tienen que decidir cuán granular vamos a ser, y me encanta lo que dijiste, hay una diferencia entre cobertura de código y, ¿era cobertura de usabilidad o de usuario? Comportamiento, sí, lo que sea. Así que cuéntanos un poco sobre cómo priorizas esa velocidad y ese alcance. Genial, ¿cuántas horas tengo? Dos minutos y 49 segundos. Bien, tengo un, ve a mi libro de cocina, aunque creo que está en la sección de Angular, hay una introducción sobre pruebas, pero es muy genérica, no es específica de Angular, y uno de los conceptos es estrecho versus amplio, y no uso unitario versus integración, porque en el momento en que dices unitario, la gente viene con muchas definiciones diferentes. Así que mi definición de una prueba estrecha es una prueba que se ejecuta en menos de 100 milisegundos, y sobre el alcance, es una prueba que está aislada fácilmente, no tienes que levantar una base de datos en Docker o lo que sea, y la tercera regla, que es la más importante en términos de alcance, es la complejidad. Cualquiera en el equipo puede depurar cualquier prueba que falle. Esto significa que puedes montar un componente con tres o cuatro tipos de hijos y tal vez llamar a algunos hooks, hooks personalizados y todo, pero si todo tiene una complejidad ciclomática de uno y es muy directo y fácil, y la prueba falla, va a ser fácil de depurar y va a ser fácil de entender. Así que esa es una de las reglas. Así que tienes que apuntar a la prueba estrecha más amplia. Entonces, ¿cuál es la prueba más grande que puedes pensar que puede ejecutarse en menos de 100 milisegundos y aún ser fácil de depurar para cualquiera en el equipo, incluidos los agentes? Porque no lo mencioné, pero por ejemplo, WallabyJS, tienen esta herramienta MCP que permite a los agentes saber instantáneamente cuál es el estado de la prueba y también preguntar sobre los valores de las variables en tiempo de ejecución, por lo que puede realmente depurar adecuadamente. Así que si proporcionas esto, podrá depurar fácilmente, pero si le das un gran alcance, todos lucharán, agentes y humanos. Me gusta mucho eso.

Y volviendo a tu presentación, solía decirle a otras personas que dan charlas que tienes estos momentos de ardilla. Y a lo que me refiero con ardilla, si piensas en la película Up donde el perro está hablando, es como, ¡ardilla! Y pienso en eso cuando a veces ves una herramienta realmente, realmente genial o algo realmente único, y tú tuviste muchas ardillas, pero había tantas herramientas realmente geniales, cosas realmente geniales que estoy como, oh, yo quiero obtener esa visualización en mi propio ID. Y uno de estos es sobre qué complemento o herramienta de IDE usaste para mostrar la cobertura de pruebas en el explorador de archivos?

Así que eso fue WallabyJS. Oh, ¿no tienes las diapositivas? Así que es Wallaby, como los canguros, pero no son canguros. Y es un complemento para VSCode. Y también en CLI, también funciona para WebStorm, pero es gratis para código abierto y de pago para cosas privadas, pero es súper genial. Y la cobertura no es nada. Es solo el comienzo de todas las características que proporciona. Así que es bastante genial.

Y tenemos cinco segundos. Rápido, y este es otro. ¿Qué era GitWipe? Porque lo usaste varias veces en tu charla. Y yo estaba como, ¿es eso un comando? No lo sé. Incluso lo busqué en Google. En realidad, es un alias que uso. Hay otro alias cuando tienes todas las herramientas de git en ZSH. Eso se llama GWIPE, git wipe. Y la cosa es que es una larga historia, en realidad. Es porque reinicio mucho. Como una de mis reglas es que si tengo una buena idea, debería poder comprometerme en cinco minutos. Y debería ir en pasos pequeños. Así que cada vez que me pierdo, hago git wipe out. Es una cosa realmente de reflejo. Así que reinicia todo. Limpia el repositorio. Vuelve a la cabeza y estás de vuelta a la seguridad. Intentas cosas y estás de vuelta a la seguridad. Genial. Gracias.