Pruebas de Componentes con Vitest

Rate this content
Bookmark

Las pruebas son importantes. Las pruebas unitarias adecuadas pueden eliminar la posibilidad de que aparezcan errores. Pero, ¿qué marco de pruebas será adecuado? Exploremos cómo podemos desarrollar una estrategia confiable y eficiente para el desarrollo y prueba de componentes con Vitest

29 min
07 Dec, 2023

AI Generated Video Summary

Esta charla explora los desafíos de elegir y aprender marcos de pruebas, enfatizando la importancia de la planificación, la automatización y la priorización de las pruebas unitarias. El marco VTEST se presenta como una opción rápida y estable para las pruebas unitarias de código JavaScript y TypeScript, con un enfoque en la lógica y la simulación de dependencias externas. La charla también cubre las pruebas de los hooks de React, las pruebas de integración con TestingLibraryReact, las pruebas de componentes y la consecución de la cobertura de código. Las mejores prácticas incluyen la realización de pruebas de accesibilidad, la planificación de pruebas antes de la codificación y el uso de IDs de prueba de datos para la estabilidad.

1. Introducción a los Marcos de Prueba

Short description:

¡Gracias! Soy Maya Chavin, una Ingeniera de Software Senior en Microsoft trabajando con Microsoft Industry AI. Odio las pruebas, pero sabemos que las necesitamos. La complejidad del código y la elección de un marco de pruebas son desafíos. Esta charla es sobre otro marco y su curva de aprendizaje.

¡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.

2. Desafíos de los Marcos de Pruebas

Short description:

Cada vez que hablamos de un nuevo marco de pruebas, cambiamos de uno a otro porque es más genial y rápido. Pero siempre hay una curva de aprendizaje. No todos están de acuerdo, y las APIs difieren. El dilema es asegurar una cobertura de código del 90%. Si no, los PR no se fusionarán. Todo se reduce al tiempo. ¿Cómo asignamos tiempo y esfuerzo a las pruebas?

Cada vez que hablamos de un nuevo testing marco, cambiamos de un testing marco a otro simplemente porque el otro es mucho más genial y rápido, siempre tenemos una curva de aprendizaje. Porque no a todos les gusta estar de acuerdo, no todas las API se ven igual, se sienten igual, hacen lo mismo. Y llegamos a un punto muy específico de dilema aquí. Pasas todo esto, todavía necesitas asegurarte de que tu prueba pase la cobertura mínima de tu base de código. ¿Y qué pasa si alguien decide que el 90% de tu base de código necesita ser cubierta por la prueba? Entonces lo haces. 89 o 99 no es 90. Y eso impide que tu PR se fusione y probablemente quieras levantarte de la mesa y gritarle a alguien por eso. Y todo se reduce a una sola cosa. Solo este dilema se reduce a una sola cosa, el tiempo.

3. Planificación y Automatización de Pruebas

Short description:

Antes de elegir un marco, necesitamos planificar y priorizar nuestro proceso de pruebas. Ejecutar pruebas en paralelo puede ahorrar tiempo, especialmente para bases de código complejas. La automatización de pruebas garantiza la cobertura de código y elimina la necesidad de pruebas manuales. Al planificar las pruebas, siempre priorice la automatización y elija la herramienta correcta. Las pruebas unitarias son cruciales para probar piezas individuales de código.

¿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.

4. Capas de Pruebas, Demostración de Componente y VTEST

Short description:

Las pruebas unitarias, de integración y de extremo a extremo son las tres capas de pruebas. En esta masterclass, nos centraremos en las pruebas de integración y unitarias con V-test. Comenzaremos con una demostración de un componente simple llamado Películas que tiene tres características: mostrar una galería de películas, permitir a los usuarios completar una película por título y obtener películas de una API externa. Discutiremos cómo probar la lógica del componente por separado utilizando hooks y luego realizaremos una prueba de cordura del componente. Por último, hablaremos de VTEST, un tema familiar para algunos de ustedes.

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.

5. Introducción al Marco VTEST

Short description:

VTEST es un marco de pruebas unitarias de JavaScript y TypeScript desarrollado por el equipo VIT. Es rápido, estable y admite TypeScript y CHESSX de serie. Cuando se trata de pruebas unitarias, es importante priorizar la lógica y usar la simulación para las dependencias externas. Para probar los hooks de React, puedes usar el paquete de la biblioteca de pruebas de hooks de React para imitar y renderizar los hooks en el contexto de React.

¿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.

6. Pruebas con el Marco VTest

Short description:

Puedes afirmar como cualquier prueba, cualquier sintaxis normal. Para el usuario, un caso de uso es probar cómo renderizas los hooks. Otro caso de uso es probar la interacción del hook, donde esperas que los datos reactivos cambien. La sintaxis de VTest es similar a Chess y te permite importar funciones específicas. Este ejemplo muestra cómo escribir la prueba.

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.

7. Pruebas de Acción y Simulación

Short description:

Puedes ejecutar la prueba utilizando el Explorador de Pruebas con la extensión VTest para VS Code. Las pruebas de acción se refieren a la ejecución de código asíncrono dentro de código síncrono en un hook de React. Para probarlo, se requiere simular la búsqueda global utilizando V.fn o espiarla con V.spy on. También es necesario simular el valor de retorno de la búsqueda y vaciar el código síncrono con Wave 4. Finalmente, desencadenar la función en los hooks y afirmar el resultado completa el proceso de 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.

8. Pruebas con VTest y TestingLibraryReact

Short description:

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. Funcionó. A continuación, pasamos a las pruebas de integración. Combinamos VTest con TestingLibraryReact para probar los componentes de React. Configuramos VTest con el matcher de TestingLibrary para comparar instantáneas y APIs. Luego renderizamos el componente utilizando la función de render de TestingLibraryReact y afirmamos el resultado con VTest. Dividir la lógica por componente es necesario para facilitar las pruebas, ya que poner todas las pruebas en un solo archivo sería desafiante.

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.

9. Pruebas de Componentes y Cobertura

Short description:

Si cambias algo en la búsqueda, solo necesitará ser reprobado en la búsqueda. No es necesario ejecutar toda la prueba en el componente en sí. Las pruebas de componentes se vuelven más aisladas. Prueba la prueba de cordura y la prueba de accesibilidad. El consejo de cobertura no es más del 80%. Instala el paquete adicional para Estambul de VTest para la cobertura. Otras herramientas para revisar: HappyDome y Xscore React para pruebas de accesibilidad.

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.

10. Mejores Prácticas de Pruebas

Short description:

Realiza la prueba de accesibilidad de cordura para garantizar el cumplimiento del código. Planea tu prueba antes de codificar. Divide la lógica del componente si supera las 100 líneas. Simula de manera responsable y usa el ID de prueba de datos para la estabilidad. Agrega una puntuación de prueba de accesibilidad. Gracias.

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.

QnA

Vitest para Pruebas de Componentes Web

Short description:

¿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? Vitest es un marco de pruebas unitarias para código JavaScript o TypeScript normal. Para probar los componentes web, se requiere una biblioteca adicional para ayudar a renderizar y probar los componentes. Vitest y playwright sirven para diferentes propósitos, con vitest centrado en las pruebas unitarias y playwright para las pruebas de extremo a extremo. Se pueden combinar para crear un sistema de pruebas integral. Otra pregunta es si vitest usa JS DOM para renderizar componentes al probar, y la respuesta no es exactamente.

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 y Migración a VTest

Short description:

JS DOM no es para renderizar. Por defecto, vitest utiliza JS DOM, pero puedes cambiar a happy DOM. Puede haber algunas peculiaridades al migrar de un marco de pruebas diferente a vitest. Por ejemplo, la función mock en Chess tenía una característica especial de debounce que tuve que encontrar una solución alternativa al migrar a vitest. Sin embargo, esto fue en una versión temprana de vitest, por lo que puede que ya se haya solucionado.

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.

Conclusión y Preguntas y Respuestas

Short description:

Para aquellos que se unen a nosotros en la sala, esto se transmitirá en vivo más tarde. Después de las charlas, todos los oradores estarán disponibles en el área de preguntas cerca de la entrada. Aplaudamos a Maya y continuemos haciendo preguntas en el área de preguntas del orador. ¡Gracias!

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

TestJS Summit 2021TestJS Summit 2021
31 min
Test Effective Development
Developers want to sleep tight knowing they didn't break production. Companies want to be efficient in order to meet their customer needs faster and to gain competitive advantage sooner. We ALL want to be cost effective... or shall I say... TEST EFFECTIVE!But how do we do that?Are the "unit" and "integration" terminology serves us right?Or is it time for a change? When should we use either strategy to maximize our "test effectiveness"?In this talk I'll show you a brand new way to think about cost effective testing with new strategies and new testing terms!It’s time to go DEEPER!
TestJS Summit 2023TestJS Summit 2023
32 min
The Art of ‘Humble Views’: Testing React Native Apps the Smart Way
In this talk, we explore the divisive world of testing, where developers often find themselves torn between writing no tests and striving for 100% test coverage. Learn how to navigate these polarizing positions and adopt a more nuanced strategy that makes testing efficient and effective.We'll dive into the concept of 'Humble Views,' where we minimize untestable objects by extracting logic from UI elements into test-friendly parts of the codebase. This approach simplifies testing, focusing on business logic instead of UI complexities. Discover how the Model-View-Presenter (MVP) architecture helps achieve this, with presenters serving as a logical layer for testing and hooks aiding in separating logic from UI components.Throughout the talk, we'll discuss the trade-offs of this approach, the role of End-to-End (E2E) tests, and how to strike the perfect balance between too much and too little testing. Join us as we delve into the art of creating 'Humble Views,' ensuring that our React Native apps are scalable, maintainable, and effectively tested!
TestJS Summit 2021TestJS Summit 2021
20 min
It's a (Testing) Trap! - Common Testing Pitfalls and How to Solve Them
It’s a trap” - a call or feeling we all might be familiar with, not only when it comes to Star Wars. It’s signalizing a sudden moment of noticing imminent danger. This situation is an excellent allegory for an unpleasant realization in testing. Imagine having the best intentions when it comes to testing but still ending up with tests failing to deliver you any value at all? Tests who are feeling like a pain to deal with?
When writing frontend tests, there are lots of pitfalls on the way. In sum, they can lead to lousy maintainability, slow execution time, and - in the worst-case - tests you cannot trust. But it doesn’t have to be that way. In this session, I will talk about developers’ common mistakes (including mine), at least from my experience. And, of course, on how to avoid them. Testing doesn’t need to be painful, after all.
TestJS Summit 2021TestJS Summit 2021
8 min
Who is Testing the Tests?
Have you ever wondered: "who's testing the tests"? Of course, tests are only valuable if they catch bugs, but how would one validate that? Well, let me tell you about mutation testing!
Mutation testing is the act of testing your test verifying that they catch bugs. Of course, you can do this manually inserting bugs and running the tests, but a mutation testing framework can do this for you!
Join me and learn the basics of mutation testing and how to use StrykerJS, the mutation testing framework for JavaScript or TypeScript.At the end of this talk, you'll be the one that is testing your tests, and it won't even cost you much time!
TestJS Summit 2022TestJS Summit 2022
11 min
Using Tests for What?!
In the talk I will explain the pains and problems of form validation Then I will explain the mental model of unit tests, and compare it to how we think about form validations.I will introduce vest with a bit of live coding showing its unit testing syntax.