Cypress vs Jest: Testing Insights

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.

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.

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

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.

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.

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

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.

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