Pruebas de Componentes con Vitest

¡Gracias! Bueno, es bastante temprano en la mañana y un minuto, sí, está cargando. ¿Cómo te sientes hoy? ¿Todo bien? ¿Tienes café? De hecho, tomé un sorbo de café y todavía estoy muy tranquila. El clima me parece una locura.

De todos modos, antes de que deep dive en nuestra charla, solo quiero repetir lo que estaba hablando sobre mí misma. Así que soy Maya Chavin, soy una Ingeniera de Software Senior en Microsoft. Trabajo para un grupo llamado Microsoft Industry AI. Así que hacemos algo así como aprovechar diferentes tecnologías de IA para construir soluciones específicas de la industria con JetGPT, GPT, y todo este módulo. Publiqué mi libro hace solo dos días, sí. Así que si eres y no has conocido Vue antes, quieres aprender Vue, sí, échale un vistazo. Y era un mantenedor de código abierto. Puedes seguirme en Maya Chavin o seguir mi blog. Publico un artículo una vez cada luna azul, con suerte.

De todos modos, testing. Así que sí, tenemos que probar, todos lo saben, ¿verdad? Tengo una advertencia antes de continuar. Odio las pruebas. Sí. Realmente odio las pruebas. Cada vez que llego a las pruebas, odio las pruebas. Antes de llegar a la prueba, digo, sí, todos tienen que escribir pruebas, todos, literalmente incluyéndome a mí. Y siempre le digo a todos en mi equipo, tienes que escribir pruebas. Pero cuando voy a escribir la prueba yo misma, digo, vamos, ¿por qué alguien querría una prueba? Bueno, sabemos que necesitamos pruebas, pero siempre enfrentamos el dilema, y eso es por qué odiamos las pruebas, más o menos. Complejidad del código. Cualquiera que trabaje con una página de código muy grande conocerá el dolor cuando necesite escribir pruebas. Y necesitas escribir pruebas para asegurarte de que tu prueba solo verificará lo que sucedió en tu código y no porque alguien más haga algo y luego afecte tus calidades de tu código. Marco de testing. No vas a elegir un marco. ¿Qué marco vas a elegir? Y sí, esta charla es sobre otro marco. Sí. Lo sé. Y la curva de aprendizaje.

¿Cómo vamos a invertir tiempo y esfuerzo en testing, ¿verdad? Pero necesitamos hacerlo. Entonces, ¿cómo vamos a hacerlo? Bueno, antes de elegir un marco, antes de ir a V-test, siempre tenemos que planificar. Veo a muchos desarrolladores que tienden a saltar directamente al código y escribir la imagen, hacer que funcione, y luego sacar la prueba más tarde. Ese es realmente el enfoque incorrecto.

Primero, necesitamos decidir qué tipo de proyectos queremos probar. ¿Es C Sharp? ¿Es JavaScript? ¿Acabo de decir C Sharp? Sí. No es realmente relevante para este, pero para Microsoft, tengo que hablar de C Sharp. De todos modos, el proyecto superior, ya sea backend o frontend o simplemente un montón de API o simplemente un montón de componentes, proyecto de código abierto, etc. En este proyecto superior, decidiremos qué tipo de plan de testing necesitas tener. Y priorizaciones. ¿Cuáles son tus prioridades aquí? Quieres tener resultados de testing rápidos, como el proceso de testing. Quieres correr en paralelo. ¿Cuántos trabajadores paralelos quieres para ejecutar tus pruebas? Una vez en nuestro equipo, tuvimos una prueba que tardó unas ocho horas en completarse. Eso te dice cuán compleja es nuestra base de código. Y llega al punto en que no podemos esperar a eso, y tenemos que ir y evaluar nuestro sistema de testing y agregar algo que lo reduzca a la mitad. Y eso es lo que hemos hecho con Playwright, no Vitex, pero es relevante. Mantén el orden de testing para que la gente sepa qué está pasando aquí, qué está pasando allí, qué pruebas fallaron y así sucesivamente. Y automatiza. Ya no necesitas testing manual, porque si haces tu testing automatizado, escribes la prueba, entonces toda la automation de testing, la automation de testing, se asegurará de que tu código esté cubierto. Así que todo, cuando planeas sobre testing, asegúrate de que planeas para automatizar primero y ante todo. Y por último, todo esto se reduce a una cosa, elige la herramienta correcta. Siempre elige la herramienta al final. Nunca elijas la herramienta primero y gires alrededor de ella. Porque si vas a la herramienta primero, cinco años después, sale otra herramienta, estás condenado, porque tienes que hacer migración y todo eso. Y volvamos a nuestras métricas aquí. Probablemente ya te acostumbraste a estas métricas, ¿verdad? Es la famosa métrica de la que habla cada libro de testing. Tener tres capas.

Tienen tres capas. La prueba unitaria es hacer testing. Vas a probar tu pedazo de código, realmente, literalmente pedazo de código, independiente. Y la integración, cuando pruebas todos estos pedazos de código juntos y ves si el flujo va correctamente. Y la prueba de extremo a extremo es simplemente la última pieza del rompecabezas. Solo asegúrate de que la interacción del usuario real está bien, usando los datos reales data está bien.

En esta masterclass, no vamos a hablar sobre la prueba de extremo a extremo. Vamos a hablar de la integración y unit testing con V-test. Pero primero, la demostración.

Entonces, en esta masterclass, voy a hacer una demostración de un componente muy simple llamado Películas. Lo que hace es que tiene tres características. Muestra una galería de películas. Permite al usuario completar la película por título, dando una entrada. Y la tercera es que la película tiene que ser obtenida de una API externa, que es asíncrona. El código se verá algo simple así. No hay nada fuera de lo común aquí. Solo un montón de conjuntos de pruebas.

Entonces, ¿cómo vamos a probarlo? ¿Cómo vamos a probar el componente, el componente de películas aquí? Bueno, para eso, vamos a hacer dos cosas. Vamos a probar la lógica del componente, que es solo un hook. Porque lo estoy usando en este. Puedes escribir todo el componente con toda la lógica dentro. Pero es mejor dividir esta lógica en sus propios hooks y luego probarla en consecuencia y dejar los componentes por separado. De esta manera, no tendrás que, cuando el componente se expanda, o cuando tengas que añadir más características, no tendrás que terminar con un componente muy largo, y no sabrás qué va a ser. Y por último, después de probar los hooks, lo que puedes hacer es simplemente realizar lo que tienes que hacer. Es simplemente realizar otra prueba de cordura del componente con todos estos hooks que estamos marcando. De esta manera, tienes dos cosas. Pruebas la lógica, y pruebas el componente basándote en la suposición de que tu lógica funciona.

Bueno, ahora llegamos a VTEST. ¿Cuántas personas aquí están familiarizadas con VTEST? ¿Probablemente sabes lo que se llama VTEST o VITEST? ¿Quién piensa que es VITEST? Bueno. En realidad, yo también.

¿Quién piensa que es VTEST, el resto, verdad? Vale, sí. Así que todos dicen VTEST, así que ese es el significado. Es como, cuando llegué por primera vez a VIT, pensé que era VITE, porque decimos LITE, así que se supone que es VITE, ¿verdad? Pero entonces digo, no, es VIT. Así que, ¿qué? De todos modos, eso es lo que significa el nombre.

Así que VTEST es lo que fue desarrollado por el equipo VIT para VIT power, vale, dispositivo VIT, VIT, por proyectos VIT power, pero ahora se ha convertido, no está solo limitado a proyectos VIT power, así que probablemente también se puede usar para otros proyectos webpack. Es un marco de pruebas unitarias de JavaScript y TypeScript, y acaba de lanzar la versión 1.00 también hace dos días. Guau. Así que es estable para usar. Es muy rápido. No puedo jurar por esto, porque lo usamos en el trabajo, cambiamos de CHESS a VTEST y es realmente, realmente rápido. Viene con soporte para TypeScript y CHESSX de serie, y por supuesto, la sintaxis es casi la misma que CHESS y Mocha y Chai, y puedes usar cualquiera de ellos, lo que significa que tu curva de aprendizaje, o tu migración, no requerirá tanto esfuerzo para hacerlo, pero mejor.

Vale, entonces, ¿cómo mejor, digamos, prueba unitaria? Para la prueba unitaria, advertencia aquí, en primer lugar, para la prueba unitaria, es importante saber que no probamos cada unidad de código. No pruebas cada pieza de código. Cada if y else, no significa que necesites probar todo. Si tienes que probar que dos más dos es igual a cuatro, eso es un hecho. No pruebas eso. Así que asegúrate de que no sobrecargas tu prueba. La segunda cosa es, para la prueba unitaria, siempre usa mock. Si algo viene de fuera, si algo importas y no es parte del código, deberías simularlo, porque nunca sabes qué está pasando en eso, desde el otro lado, puede afectar tu prueba. Y por último, siempre asegúrate de que haces pruebas funcionales aquí, eso significa lógica, no todo lo demás, no interacción y así sucesivamente. Echemos un vistazo al uso de la búsqueda, el hook, con el código, la lógica detrás. Así que en esta lógica, tengo dos cosas. Primero es que vamos a rellenar la lista de elementos de entrada según la búsqueda. Así que estas son las dos lógicas principales aquí que necesito probar por separado. Así que para eso, para probar el hook, VTest no funcionaría de serie con los hooks de React. Porque VTest es para JavaScript y TypeScript plan, el vanilla. Si quieres probar algo especial como los hooks, porque es interactivo, necesitas asegurarte de que necesitas usar una biblioteca externa para ayudar con eso. Así que en este caso, usando la biblioteca de pruebas de hooks de React es el paquete que te permite imitar y renderizar los hooks de React según el estándar de React, y luego puedes probarlo. Así que, ¿cómo hacemos eso? Primero, simplemente importamos render hook de la biblioteca de pruebas de hooks de React, y luego ejecutamos la función, activamos la función para renderizar los hooks en el contexto de React, y obtenemos de vuelta el resultado, y el resultado tiene un campo llamado current, donde puedes... lo siento.

Donde puedes afirmar como cualquier prueba, cualquier sintaxis normal. Puedes escuchar que busco que el resultado actual del término de búsqueda sea... vaya. No se resalta. Eso es gracioso. No importa. Vale. Vale. Entonces, para el usuario, el segundo es... ¿por qué? No importa. Este problema técnico. Lo siento. Necesito probarlo antes de ponerlo aquí. Vale. Así que ese es uno de los casos de uso para los usuarios cuando pruebas si es... cómo renderizas los hooks.

El segundo, cuando quieres probar la interacción del hook, digamos que llamas a una función y esperas que el interior del hook, algunos datos reactivos vayan a cambiar, puedes usar las funciones de la aplicación del paquete de render hooks, y luego se asegurará de que esperará hasta... desencadenará esta función como parte del contexto del hook, y luego se asegurará de que antes de pasar a esperar, tenemos esto cubierto y no te lanzará ningún error sobre el elemento reactivo que no se ha actualizado o algo así. Y eso es todo.

Y la razón por la que no hablo de toda la sintaxis de VTest aquí, es porque es similar a Chess aquí. Probablemente esperas que sea, todo es estado... probablemente tienes la importación esperada descrita desde VTest. Si miras la primera diapositiva... oh, funcionó. Sí. Entonces tienes la primera diapositiva aquí, esperada descrita desde VTest. Y esa es la característica modular de VTest que te permite importar una función específica y hacer que no sea como... no tienes que importar todo el paquete, y no estamos disponibles globalmente. Por supuesto, puedes hacerlo disponible globalmente usando la configuración. Pero si no quieres, esta es la forma. Hace que sea mucho más rápido de esta manera. Vale. Mueve. Sí. Sí. Vale. Entonces, este es el ejemplo de cómo puedes escribir la prueba.

Y también puedes ejecutar la prueba utilizando el Explorador de Pruebas aquí con la extensión VTest para VS Code. Y probablemente también puedes intentar que el copiloto escriba la prueba por ti, como estoy haciendo aquí.

Vale. Entonces, a continuación, la acción testing. ¿Qué significa eso? En los hooks de uso de películas, tenemos... tenemos un código llamado useEffect, donde vamos a hacer sincrónicamente las acciones de buscar película, que es un código asíncrono, lo que significa que no se detendrá. No esperará a que este código termine. Pero se actualizará uno... porque tenemos un useEffect, por lo que se actualizará cuando termine. Lo siento. Se actualizará cuando sea una película de prueba. Y así es como haces el código asíncrono dentro del código síncrono en un hook de React.

Ahora, cómo vamos a probarlo. Es más complejo y no trivial usando la prueba anterior que tenemos. Lo que hacemos aquí, tenemos que simular la búsqueda global con V.fn, una función falsa. Y luego eso en realidad tampoco es un buen enfoque, porque literalmente simulas toda la implementación global de la función de búsqueda. Y si alguien escribe otra prueba, están usando la búsqueda global y también la simulan, eso significa que probablemente termines teniendo una de las pruebas que caerá, dependiendo de la condición de carrera aquí. Así que la mejor manera de espiarlo es usando V.spy on, y esto asegurará que atacará una función de espionaje en esa búsqueda global y te permitirá realizar más simulaciones. Y el tercero, vamos a simular el valor de retorno de la búsqueda. Y vamos a vaciar todo ese código síncrono con Wave 4. En la versión anterior de la biblioteca de testing de hooks de React, estaban usando Wave 4, el siguiente actualización. Pero hace un mes, lo cambiaron a Wave 4. Creo que liberan y deprecian Wave 4 próxima actualización, por lo que deberías usar Wave 4, y simplemente envuelve el código de expectativa en el Wave 4, y se asegurará de que Wave 4 sea verdadero o se afirme dentro del marco de tiempo. Y por último, desencadenas la función en los hooks y la afirmas. ¿Cómo se ve? Entonces aquí, y aquí voy a comentar la búsqueda global. Y luego creo una función para el valor del resultado simulado. Y luego esta función simplemente, puedo reutilizar otro componente. Simplemente me devolverá una especie de resultado simulado para el valor de la búsqueda. Para la llamada de búsqueda. Y estoy llamando a la búsqueda, creo una función espía de búsqueda. Y antes de mi prueba, intentaré simular, enganchar el espía, y con el valor simulado dentro de mi prueba, que estoy usando antes. Pero si tienes una prueba diferente con un valor de resultado simulado diferente o un valor de rechazo simulado para la simulación de búsqueda, entonces puedes hacerlo dentro de la prueba misma, no antes.

Y aunque hagas eso, también necesitas limpiarlo después. Así que aquí puedes ver que hago Wave 4 en la promesa. Renderizo el hook, obtengo el resultado, obtengo una función llamada Wave 4 next update. Pero obviamente en el próximo, si lo usas, deberías cambiarlo por Wave 4. Y luego afirmarlo y ejecutarlo. Y eso es todo. Funcionó. Quiero decir, no hago codificación en vivo, pero captaste la idea.

Vale. Entonces, el siguiente, integración. Así que hablamos de pruebas de lógica. Así que terminamos con la testing de todas las funciones, toda la lógica que tenemos en el componente. Ahora vamos a hacer el segundo, la prueba de cordura, la prueba real del componente aquí. De nuevo, VTest no funciona por sí solo porque el componente React no es una función regular de JavaScript que puedas probar. Así que para eso, lo combinamos con una biblioteca externa llamada TestingLibraryReact. Y este componente, este paquete te dará la función de render que te permitirá imitar y renderizar un componente en el entorno de React. Y luego VTest puede afirmar el resultado de ese entorno. ¿Cómo hacer eso? Tenemos dos cosas. Configuración. Así que VTest, necesitas configurarlo, necesitas extender la función expect con el matcher de los matchers de prueba de TestingLibrary. Así que expect puede comparar entre instantáneas o puede comparar entre las diferentes API dentro del domo de React. Y luego te enganchas a la configuración de VTest con el archivo de configuración. Y luego simplemente lo renderizas. Importas el render de TestingLibraryReact. Y luego renderizas la función con el componente obtenido por test ID. Y por último, esperas que se haya probado. Tan simple como eso. Y así tenemos nuestra primera prueba para nuestro componente testing hecha.

Entonces, ¿por qué necesitamos dividir la lógica por componente? Bueno, como puedes ver, puedes poner todo dentro. Pero entonces la testing será difícil porque tendrás que poner todas las pruebas dentro de un solo archivo.

Y la gran oportunidad aquí, cambias algo en la búsqueda, solo necesitará ser reprobado en la búsqueda. Y no tienes que ejecutar toda la prueba en el componente en sí. Y tenemos menos código para realizar el cinco. Y por último, hacer que la testing de componentes sea más aislada. Y solo necesitas probar la prueba de cordura y la accessibility prueba. Estas son las dos cosas principales. Interacciones, interacciones de la interfaz de usuario, imitación y accessibility. Eso se supone que es la prueba de componentes.

Cobertura. Creo que me estoy quedando sin tiempo. Entonces, para la cobertura, ¿80% o 90%, cuál es mejor? Bueno, necesitas decidirlo tú mismo. Mi consejo es nada más del 80% para la cobertura. Y si quieres usar la cobertura con VTest, puedes instalar el paquete adicional para Estambul de VTest y luego conectarlo a VTest en uno de los proveedores. Y voilà, tienes la cobertura de pruebas. También en HTML. Y extensión para VTest y VS Code. Yo lo uso. Porque es muy agradable usarlo. Y eso es todo.

¿Qué? Otra herramienta que puedes intentar revisar para usar con VTest en sí. HappyDome. El rumor es que es muy bueno. Mejor que ChessDome. Nunca lo probé. Pero deberías intentarlo. Y avísame si es realmente bueno. El rumor lo tiene. Xscore React. Esta es la biblioteca para accessibility testing que usamos para React components. Y puedes conectar este dentro de Playwright o VTest.

Y puedes probar. Realiza la prueba de cordura de accessibility. No cubre todo. Pero asegura que tu código seguirá cierta conformidad semántica de WarioArea.

¿Y qué sigue? Antes de terminar. Planifica. Siempre. Planea tu prueba. Primero. Codifica después. No tienes que optar por TDD u otras metodologías. Solo ten una idea de lo que vas a construir. Lo que quieres probar antes de empezar a trabajar en ello.

Divide la lógica del componente. Me gusta el hecho de que no quiero que mi componente sea grande. Si tiene más de 100 líneas de código, probablemente deberías dividirlo. Simula de manera responsable. No intentes simularlo para que tu prueba pase en cualquier caso. Y localizador. Puedes usar clase o ID. Pero prefiero usar data test ID. Así se mantendrá mayormente estable. Y nadie querrá siquiera intentar meterse con ello. Y por último. Agrega una puntuación para la accessibility testing, si aún no lo has hecho. Y gracias.

Entonces, tenemos algunas preguntas que han surgido. Y muchas de ellas se basan en comparaciones. Podría consolidar algunas de estas preguntas en general, ya sabes... ¿Sugieres usar... ¿Dijimos vitest? ¿En qué quedamos? ¿Tú... Realmente no lo recuerdo. ¿Sugieres usar vitest para pruebas de componentes web? Y si es así, ¿cuáles dirías que son los beneficios más allá de la velocidad en comparación con playwright o Jest u otras ejecuciones de pruebas?

En primer lugar, no he escrito un componente web todavía. Así que no puedo... Así que no tomes mi palabra por esto, porque asumo que el componente web es similar a JavaScript normal. Así que definitivamente puedes probar con vitest. Bueno, tal vez debería preguntarlo en Twitter, porque no tengo idea. Pero de cualquier manera, estoy seguro de que puedes combinar esto con vitest. Es solo un marco de pruebas para... Marco de pruebas unitarias. Así que es... Así que puedes probar un código JavaScript o TypeScript normal en eso. Pero cosas como el componente web, tienes que usarlo con una biblioteca adicional para ayudar a renderizar el componente o, ya sabes, combinarlo para poder probarlo. Así que deberías probarlo de cualquier manera. Y no es porque... ¿Sería mejor que playwright? Bueno, lo que pasa es que vitest y playwright no son lo mismo. Vitest es para pruebas unitarias. Playwright para pruebas de extremo a extremo. Así que puedes combinar estos dos para convertirlo en un sistema completo de pruebas. Así que tienes a playwright para hacer la prueba de extremo a extremo. Y después de que ya tienes tu código cubierto por pruebas unitarias, por vtest. Sí, eso tiene sentido. Gracias.

Otra pregunta que ha surgido es... Esta podría ser una pregunta bastante clara, si conoces la respuesta. Pero, ¿vitest usa JS DOM para renderizar componentes al hacer pruebas? No exactamente.

JS DOM no es para renderizar. Un JS DOM es para obtener la API para la API DOM, como una API DOM simulada. Así que puedes obtener un selector, o puedes hacer obtener un atributo por ID o por... Lo siento, no un atributo. Obtener un atributo, algo con la API DOM. Así que usualmente, sí. Por defecto, vitest utiliza JS DOM. También puedes cambiar a happy DOM, si quieres. Es configurable, sí.

Excelente. Gracias. Hay tantas preguntas geniales, y simplemente no tendremos tiempo para hacerlas todas. Tengo una muy rápida, que es una de las cosas que mencionaste en tu charla fue la especie de interoperabilidad entre lo que la gente ya puede estar usando para testing y vitest. ¿Has experimentado, al contrario, alguna peculiaridad donde en realidad, tengo que hacer un poco más de trabajo manual aquí. No es solo un reemplazo directo. Hablaste... Así que déjame entender esto correctamente. Así que estabas preguntando que, si ya tengo mi sistema de testing en un marco diferente, y ahora quiero cambiar a vitest, ¿tuve algún momento de fracking donde no funciona de inmediato?

Exactamente. Una de las cosas que mencionaste en tu charla fue la facilidad de migración entre sistemas. Al contrario, ¿hay alguna vez que eso... Sí, hay algunos momentos aha allí. Por ejemplo, alguna función en Chess que no recuerdo exactamente cuál. Creo que algo relacionado con mock. Así que tuve una vez que tuve que migrar la prueba con la prueba mock. La prueba que tenemos un montón de mocks. Y Chess tiene una función mock especial que borra el debounce, la usa para simular el debounce. Y no pude encontrar la función de similitud que puedo usar en vitest. Así que me tomó alrededor de un día o algo así encontrar una solución alternativa. Pero eso fue cuando vitest era la versión 0.0 algo. Así que estoy seguro de que ya lo habrán solucionado.

Excelente. Muchas gracias. Honestamente, hay tantas preguntas y ya casi nos quedamos sin tiempo. Pero para aquellos de ustedes que se unen a nosotros en la sala, esto se transmitirá en vivo más tarde. Pero para aquellos de ustedes que se unen a nosotros en la sala, todos los oradores de hoy, después de sus charlas, se dirigirán al área de preguntas de los oradores, que está cerca de la entrada.

Así que quiero que demos un gran aplauso a Maya. Y si quieres seguir haciendo preguntas, por favor dirígete al área de preguntas del orador después. Así que es hora de un aplauso. Gracias. Gracias. Gracias.