Pruebas de Componentes con Cypress vs Biblioteca de Pruebas de React

Rate this content
Bookmark

CCT vs RTL habla sobre las similitudes entre las herramientas, las diferencias, compara las formas de hacer las mismas cosas con las herramientas, y finalmente da una demostración de comparación de la experiencia del desarrollador.

25 min
11 Dec, 2023

AI Generated Video Summary

La charla discute las diferencias entre las pruebas de componentes con Cypress y la Biblioteca de Pruebas de React (RTL). Destaca los beneficios de usar las pruebas de componentes con Cypress, como un manejo más fácil de componentes complejos y una experiencia de prueba más estable en CI. La comparación entre SignOn y Jest se centra en las capacidades de espionaje y simulación de bajo nivel. La comparación entre Cypress Intercept y Mock Service Worker (MSW) examina sus capacidades de espionaje y simulación de red. La charla también enfatiza la superior experiencia del desarrollador y observabilidad proporcionada por las pruebas de componentes con Cypress en comparación con RTL.

1. Pruebas de componentes de Cypress vs React Testing Library

Short description:

Hola a todos. Mi nombre es Murat, y hoy hablaré sobre las pruebas de componentes de Cypress frente a la React Testing Library. Hemos estado utilizando las pruebas de componentes de Cypress en X10, mi empresa, durante un año, y hemos estado realizando pruebas de extremo a extremo durante dos años. En React, puedes encontrarte con la situación de tener que envolver tu componente con muchos proveedores. Esta es una prueba de componentes de Cypress para un componente simple del libro. Aquí está el segundo ejemplo, es un campo de texto, estamos escribiendo en él, también puede ser de solo lectura. A la izquierda, Cypress, cuando montamos el componente, usamos site.stop en su lugar y alias. Aquí está el tercer componente, estás haciendo clic en cada uno y asegurándote de que estamos en una ruta determinada y queremos asegurarnos de que lo que hacemos clic está resaltado y las cosas en las que no hacemos clic no están resaltadas. Cuanto más complejo se vuelve el componente, más beneficio obtendrás de la API de Cypress y tendrás un poco menos de código logrando lo mismo. Pero el verdadero vendedor es el HTML frente al navegador.

Hola a todos. Mi nombre es Murat, y hoy hablaré sobre las pruebas de componentes de Cypress frente a la React Testing Library. Puedes encontrar una copia de la presentación en Slides.com.

Mi nombre, SciCT versus RTL. Empecemos. Los cuatro temas en la presentación, ejemplos de componentes de Cypress versus React Testing Library, comparación de espionaje y simulación de bajo nivel, comparación de espionaje y simulación de nivel de red, y finalmente, una comparación de la experiencia del desarrollador. Hemos estado utilizando las pruebas de componentes de Cypress en X10, mi empresa, durante un año, y hemos estado realizando pruebas de extremo a extremo durante dos años. También tenemos la React Testing Library allí, también, por lo que puedes hacer algunas comparaciones calculadas entre las dos. Todos los ejemplos en la presentación serán de mi libro, Pruebas de componentes de Cypress impulsadas por el Diseño. Con cada componente, verás una variante de prueba de componentes de Cypress versus una variante de la React Testing Library, que puedes comparar vosotros mismos cuando produzcas el código.

En React, puedes encontrarte con la situación de tener que envolver tu componente con muchos proveedores. Cuando estás realizando una prueba de componentes de Cypress o una prueba de la React Testing Library, tienes que montar el componente de la misma manera que se monta en tu aplicación, por lo que para eso puedes usar estos montajes personalizados, que te permiten abstraer algunas de las complejidades que realmente no tienes que pensar cuando estás testing tu componente. La idea es de EPIC React de Kent Dodd, y verás prácticamente el mismo código por aquí, y compararemos cómo se utilizan con diferentes componentes. Esta es una prueba de componentes de Cypress para un componente simple del libro, solo mostrándote que esto está testing dos de los héroes aquí mismo. Echemos un vistazo al código, sizect en el lado derecho, rtl en el lado izquierdo, para montar o renderizar, es de la misma manera, en rtl tenemos asignación de variables de derecha a izquierda y las afirmaciones sobre eso. Cytus, tenemos sintaxis de cadena de izquierda a derecha y afirmaciones similares. Tenemos la API within en rtl, y es una API similar en el sitio de Cypress. Al final es la misma prueba, solo APIs ligeramente diferentes logrando lo mismo. Aquí está el segundo ejemplo, es un campo de texto, estamos escribiendo en él, también puede ser de solo lectura. Luego, en la prueba, queremos asegurarnos de que se están realizando llamadas onChange a medida que escribimos en la cosa. La única distinción aquí es cómo estamos marcando el onChange, así que solo FN para onChange y luego nos aseguramos de que se está haciendo la asignación cuando montamos el componente y luego más tarde hacemos afirmaciones en ese componente de que se está llamando tantas veces. A la izquierda, Cypress, cuando montamos el componente, usamos site.stop en su lugar y alias, más tarde nos referimos al alias de esta manera y luego nos aseguramos de que se llama tantas veces como estamos escribiendo en el campo. Aparte de eso, en el lado derecho también uso la biblioteca de testing por lo que tenemos encontrar por texto de marcador de posición aquí, podemos comparar eso uno a uno, luego podemos ver las diferencias de API por nosotros mismos. Aquí está el tercer componente, estás haciendo clic en cada uno y asegurándote de que estamos en una ruta determinada y queremos asegurarnos de que lo que hacemos clic está resaltado y las cosas en las que no hacemos clic no están resaltadas. Con Cypress, tenemos esta conveniencia de jQuery por lo que podemos hacer clic en algo y verificar que las cosas tienen un cierto CSS y las cosas en las que no hacemos clic no tienen ese CSS. Es posible hacer lo mismo en el lado de RTL pero requiere un poco de trabajo. Y verás este patrón, cuanto más complejo se vuelve el componente, más beneficio obtendrás de la API de Cypress y tendrás un poco menos de código logrando lo mismo. Pero el verdadero vendedor es el HTML frente al navegador. Así que en el lado de la React testing library, tienes cosas en la terminal, básicamente solo tienes HTML como texto. Y en el lado de las pruebas de componentes de Cypress, tienes el navegador real, tienes herramientas de desarrollo, tienes red, todo lo que tienes en tu aplicación real, pero solo con tu componente montado.

2. Ejemplos de Pruebas de Componentes de Cypress vs RTL

Short description:

Entonces, en Cypress, podemos obtener fácilmente el objeto de ventana y llamar al método get current position con un objeto de posición falso. Sin embargo, en RTL, necesitamos hacer un poco de trabajo extra para lograr el mismo resultado.

Eso te da mucha observability sobre lo que está sucediendo. Si has pasado por Epic React, te gustará este, porque cuando lo hice, creé un espejo de prueba de componentes de Cypress de todos estos ejemplos que cubre Kent. Y escogí tres aquí para que los veamos juntos. Así que aquí hay un simple ejemplo de Redux. La forma en que estamos renderizando o montando con el proveedor de Redux y la tienda es exactamente la misma. Si quieres tener una tienda personalizada, la forma en que estamos haciendo una asignación es exactamente la misma. Así que nada es diferente cuando se trata de Redux. Con Ally, hay APIs ligeramente diferentes porque estas son bibliotecas personalizadas al final. El Cypress, el inject X, y el check Ally. Con RTL, sacamos el contenedor de ahí y luego nos aseguramos de que no tiene violaciones. La API es más matizada, un poco diferente, cuando quieres tener impactos personalizados incluidos como moderno o serio, tienes que hacer un poco de trabajo en el lado de RTL, pero es posible lograr lo mismo. La geolocalización es interesante porque con Cypress podemos obtener la ventana del objeto de ventana y desde la geolocalización del navegador de la ventana, el método get current position puede ser llamado con este objeto de posición falso, y puedes ver la bonita abstracción allí exactamente comunicando lo que queremos hacer, con solo un RTL hay algo de trabajo allí, así que primero tenemos que fn la geolocalización, y encima de eso, después de hacer eso get current position solo fn, tenemos que marcar la implementación diciendo que esto va a ser una promesa que toma un callback, que toma esa posición falsa como argumento. Así que lleva un poco de trabajo, pero encima de eso tenemos que tener esta función de utilidad que está simulando una promesa diferida, porque tenemos que actuar, y luego resolver, y esperar esa promesa, y luego hacer la afirmación. Así que de nuevo, es posible hacer lo mismo en el lado de RTL, pero lleva un poco de trabajo para lograr el propósito. Así que esos son algunos ejemplos de pruebas de componentes de Cypress versus RTL.

3. Comparando SignOn y Jest

Short description:

Comparemos las capacidades de espionaje y simulación de bajo nivel de SignOn y Jest. Tienen APIs similares, pero SignOn proporciona algunos comparadores personalizados convenientes. Las pruebas asíncronas son ligeramente diferentes entre los dos, pero el resultado final es el mismo. En cuanto a los stubs y los mocks, CyStub es comparable a JestFn, pero la implementación y el uso difieren. Cynon proporciona abstracciones agradables para tratar con promesas, pero Jest requiere más esfuerzo. Trabajar con Jest en la comunidad de React ha construido experiencia e interés adquirido.

Echemos un vistazo a las capacidades de espionaje y simulación de bajo nivel, comparando SignOn y Jest. En el lado izquierdo, tenemos SignOn. En el lado derecho, tenemos Jest. SciSpy versus JeftSpyOn tienen APIs similares, tomando un objeto y un método. Para haber sido llamado notación de punto versus sintaxis de camel case, APIs similares, tenemos algunas alternativas en el lado de SignOn, pero hacen lo mismo.

Emparejando cadenas o esperando cualquier cosa, eso también es una comparación uno a uno. Comparadores personalizados, tienes estas conveniencias en el lado de SignOn y son bastante fáciles de usar y directas. Es posible hacer lo mismo en el lado de Jest, pero lleva un poco de trabajo, así que tienes que crearlos tú mismo si quieres tener comparadores personalizados. Por eso no los ves demasiado a menudo.

Asyngonist testing, ser capaz de crear el espía es prácticamente lo mismo en ambos lados. En el lado de Cypher, puedes envolver la promesa, el side wrap, y luego hacer una afirmación directamente sobre ella. En el lado de RTL, tienes que reunir todas las promesas primero y luego hacer una promesa de todas. De esa manera, puedes verificar el orden de ellas, por lo que la primera llamada es 4 y 5, la segunda llamada es 1 y 90, sumando estas cosas. En el lado de Cypher, se infiere porque llamamos a esta primera, por lo que debería ser llamada primero, y luego llamamos a esta segunda, que debería ser llamada segunda. Son ligeramente diferentes en las pruebas asíncronas testing pero al final, de nuevo, logramos lo mismo.

Hagamos un contraste y echemos un vistazo a los stubs y los mocks. CyStub es directamente comparable a JestFn para poder simular algo, métodos de objeto similares a la API de CySpy, con Jest, aunque ligeramente diferente. Todos estamos acostumbrados a las implementaciones de simulación y cómo lo hacemos, pero viene de, hey, ¿es esto un espía o es realmente un mock? En Jest, así es como lo hacemos. Nos hemos acostumbrado a ello, lo hemos estado haciendo todo el tiempo, así que es fácil de entender. A veces me confundo con la diferencia entre la implementación de mock versus el valor de retorno de mock pero cuando lo cambias al lado de Cynos, está claro. El valor de retorno de mock es un extra, asegurándote de que estás devolviendo un cierto método de la simulación del método. Cuando tratamos con promesas y hacemos las cosas un poco más sofisticadas, con Cynon tenemos algunas abstracciones agradables. Método de objeto siendo llamado con var return foo, es agradable y declarativo. Haciendo lo mismo en el lado de Jest, cediendo el argumento, condicional. Sí, es un poco de trabajo, pero es posible. Siguiendo una promesa, de nuevo, bien abstraída. Es posible en el lado de RTL, pero lleva un poco de trabajo. Rechazando una promesa, de nuevo, el mismo enfoque. Pero en la comunidad de React, nos hemos acostumbrado a estas formas difíciles de trabajar con Jest. Hemos construido cierta experiencia en esto, así que definitivamente va a haber algún interés adquirido allí.

4. Comparando Cypress Intercept y MSW

Short description:

Pero en el lado de Cynon, tienes la comodidad declarativa, y en el lado de Jest, tienes la posibilidad imperativa. Ahora comparemos las capacidades de espionaje y simulación de red de Cypress Intercept y Mock Service Worker. Al simular en el lado de la red, puedes ganar más confianza en tu componente. Comparando las APIs, MSW requiere más configuración e hooks, mientras que Cypress Intercept proporciona una API más sencilla con más flexibilidad. Aunque MSW es fantástico, Cypress Intercept se desempeña ligeramente mejor en la simulación a nivel de red.

Pero es bueno saber que en el lado de Cynon, las mismas cosas están disponibles con abstracciones más sencillas, pudiendo usar menos código. Así que hay más ejemplos en este repositorio, y puedes comparar uno a uno. Y paso por muchas de las otras comparaciones, pero al final, el mensaje es que en el lado de Cynon, tienes la comodidad declarativa, y en el lado de Jest, tienes la posibilidad imperativa. Puedes hacer lo mismo. Requiere un poco de trabajo en el lado de Jest, pero es totalmente posible lograr el mismo propósito.

Muy bien. Así que eso fue una comparación de espionaje y simulación de bajo nivel. Echemos un vistazo a las capacidades de espionaje y simulación de red. Por supuesto, estoy hablando de Cypress Intercept y Mock Service Worker. Así que si has pasado por los cursos de CAD Dots, sabrás que quieres simular más en el lado de la red versus el lado de tu código. Así puedes obtener más confianza de tu componente. Y si también usas estos montajes personalizados o renders personalizados, entonces estás en el negocio. Hacemos esto en X10 y es mucho menos código con el que tenemos que lidiar porque no tenemos que simular tanto.

Comparemos las APIs con Cypress Intercept en el método de la ruta que estamos golpeando. Así que digamos la Ruta de los Héroes, debería devolver 400. Con MSW hay algunas configuraciones, así que tienes que definir tus manejadores y tienes que definir tu ruta y lo que estás devolviendo de ella. Y luego tienes que hacer setup server con esos manejadores. Tienes que escuchar y luego tienes tu código de prueba. Y al final tienes que resetear los manejadores y cerrar. Así que hay un poco de trabajo configurando esto pero puedes domesticar esos con algunos hooks de prueba. Así que aquí tienes un ejemplo. Así que verás los hooks de prueba aquí y el before all server listen después de cada reseteo de manejadores y cierre. No necesitas nada de eso en el lado de Cypress Intercept. La otra diferencia es que podemos, por ejemplo, tener algún intercept en el bloque before each y luego podemos cambiar las cosas y sobrescribir cosas en los bloques it sobre ya sea sobrescribir o añadir a ellos. Con MSW no tienes esa posibilidad, así que tienes que definir tus manejadores y todos los bloques it debajo van a estar usando estos manejadores. Así que si quieres cambiar algo ligeramente en un bloque it eso no es posible. Desafortunadamente vas a tener que repetir todos estos hooks en un bloque separado sólo para hacer esa ligera variación. Para nosotros, eso hace toda la diferencia, porque tener esa flexibilidad nos permite tener menos código, menos ruido, y es simplemente una API más sencilla con la que trabajar. Al final, puedes echar un vistazo a estos recursos, reproducir el código tú mismo, y formar tu propia opinión, pero en mi opinión, aunque MSW es fantástico, es todo un cambio de paradigma en la simulación, siendo capaz de simular lejos de tu código fuente a nivel de red. Cypress Intercept, en mi opinión, lo hace ligeramente mejor, y vemos esto en cualquier comparación de código en X10, aunque no hemos usado MSW.

5. Comparando la Experiencia del Desarrollador y la Depuración

Short description:

Algunos de estos ejemplos muestran que cuanto más complejo se vuelve el componente, menos código se necesita con Cypress Intercept. Vamos a comparar la experiencia del desarrollador pasando por tres ejemplos sencillos, introduciendo fallos artificiales y depurándolos. En un ejemplo, cambiamos la visualización de 'off' a 'on' y observamos los resultados de las pruebas. Con Cypress, podemos identificar rápidamente el fallo y depurarlo inspeccionando el DOM.

Algunos de estos ejemplos que podemos observar, es obvio que cuanto más complejo se vuelve el componente, menos código se necesita con Cypress Intercept.

Finalmente, vamos a comparar la experiencia del desarrollador. Así que para esto, voy a hacer una demostración en vivo, porque de otra manera no sería realmente posible. Así que vamos a pasar por tres ejemplos sencillos, y vamos a introducir fallos artificiales e intentar depurar ellos.

Así que aquí tengo el componente de la barra de encabezado de la marca. Recordemos lo que está haciendo. Se llama a las especificaciones, y a la marca de la barra. Así que este simplemente va a mostrar dos de los héroes. Vamos a cambiar eso de 'off' a 'on'. Veamos qué sucede. Aquí está nuestro componente en el lado izquierdo. Simplemente haremos eso 'on'. Tendremos las pruebas de RTL ejecutándose aquí. Los fallos tardan un poco más, pero con RTL, vas a pasar un poco más de tiempo cuando estás trabajando a la carta en un componente a la vez. Va a ser más rápido, ligeramente más rápido cuando estás ejecutando la suite completa. Con Cypress, sólo puedes igualar eso si estás usando Vite. Con webpack, eso no va a ser compatible, pero las pruebas individuales van a ser mucho más rápidas con Cypress como veremos a lo largo de esta demostración.

Así que aquí, tenemos el fallo, está diciendo que falló en esta línea comprobando el tour de los héroes. Y si es un componente simple, es fácil de detectar el tour en los héroes, realmente no coincide con el tour de los héroes 'off'. Así es como lo sabemos. Con Cypress, tan pronto como digo, la prueba estará hecha, pero vamos a simular eso de nuevo. Y puedes ver lo mucho más rápido que es obtener la retroalimentación de una sola prueba. Así que podemos viajar en el tiempo, ver eso en el tour, lo consiguió. Así que está buscando 'off' en un span en esta línea, pero realmente no lo está consiguiendo. Eso no es suficiente, ya que esta es la demostración real, ¿verdad? Podemos simplemente inspeccionar eso. Y luego ir al lugar donde falló, apagar el resaltado. Y entonces estamos justo en nuestro DOM. Vemos el span del tour, vemos el span de 'on', ¿verdad? Y eso no es lo que queremos en nuestra prueba, queremos 'off'. Así que es una simulación fácil de un fallo y una experiencia de depuración. Muy bien, así que vamos a cerrar ese y luego echar un vistazo a nuestra segunda prueba.

6. Estabilidad de las Pruebas de Componentes de Cypress

Short description:

¿Podemos cerrar la prueba también? Permíteme saltar al componente de detalle de entrada para mostrarte la prueba. Escribimos 42 y queremos que onChange se llame dos veces. Para la versión de solo lectura, nos aseguramos de que no podamos interactuar con ella. Introducimos un retraso artificial para simular un fallo. La prueba de componentes de Cypress espera tres segundos y vuelve a intentarlo, haciendo que la prueba sea estable. Las pruebas de componentes de Cypress son más estables en CI en comparación con RTL.

¿Podemos cerrar también la prueba, no tenemos que hacer una modificación aquí. Así que permíteme, mientras eso se está cocinando, creo que va a tener que tomar un tiempo para ejecutar el sitio RTL, así que simplemente dejaremos que eso se cocine. Y simplemente saltaré al componente de detalle de entrada aquí para mostrarte cómo es la prueba. Cierro este tipo, selecciono ese. Así que es solo un campo de texto y podemos estar escribiendo en él. Por ejemplo, si viajo en el tiempo aquí, el tipo puede agregar el componente. Entonces, mientras estamos escribiendo, escribimos 42 y queremos que onChange se llame dos veces. Cuando es una versión de solo lectura del componente, solo queremos asegurarnos de que no podamos interactuar con él. Así que ese es el componente. Muy bien. Y vamos a tratar de mostrar más. Nombre del archivo, entrada, detalle, prueba. Por supuesto que eso va a funcionar. Así que lo que quiero simular aquí es un fallo. Digamos que tenemos, como siempre, una situación muy asíncrona, y estas llamadas onChange están llegando con un ligero retraso. Así que vamos a introducir este retraso artificial. Tendremos que usar tsignore para hacer que eso suceda. Así que básicamente esto dice que mientras estoy escribiendo, hay un ligero retraso en el que el DOM está respondiendo. Así que veamos qué sucede cuando hacemos eso. Guardaré. Y no voy a esperar a que RTL se cocine, pero haré este guardado. Y luego simplemente echaré un vistazo a la prueba de componentes de Cypress. Así que está esperando tres segundos. Y luego sigue intentándolo, intentándolo, intentándolo. Y Cypress tiene esta capacidad de reintentar incorporada. ¿Verdad? Y eso hace que la prueba sea muy estable. Así que no tuvimos que cambiar nada para hacer que la prueba funcionara de nuevo. Y esta es la razón por la que verás que tu prueba de componentes de Cypress es mucho más estable en CI en comparación con RTL siempre que tengas estas pruebas significativas que están haciendo cosas un poco ambiciosas. Y simplemente funcionará, muy, muy estable. Puedes hacer lo mismo.

7. Prueba RTL y Componente Heroes

Short description:

Puedes hacer que funcione en el lado de RTL, ver la prueba de detalle de entrada. La comprobación estática no va a funcionar. No estás recibiendo estas llamadas porque esta es una comprobación estática y está fallando en la línea 28. Una vez que utilices la API WaitFor envolviendo esa afirmación en una función asíncrona, tu prueba va a funcionar mejor. Así que ese va a ser el componente Heroes. Casi estamos allí con la Prueba de Aprobación de RTL de Detalle de Entrada. Solo esperaremos por ello. En este, estamos probando el componente de error.

Puedes hacer que funcione en el lado de RTL, ver la prueba de detalle de entrada. Pero para hacer esta prueba, tendrás que cambiarla ligeramente. ¿Verdad? La comprobación estática no va a funcionar. Veamos un fallo aquí. ¿Verdad? No estás recibiendo estas llamadas porque esta es una comprobación estática y está fallando en la línea 28. Porque cuando tienes este tipo de comportamiento asíncrono, tendrás que usar la API WaitFor envolviendo esa afirmación en una función asíncrona. Esta parte es exactamente la misma, pero la API WaitFor es diferente. Y una vez que hagas eso, entonces tu prueba va a funcionar mejor, ¿verdad? Mientras eso se está cocinando, no quiero esperar más a RTL, pero podemos pasar a la siguiente prueba. Y puedo mostrarte la siguiente en la Prueba de Componentes de Cypress mientras esta prueba se está ejecutando correctamente de nuevo. Vamos a tener que esperar por eso. Así que mientras eso se está cocinando, simplemente pasaré a la siguiente prueba. Así que ese va a ser el componente Heroes. Casi estamos allí con la Prueba de Aprobación de RTL de Detalle de Entrada. Solo esperaremos por ello. Vale. Así que, vale, así que, Detalle de Entrada ... De todos modos, estoy seguro de que lo haremos funcionar si luchamos un poco más, pero la idea es usar la función WaitFor. Y simplemente pasaremos a nuestra siguiente prueba, con Heroes, ¿verdad? Y echemos un vistazo a la prueba de Heroes. Así que en esta, lo que estamos haciendo es, vamos a verlo rápidamente. Así que en la segunda prueba, echemos un vistazo a esa, donde la estamos cargando, estamos viendo este spinner, estamos haciendo clic en el primer botón de Borrar, y luego estamos viendo el modelo, y luego en ese modelo, estamos haciendo clic en No. Y luego una vez que hacemos clic en No, el modelo desaparece. Y la segunda vez, borramos de nuevo, y esta vez hacemos clic en Sí. Después de hacer clic en Sí, queremos que el modelo desaparezca, y queremos ver al final una respuesta de red de 500 y luego el componente de error. Así que estamos probando el componente de error allí. Así que aquí, vamos a ejecutar la prueba de Heroes. Pondré la prueba de Heroes justo aquí. Así que en este componente, intentemos simular un fallo con un gancho de monitor. Así que digamos que cada vez que borramos algo en la lista de Heroes, queremos decir, vale, hay un problema con la eliminación de héroes, simplemente comentaremos esta línea, y esta línea va a fallar. Y si miras la prueba en el lado de RTL, así que estamos haciendo clic en el botón sí, y luego estamos asegurándonos de que el modelo no está en la vista. Y luego al final, vemos el error.

8. Experiencia de Desarrollador y Observabilidad

Short description:

La prueba de componentes de Cypress intercepta la solicitud de red y proporciona una observabilidad completa en el componente. En comparación, RTL carece de visibilidad y capacidades de depuración. La experiencia del desarrollador con las pruebas de componentes de Cypress es superior, ya que permite realizar pruebas en un navegador real y proporciona una observabilidad completa. Por otro lado, RTL te deja a oscuras. En general, hay muchas similitudes entre las herramientas, pero el diferenciador clave es la experiencia del desarrollador.

Entonces el modelo desaparecerá, creo, pero luego, dado que el hook está haciendo la llamada para hacer esa solicitud de eliminación, no vamos a ver el error. Y en el lado de la prueba de componentes de Cypress, interceptamos. Así que aquí tenemos la interceptación justo aquí. Tenemos que tenerlo en la parte superior del archivo con RTL y MSW. Hacemos el clic y luego el modelo desaparece. También esperamos esta solicitud de red, realmente no somos capaces de hacer lo mismo esperando llamadas de red en el lado de MSW.

Muy bien, entonces cuando vemos el fallo, echemos un vistazo. Entonces nos está diciendo que la línea 93 falló. Comentamos las cosas probablemente van a funcionar, pero realmente mirando el terminal, no somos capaces de ver nada o tener una idea de lo que no funcionó. ¿Es este problema con el componente de error? ¿Hay algo mal con nuestro componente de héroes? No lo sabemos, estamos literalmente a oscuras tratando de diagnosticar un problema como este.

Veamos cómo se ve eso en la prueba de componentes de Cypress. Así que simplemente volvamos a ejecutar. Entonces hacemos la operación de eliminación, estamos esperando la solicitud de red de eliminación. Pero eso nunca sube. Y aquí tenemos algo que ver con eso, pero también podemos mirar la pestaña de red de DevTools, y simplemente miraremos el XHR. Entonces, cuando mires esto, deberías ver salir una solicitud de eliminación. Pero no pasa nada, ¿verdad? Nunca obtenemos esa solicitud de eliminación. Entonces somos capaces de deducir que, bueno, lo que sea que esté causando esa eliminación, que es el hook personalizado, debe haber algo que no funciona con él. Y luego pensamos, ¿qué hace que esa eliminación ocurra? Esta función. Luego podemos seguir adelante e intentar debug si hay algo mal con nuestro hook personalizado. Así que esta es una comparación de la experiencia del desarrollador entre las tres herramientas, entre las dos herramientas. Tengo algunas diapositivas aquí que intentan comunicar con algunos videos, pero sin una demostración en vivo, nunca tendrías la sensación. El mensaje principal entonces entre estas tres experiencias por un lado, estás probando a oscuras. Por otro lado, tienes las luces encendidas, tienes una observabilidad completa en el componente. Ves exactamente lo que está pasando con el navegador, con la red, con el DOM. Así que esa es la conclusión de la experiencia del desarrollador. Para concluir, hay muchas similitudes entre las herramientas. Si conoces la biblioteca de pruebas de React y algo de Cypress de extremo a extremo, te sentirás muy cómodo con las pruebas de componentes de Cypress. La prueba de componentes de Cypress, tienes la conveniencia declarativa, con RTL y Jest tienes la posibilidad imperativa. El diferenciador clave es la experiencia del desarrollador, en mi opinión. Por un lado, tienes el navegador real, tu componente completo, solo por sí mismo. Así que es como tu aplicación completa, solo que ese componente está aislado. Por otro lado, tienes el HTML en el terminal. Eso hace toda la diferencia. Tienes una observabilidad completa por un lado versus estás a oscuras con RTL. Aquí están todos los enlaces y referencias en esta entrada de blog, es lo que causó la presentación para empezar. Y algunos otros, puedes buscar pruebas de componentes de Cypress versus comparaciones de RTL. Eso es todo lo que quería compartir. Gracias. www.microsoft.com www.microsoft.com

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
33 min
Network Requests with Cypress
Whether you're testing your UI or API, Cypress gives you all the tools needed to work with and manage network requests. This intermediate-level task demonstrates how to use the cy.request and cy.intercept commands to execute, spy on, and stub network requests while testing your application in the browser. Learn how the commands work as well as use cases for each, including best practices for testing and mocking your network requests.
TestJS Summit 2021TestJS Summit 2021
38 min
Testing Pyramid Makes Little Sense, What We Can Use Instead
Featured Video
The testing pyramid - the canonical shape of tests that defined what types of tests we need to write to make sure the app works - is ... obsolete. In this presentation, Roman Sandler and Gleb Bahmutov argue what the testing shape works better for today's web applications.
TestJS Summit 2022TestJS Summit 2022
27 min
Full-Circle Testing With Cypress
Cypress has taken the world by storm by brining an easy to use tool for end to end testing. It’s capabilities have proven to be be useful for creating stable tests for frontend applications. But end to end testing is just a small part of testing efforts. What about your API? What about your components? Well, in my talk I would like to show you how we can start with end-to-end tests, go deeper with component testing and then move up to testing our API, circ
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
21 min
Everyone Can Easily Write Tests
Let’s take a look at how Playwright can help you get your end to end tests written with tools like Codegen that generate tests on user interaction. Let’s explore UI mode for a better developer experience and then go over some tips to make sure you don’t have flakey tests. Then let’s talk about how to get your tests up and running on CI, debugging on CI and scaling using shards.

Workshops on related topic

React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
TestJS Summit 2022TestJS Summit 2022
146 min
How to Start With Cypress
Featured WorkshopFree
The web has evolved. Finally, testing has also. Cypress is a modern testing tool that answers the testing needs of modern web applications. It has been gaining a lot of traction in the last couple of years, gaining worldwide popularity. If you have been waiting to learn Cypress, wait no more! Filip Hric will guide you through the first steps on how to start using Cypress and set up a project on your own. The good news is, learning Cypress is incredibly easy. You'll write your first test in no time, and then you'll discover how to write a full end-to-end test for a modern web application. You'll learn the core concepts like retry-ability. Discover how to work and interact with your application and learn how to combine API and UI tests. Throughout this whole workshop, we will write code and do practical exercises. You will leave with a hands-on experience that you can translate to your own project.
React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
WorkshopFree
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop
TestJS Summit 2023TestJS Summit 2023
48 min
API Testing with Postman Workshop
WorkshopFree
In the ever-evolving landscape of software development, ensuring the reliability and functionality of APIs has become paramount. "API Testing with Postman" is a comprehensive workshop designed to equip participants with the knowledge and skills needed to excel in API testing using Postman, a powerful tool widely adopted by professionals in the field. This workshop delves into the fundamentals of API testing, progresses to advanced testing techniques, and explores automation, performance testing, and multi-protocol support, providing attendees with a holistic understanding of API testing with Postman.
1. Welcome to Postman- Explaining the Postman User Interface (UI)2. Workspace and Collections Collaboration- Understanding Workspaces and their role in collaboration- Exploring the concept of Collections for organizing and executing API requests3. Introduction to API Testing- Covering the basics of API testing and its significance4. Variable Management- Managing environment, global, and collection variables- Utilizing scripting snippets for dynamic data5. Building Testing Workflows- Creating effective testing workflows for comprehensive testing- Utilizing the Collection Runner for test execution- Introduction to Postbot for automated testing6. Advanced Testing- Contract Testing for ensuring API contracts- Using Mock Servers for effective testing- Maximizing productivity with Collection/Workspace templates- Integration Testing and Regression Testing strategies7. Automation with Postman- Leveraging the Postman CLI for automation- Scheduled Runs for regular testing- Integrating Postman into CI/CD pipelines8. Performance Testing- Demonstrating performance testing capabilities (showing the desktop client)- Synchronizing tests with VS Code for streamlined development9. Exploring Advanced Features - Working with Multiple Protocols: GraphQL, gRPC, and more
Join us for this workshop to unlock the full potential of Postman for API testing, streamline your testing processes, and enhance the quality and reliability of your software. Whether you're a beginner or an experienced tester, this workshop will equip you with the skills needed to excel in API testing with Postman.
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
WorkshopFree
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.
TestJS Summit 2023TestJS Summit 2023
148 min
Best Practices for Writing and Debugging Cypress Tests
Workshop
You probably know the story. You’ve created a couple of tests, and since you are using Cypress, you’ve done this pretty quickly. Seems like nothing is stopping you, but then – failed test. It wasn’t the app, wasn’t an error, the test was… flaky? Well yes. Test design is important no matter what tool you will use, Cypress included. The good news is that Cypress has a couple of tools behind its belt that can help you out. Join me on my workshop, where I’ll guide you away from the valley of anti-patterns into the fields of evergreen, stable tests. We’ll talk about common mistakes when writing your test as well as debug and unveil underlying problems. All with the goal of avoiding flakiness, and designing stable test.