Solicitudes de red con Cypress

Rate this content
Bookmark

Ya sea que estés probando tu interfaz de usuario o API, Cypress te brinda todas las herramientas necesarias para trabajar y gestionar las solicitudes de red. Esta tarea de nivel intermedio demuestra cómo utilizar los comandos cy.request y cy.intercept para ejecutar, espiar y simular solicitudes de red mientras pruebas tu aplicación en el navegador. Aprende cómo funcionan los comandos y los casos de uso para cada uno, incluyendo las mejores prácticas para probar y simular tus solicitudes de red.

33 min
18 Nov, 2021

Video Summary and Transcription

Cecilia Martinez, una gerente de cuentas técnicas en Cypress, habla sobre las solicitudes de red en Cypress y demuestra comandos como cydot request y SCI.INTERCEPT. También explica la coincidencia dinámica y el aliasing, la simulación de solicitudes de red y los pros y contras de usar respuestas reales del servidor versus simulación. La charla cubre el registro de respuestas de solicitudes, la prueba de API de front-end y back-end, el manejo de la longitud de la lista y la navegación por el DOM, la carga perezosa y proporciona recursos para que los principiantes aprendan Cypress.

Available in English

1. Introduction to Network Requests with Cypress

Short description:

Hola, soy Cecilia Martinez, una gerente de cuentas técnicas en Cypress. Hoy hablaré sobre las solicitudes de red con Cypress. Cypress es un marco de código abierto para escribir y ejecutar pruebas en un navegador. Proporciona una interfaz gráfica de usuario con un registro de comandos que muestra las solicitudes de red realizadas durante las pruebas. También puedes interactuar con las solicitudes de red utilizando los comandos cydot request y cydot intercept. Utilizaré código de la aplicación de pago de código abierto de Cypress para demostrar estos comandos.

Y estoy muy emocionada de estar aquí hoy para hablarles sobre las solicitudes de red con Cypress. He puesto a disposición las diapositivas de la presentación en la URL que aparece en la pantalla, y puedes contactarme en Twitter en Cecilia Creates.

Entonces, para aquellos de ustedes que no están familiarizados con Cypress, es un marco de código abierto que te permite escribir y ejecutar pruebas para cualquier aplicación que se ejecute en un navegador. Cypress ejecuta pruebas contra tu aplicación dentro de un navegador real. Puedes ver en la pantalla aquí una representación de nuestra interfaz gráfica de usuario cuando estás ejecutando tus pruebas localmente. Entonces, la aplicación bajo prueba está en el lado derecho en la vista previa de la aplicación. Y luego, en el lado izquierdo, tenemos lo que se llama nuestro registro de comandos, que como su nombre indica es un registro de todos los comandos que tu código de prueba está ejecutando contra tu aplicación. Esto nos brinda información sobre las solicitudes de red que están ocurriendo dentro de tu aplicación a medida que las pruebas avanzan. Puedes ver las solicitudes de red a medida que ocurren en el registro de comandos. Aquí en la captura de pantalla, podemos ver que después de que nuestro código de prueba ha hecho clic en un elemento, se produjo una solicitud POST. Podemos ver el código de estado, podemos ver el punto final, así como cómo podemos o no interactuar con esa solicitud a través de nuestro código de prueba. También podemos hacer clic en cualquier solicitud en el registro de comandos para mostrarla en la consola. Esto te brinda información adicional útil como las cabeceras de la solicitud, el cuerpo de la respuesta, que puede ser útil cuando estás solucionando problemas o depurando pruebas fallidas, o tratando de comprender mejor lo que está sucediendo con las solicitudes de red de tu aplicación.

Además de ver las solicitudes de red dentro del ejecutor de pruebas de Cypress, también puedes interactuar con ellas. Entonces, hoy vamos a hablar sobre dos comandos que te permiten trabajar con las solicitudes de red dentro de tus pruebas de Cypress. El primero es cydot request, que ejecuta solicitudes HTTP. Y el segundo es cydot intercept, que te permite interactuar con las solicitudes de red. Para fines de demostración hoy, utilizaré código de la aplicación de pago de código abierto de Cypress. La aplicación de pago de código abierto de Cypress es un gran recurso. Fue desarrollada por nuestro equipo de Developer Experience. Es una aplicación de React de pila completa que muestra mejores prácticas, casos de uso y básicamente todas las cosas diferentes que puedes hacer con Cypress. Entonces, es de código abierto. Entonces, si vas al enlace de GitHub en la pantalla, puedes ver el código fuente, así como un conjunto completo de pruebas de UI y API para la aplicación. Es una aplicación de pagos similar a Venmo. Entonces, estás lidiando con cosas como usuarios, transacciones, cuentas bancarias y mucho más.

2. Introducción a cydot request

Short description:

cydot request es un comando en Cypress que te permite enviar solicitudes HTTP desde tu código de prueba. Se utiliza comúnmente para pruebas de API, donde puedes validar las respuestas de los puntos finales del servidor. También puedes usarlo para recuperar, crear o actualizar datos con fines de prueba. Además, puedes usarlo para validar puntos finales antes de continuar con tu prueba.

componentes de interfaz de usuario muy familiares. Muy bien. Así que podemos comenzar con cydot request. Como mencioné, cydot request envía una solicitud HTTP desde tu código de prueba. Esto es independiente de la funcionalidad de tu aplicación. Es similar a cómo puedes enviar una solicitud HTTP desde cURL o Postman. Entonces, la sintaxis es cydot request. Como mínimo, debes pasar la URL del punto final donde estás realizando la solicitud. También puedes pasar el método, un cuerpo especificado y opciones adicionales para la solicitud.

Entonces, ¿por qué usarías cydot request? El caso de uso más popular es en realidad para pruebas de API. Cypress, aunque es conocido principalmente por pruebas de interfaz de usuario y de extremo a extremo, también puedes usar el comando cydot request, junto con el mismo lenguaje de aserciones con el que estás familiarizado, para validar las respuestas que regresan de tus puntos finales del servidor. Entonces, en el ejemplo aquí, esto viene directamente de la suite de pruebas de API en nuestra aplicación real de Cypress. Estamos validando una solicitud GET a nuestro punto final de cuentas bancarias, y el bloque de la prueba es que obtiene una lista de cuentas bancarias para un usuario. Entonces, en este caso, estamos usando cydot request en la línea 4 para hacer una solicitud GET a ese punto final. Y luego, estamos obteniendo la respuesta y haciendo aserciones sobre ella. Esperamos que el estado de respuesta sea igual a 200. Y esperamos que el cuerpo de la respuesta contenga el ID de usuario en los resultados. Entonces, nuevamente, puedes aprovechar la misma sintaxis de Cypress que estás acostumbrado para las pruebas de API junto con tu suite de pruebas de interfaz de usuario. También puedes usarlo para recuperar, crear o actualizar datos para pruebas.

La gestión de datos de prueba es un tema muy popular cuando se trata de pruebas, especialmente cuando se trata de pruebas de extremo a extremo. Entonces, si necesitas recuperar datos de un punto final, como un nombre de usuario o contraseña para iniciar sesión, o si necesitas crear una transacción o crear algo en tu aplicación para probarla, en lugar de hacerlo programáticamente, puedes usar una llamada de solicitud firmada para hacerlo a través de tu API. También puedes usarlo para validar puntos finales antes de continuar con tu prueba. Entonces, si tienes un punto final poco confiable o un backend que puede ser más lento o estar inactivo, o si estás utilizando un servicio de terceros o un microservicio y simplemente quieres asegurarte de que todo esté listo antes de continuar con tu prueba, puedes enviar una solicitud de cierre de sesión para validar que su estado de respuesta sea 200, que esté listo y luego continuar con la prueba que requiere ese punto final.

3. Introducción a SCI.INTERCEPT

Short description:

SCI.INTERCEPT es un comando poderoso y flexible en Cypress que te permite interceptar y observar las solicitudes HTTP realizadas por tu aplicación. Puedes declarar un espía con sci.intercept, especificando una URL, método o coincidencia de ruta. Al asignar alias a las solicitudes interceptadas con .as, puedes guardarlas para usarlas más tarde. También puedes esperar a que ocurra una solicitud utilizando SIDOT wait. Esto permite un control preciso y pruebas de las solicitudes de red.

Muy bien, eso fue la solicitud de cierre de sesión, ahora profundicemos en SCI.INTERCEPT. SCI.INTERCEPT es un comando muy poderoso y muy flexible. Hay muchas cosas que puedes hacer con él, así que tenemos mucho que explorar, pero primero hablemos de cómo funciona.

Esta imagen es de una presentación llamada Cómo funciona SCI.INTERCEPT, y básicamente, como puedes ver en la imagen aquí, CIFRS enruta todas las solicitudes HTTP a través de un proxy. Esto te permite literalmente interceptar cualquier solicitud que entre y salga de la ruta desde tu aplicación, el navegador, hacia Internet. Por lo tanto, se pueden observar o lo que llamamos espiar o simular cualquier solicitud, y también te proporciona un controlador de ruta que permite una coincidencia realmente dinámica o controlada de las solicitudes que deseas interceptar, de lo cual hablaremos ahora. Así que primero profundicemos en el espionaje de red. Puedes declarar un espía con sci.intercept. Quieres hacer esto lo más temprano posible en tu código de prueba porque quieres declarar el espía en la solicitud de red antes de que ocurra la solicitud de red. A través del comando sci.intercept, puedes pasar una URL, un método o una coincidencia de ruta. Si no se pasa ningún método, cualquier tipo de método coincidirá. Entonces, si solo pasas un punto final entonces cypress interceptará, solicitud GET, solicitud POST, solicitud por lotes, cualquier cosa que ocurra en ese punto final. Esta será la sintaxis que vamos a ver. Como dije, puedes usar una URL, un método o una coincidencia de ruta. Así que vamos a empezar con solo sci.intercept pasando un punto final. Nuevamente, cualquier tipo de método coincidirá con ese punto final. También puedes especificar el propio método y puedes usar una coincidencia de ruta. Entonces, la coincidencia de ruta es un objeto utilizado para coincidir con las solicitudes HTTP que se manejarán. Es como una combinación de diferentes propiedades opcionales que puedes aprovechar para ser realmente específico en las solicitudes que deseas interceptar. En nuestro ejemplo aquí, estamos aprovechando las propiedades de URL y consulta para decir que solo queremos interceptar solicitudes a esta URL que tengan una propiedad de consulta que coincida con el término esperado. Y así, nuevamente puedes ver cómo puedes ser muy específico aprovechando las propiedades que necesitas para obtener la especificidad que estás buscando.

Una vez que hayas declarado una interceptación, quieres poder aprovecharla y lo haces asignándole un alias con .as. Esto te permite guardar las solicitudes interceptadas para usarlas en todo tu código de prueba. Entonces, lo que se ve es que en el ejemplo que acabamos de mencionar, hemos establecido interceptación pasando nuestra coincidencia de ruta y diciendo que cualquier solicitud de red que coincida con esta ruta que cumpla con este criterio. Queremos guardar eso y queremos darle el nombre de búsqueda. Entonces, ahora tendremos esencialmente esta ruta con alias, esta solicitud con alias llamada búsqueda que podemos aprovechar en todo nuestro código de prueba. Un caso de uso común para eso es esperar, por lo que puedes esperar a que ocurra una solicitud con SIDOT wait. Entonces, después de declarar la interceptación y después de haber asignado un alias, puedes usar SIDOT wait para esperar que esa solicitud ocurra en cualquier parte de tu código de prueba. Entonces, en este ejemplo aquí tenemos SIDOT intercept, estamos diciendo que cualquier solicitud GET a nuestro punto final de usuarios por favor interceptarla y guardarla como obtener usuarios. Luego, en cualquier parte de nuestro código de prueba, ya sabes, podemos activar algo, hacer clic en algunos elementos, divertirnos mucho, y luego podemos esperar y decir

4. Coincidencia dinámica y aliasing en Cypress

Short description:

Y eso esperará a que esa solicitud ocurra realmente desde nuestra aplicación antes de continuar con el código de prueba. El comando Cypress intercept tiene algunos métodos adicionales que están disponibles a través de la API, como REC.alias. Esto te permite asignar un alias a una ruta solo si cumple con los criterios que defines programáticamente. Por ejemplo, puedes asignar un alias a una solicitud como consulta de lista de cuentas bancarias de GraphQL si el cuerpo de la solicitud incluye la propiedad de consulta con el valor lista de cuentas bancarias. Una vez que hayas definido tu interceptación, puedes hacer afirmaciones sobre ella utilizando el estilo encadenado o el método then para acceder a las propiedades de la interceptación.

SIDOT wait en obtener usuarios. Y eso esperará a que esa solicitud ocurra realmente desde nuestra aplicación antes de continuar con el código de prueba.

Muy bien, los ejemplos de los que hemos hablado hasta ahora son básicamente coincidencias estáticas, ¿verdad? Es decir, son criterios que has establecido de antemano al definir esa ruta. También puedes hacer coincidencias dinámicas. Esto es realmente útil específicamente para el aliasing de solicitudes GraphQL. El comando Cypress intercept tiene algunos métodos adicionales que están disponibles a través de la API. Al pasar REC como opción a SIDOT intercept, nos da acceso a esos comandos de la API. Uno de ellos es REC.alias. REC.alias reemplaza el uso de 'as' y te permite asignar un alias a una ruta solo si cumple con los criterios que defines programáticamente.

Veamos a qué me refiero. En nuestro ejemplo, estamos diciendo SIDOT intercept, por favor intercepta cualquier solicitud POST a nuestro punto final de API GraphQL. Si estás familiarizado con GraphQL, normalmente tienes un único punto final que maneja diferentes tipos de consultas y mutaciones. En este caso, vamos a pasar esa propiedad REC para acceder a algunas opciones de la API. De esta manera, podemos hacer una interceptación programática aquí. Vamos a obtener el cuerpo de cualquiera de esas solicitudes y vamos a definir eso y vamos a decir que si el cuerpo tiene una propiedad de consulta y esa propiedad de consulta incluye 'lista de cuentas bancarias', entonces, y solo entonces, queremos asignarle un alias a esa solicitud como consulta de lista de cuentas bancarias de GraphQL. Esto nos permite, nuevamente, obtener dinámicamente una solicitud, decir, ¿tiene esta solicitud lo que necesitamos? Sí, genial. Ahora voy a asignarle un nombre. Y esto sucede en el momento de la solicitud porque, ya sabes, estamos obteniendo una solicitud que se está llevando a cabo, estamos analizando el cuerpo, viendo si coincide con lo que necesitamos. Y luego vamos a asignarle un alias. Así que nuevamente, realmente útil para solicitudes GraphQL específicamente.

Una vez que hayas definido tu interceptación, le hayas dado un nombre, hayas esperado a que ocurra, uno de los casos de uso más comunes, y también puedes hacer afirmaciones sobre ella, ¿verdad? Puedes hacerlo de la misma manera que hicimos para las solicitudes de la API. En este ejemplo, vamos a seguir usando nuestro punto final de obtener usuarios que hemos interceptado y declarado. Vamos a esperar a que ocurra y luego vamos a hacer algunas afirmaciones sobre ella. Podemos usar el estilo encadenado donde decimos que la URL de la solicitud debe incluir 'usuarios'. También puedes acceder a otras propiedades disponibles, como el cuerpo de la solicitud, las cabeceras, el estado, simplemente encadenándolas directamente, o puedes usar el método then y luego obtener la interceptación para acceder a cualquier propiedad de interceptación de nivel inferior. Es decir, la solicitud, la respuesta, las cabeceras, el estado,

5. Solicitudes de red y stubbing

Short description:

Puedes validar el comportamiento de tu aplicación utilizando la sintaxis de afirmación expect en las solicitudes y respuestas. También puedes esperar múltiples solicitudes y usar el mismo alias para manejar diferentes respuestas. El stubbing de red te permite omitir la respuesta real de la red y proporcionar una diferente. Cypress ofrece varias opciones para el stubbing, como usar archivos de fixture, proporcionar un cuerpo JSON o crear una respuesta con propiedades específicas. También puedes stubear respuestas dinámicamente utilizando el método rect.reply y pasar una cadena, objeto o respuesta estática. Esto permite realizar pruebas flexibles y manejar las solicitudes de red.

todo lo que puedas necesitar. Y luego puedes usar esa misma sintaxis de afirmación expect para asegurarte de que la solicitud que se envió o la respuesta que se recibió fue realmente lo que debería haber sido para validar el comportamiento de tu aplicación. Y por último, también puedes esperar múltiples solicitudes. Por ejemplo, ¿sigues usando nuestra ruta obtener usuarios? Sabes, tal vez la primera vez que se ejecuta, debería incluir el usuario uno, pero luego tenemos algún código de prueba adicional o creamos otro usuario. Y luego la segunda vez que se ejecuta, debería incluir el usuario dos. Entonces estamos usando el mismo alias, pero estamos esperando a que la solicitud ocurra varias veces porque podría ser diferente cada vez.

Muy bien. Eso fue sobre las solicitudes de red. Nuevamente, hablamos sobre la interceptación, el alias, la espera y luego hacer afirmaciones sobre las solicitudes que van hacia y desde tu aplicación. Ahora hablemos sobre el stubbing de red. El stubbing de red te permite básicamente omitir la respuesta real de tu red y decir, dale algo más en su lugar. Te permite engañar esencialmente a la interfaz de usuario o al front-end de tu aplicación. Puedes pasar el cuerpo de respuesta a cy.intercept para stubear la respuesta real de la red. Hay muchas opciones diferentes para esto. Voy a repasar algunas de las más populares. La primera es que puedes aprovechar un archivo de fixture de Cypress. Cypress te permite tener activos estáticos que puedes pasar en tu código de prueba. Entonces, en este ejemplo aquí, estamos diciendo cy.intercept, cualquier cosa que vaya a nuestro punto final slash users dot JSON, adelante y stubéalo usando el fixture users dot JSON que tenemos junto a nuestro código de prueba. También puedes stubear la respuesta con un cuerpo JSON, uno que hayas escrito tú mismo que debería coincidir con la respuesta esperada del servidor. Y también puedes crear un cuerpo que aproveche ciertas propiedades. Entonces, si quieres definir un código de estado, cuerpo, cabeceras, puedes hacerlo con un objeto también. Todas esas son respuestas estáticas. Al igual que podemos coincidir dinámicamente con rutas, también podemos stubear dinámicamente. Al igual que teníamos rect.alias, tenemos rect.reply, que es otro método o función que se puede utilizar para enviar una respuesta stubbed para una solicitud interceptada. Puedes pasar una cadena, un objeto o una respuesta estática. Una respuesta estática es un tipo de objeto que te brinda algunas opciones adicionales si deseas hacer cosas como forzar errores de red o retrasar o limitar la respuesta. Pero en la mayoría de los casos, es básicamente para todo lo demás, si una cadena o un objeto no tienen sentido o si deseas algunas opciones adicionales. Entonces, en nuestro ejemplo aquí, nuevamente, estamos interceptando el punto final de facturación. Vamos a pasar rect para tener acceso a esos métodos de la API. Y luego vamos a obtener dinámicamente un nombre de plan de facturación en el momento de la solicitud. Nuevamente, esto es algo que podemos hacer

6. Stubbing dinámico y pros/contras

Short description:

Cuando necesitas stubear respuestas de forma dinámica, puedes usar la función rect.reply. Esto te permite obtener datos de tu interfaz de usuario o validar datos antes de stubear la respuesta. Se pueden manejar y stubear múltiples solicitudes de manera diferente. El interceptor más recientemente definido anulará los stubs anteriores. El stubbing de red tiene pros y contras. Aprovechar las respuestas reales del servidor garantiza una prueba de extremo a extremo real, imitando el entorno de producción. Proporciona una mayor seguridad y confianza en el rendimiento de la aplicación. Sin embargo, requiere declarar datos.

de forma dinámica. Como estamos interceptando esa solicitud, luego obtenemos los data. Y luego respondemos con esos data y detenemos esa respuesta. Esto puede ser, como puedes ver, hay mucha flexibilidad aquí. Pero si por alguna razón no puedes definir esa información de antemano o si necesitas obtener algo de tu interfaz de usuario, o si necesitas validar data antes de stubear la respuesta, puedes hacerlo de forma dinámica utilizando la función rect.reply.

Entonces, nuevamente, el objeto se convertirá automáticamente en una cadena JSON y se enviará como la respuesta en lugar de la respuesta real del servidor para esa solicitud. También puedes manejar múltiples solicitudes. De la misma manera que puedes esperar múltiples solicitudes, puedes manejar múltiples solicitudes y stubearlas de manera diferente. Entonces, a partir de la versión 7.0, tenemos esta opción y los controladores de solicitudes suministrados a interceptar se emparejarán, comenzando con el interceptor más recientemente definido. Esto permite a los usuarios anular el stub anterior llamándolo nuevamente. Entonces, en nuestro ejemplo aquí, declaramos una interceptación en nuestro punto final de inicio de sesión. Lo estamos stubeando con el nombre de usuario uno y lo guardamos como inicio de sesión. Vamos a tener algún código de prueba aquí, y luego esperaremos a que se produzca esa solicitud de inicio de sesión y debería tener el nombre de usuario uno porque esa es nuestra respuesta stubeada. Luego declaramos la interceptación nuevamente, esta vez pasando el nombre de usuario dos. Esto va a anular esa primera interceptación. Nuevamente, lo guardamos como inicio de sesión, estamos usando el mismo alias. Y luego, esta vez, después de haber realizado algún código de prueba para activar esa respuesta, vamos a esperarla nuevamente. Y esta vez, tendrá el nombre de usuario dos, porque ese segundo interceptador de Cylot ha vuelto a anular el primero. Entonces podemos stubear respuestas de diferentes maneras en todo nuestro código de prueba, dependiendo de lo que necesitemos. Cosas muy interesantes.

Muy bien, hablamos sobre el stubbing de red. Ahora hablemos de los pros y contras. ¿Cuándo querrías hacerlo? ¿Cuándo no querrías hacer stubbing de red? El primer enfoque es aprovechar las respuestas reales del servidor. Esto es, ya sabes, una prueba de extremo a extremo real. Esto es, um, no aprovechar el stubbing de red en absoluto, dejar que todas las API reales, todas las respuestas reales del servidor vuelvan y pasar por tus pruebas de esa manera. Garantiza que el contrato entre tu cliente y tu servidor o tu front-end y tu back-end esté funcionando correctamente. Entonces, algunos de los pros, ¿verdad? Es más probable que funcione en producción. Por lo tanto, tus pruebas van a imitar mejor tu entorno de producción real y luego, ya sabes, proporcionar una mejor seguridad de que tus pruebas funcionarán de la misma manera que tu aplicación va a funcionar y que tienes más confianza en que el usuario tendrá la experiencia que espera. Obtienes cobertura de prueba en los puntos finales del servidor y es excelente para la representación tradicional del lado del servidor HTML. Se vuelve realmente difícil stubear mucho HTML si no estás utilizando respuestas reales del servidor. Hay algunos contras, ¿verdad? Entonces, requiere declarar data.

7. Solicitudes de red y stubbing

Short description:

Si estás utilizando un backend real, es más lento y más difícil probar casos límite a través de la interfaz de usuario. El stubbing de respuestas permite tener control y pruebas más rápidas. Sin embargo, los datos stub pueden no coincidir con los datos reales y no son útiles para la representación en el lado del servidor. La sugerencia es combinar ambos enfoques, con una prueba real de extremo a extremo para los caminos críticos y stubbing para todo lo demás.

Si estás utilizando un backend real, vas a necesitar datos reales. Definitivamente será mucho más lento porque estás completando solicitudes de red reales. Tienes que esperar a que la API responda. También es más difícil probar casos límite porque tienes que forzar esos casos límite a través de la interfaz de usuario. Tienes que hacer que esos casos límite ocurran a través de la aplicación en lugar de crearlos mediante respuestas stub.

Entonces, la sugerencia es usarlo con moderación. Es genial para los caminos críticos de tu aplicación cuando realmente necesitas esa cobertura real de extremo a extremo.

El siguiente enfoque es stubear tus respuestas. Esto te permite controlar todos los aspectos de la respuesta. Como vimos con SIN e intercepts, puedes stubear de la manera que desees. Es una excelente manera de controlar los datos que se devuelven al frontend de tu aplicación.

Los pros, obviamente, es que obtienes ese control. Puedes forzar ciertos comportamientos de respuesta como retrasos de red. No tienes que preocuparte por cambios de código en tu servidor. Incluso puedes comenzar a probar el frontend de tu aplicación antes de que el servidor o el backend estén completos. También es mucho, mucho, mucho más rápido. Pero obviamente, no tendrás garantías de que tus datos stub coincidan con los datos reales. No tendrás cobertura de prueba en algunos puntos finales del servidor. Tampoco es tan útil para una representación tradicional de HTML en el lado del servidor.

La sugerencia aquí es combinar ambos enfoques. Tener una prueba real de extremo a extremo para esos caminos críticos y luego stubear todo lo demás. Darte una semana de pruebas mucho más rápida. Darte ese control que necesitas.

Muy bien. Esto ha sido Solicitudes de red con Cypress. Una vez más, soy Cecilia Martinez. Muchas gracias por tu tiempo y espero que esto te sea útil.

8. Resultados de la encuesta y conferencias virtuales

Short description:

Las conferencias virtuales me han facilitado asistir a más de cuatro conferencias tecnológicas. La mayoría de las personas han asistido a una o tres conferencias, y algunas están asistiendo a su primera conferencia. Estar en línea ha abierto oportunidades para los oradores y diferentes tipos de eventos. Es una experiencia diferente ahora.

Qué charla tan fantástica, claramente una herramienta muy versátil. Pero antes de sumergirnos en las preguntas y respuestas, vamos a traer a Cecilia y echemos un vistazo a los resultados de la encuesta. Hola, Cecilia. Así que preguntaste a la gente cuántas conferencias tecnológicas han asistido. Antes de ver los resultados, ¿cuántas has asistido tú? Oh, definitivamente estoy en esa categoría de más de cuatro. Para mí, las conferencias virtuales como esta me han facilitado mucho asistir a muchas más. Así que creo que probablemente he perdido la cuenta en este punto, para ser honesta. ¿Y qué opinas de los resultados? Sí. OK. Así que la mayoría de las personas parecen estar en esa categoría de una a tres conferencias. Parece que también tenemos bastantes personas que están asistiendo a su primera conferencia, lo cual es bastante emocionante. Elegimos una buena opción al venir aquí y echar un vistazo. Así que sí. Sí. Parece que también tenemos algunas personas que están en esa categoría de más de cuatro aunque tal vez no tantas. Y lo mismo que tú, estar en línea ha abierto muchas puertas para los oradores y diferentes tipos de eventos. Así que sí, he asistido a muchas. Pero todo es diferente en este momento, ¿verdad? Así que tenemos algunas preguntas para ti.

9. Logging Request Responses in Cypress

Short description:

Puedes registrar las respuestas de las solicitudes utilizando el comando site outlog. Esto te permite registrar las respuestas en el registro de comandos de Cypress y en tu salida. Hay varias herramientas disponibles para registrar las respuestas. También puedes capturar y aprovechar las respuestas con fines de documentación y validación.

Y no me sorprende porque, como mencionaste en tu charla, esta característica se puede utilizar para muchas cosas. Así que vamos a empezar con Malcolm. Él preguntó cómo podemos registrar las respuestas de las solicitudes o si podemos hacerlo. Sí, absolutamente. Hay un par de opciones diferentes, ¿verdad? Puedes utilizar el comando site outlog que te permite registrar eso en el registro de comandos de Cypress, si también quieres registrar eso en tu salida. Tenemos algunas opciones allí. Hay varias herramientas diferentes que puedes utilizar. También siempre puedes capturar esas respuestas y aprovecharlas de diferentes maneras. Por ejemplo, si necesitas documentarlas o validarlas. Así que además de eso, el registro probablemente sea la parte más amigable para el usuario, pero sí, también hay algunas opciones adicionales dependiendo de dónde quieras registrar esas respuestas.

QnA

Testing Front End and Backend API

Short description:

Existen diferentes enfoques para probar la API del front-end y del backend. Depende de tus objetivos y del contexto de tu proyecto. Si solo te importa probar la funcionalidad del front-end, simular el backend es un enfoque válido. Si deseas asegurar toda la funcionalidad de extremo a extremo, puedes combinar pruebas de extremo a extremo, pruebas de API y pruebas de interfaz de usuario del front-end simuladas. El mejor enfoque depende de los riesgos que estés tratando de mitigar. Cuando verificas que no se haya enviado una solicitud, es difícil demostrar que algo no ocurrió. Una forma es declarar la ruta y escribir una función personalizada para contar las ocurrencias. Si el recuento se mantiene en cero, indica que la solicitud no ocurrió. Sin embargo, si necesitas verificar que algo no haya ocurrido, sugiere que puede haber aspectos no deterministas en la prueba.

aspecto de ello, pero sí, también hay algunas opciones adicionales dependiendo de dónde quieras registrar esas respuestas.

Fantástico. Tenemos una pregunta de refactor Eric. ¿Es recomendable probar el front-end de toda la API del backend simulada, por supuesto, acompañada de algunas pruebas reales de extremo a extremo para los flujos de usuario críticos? Sí, creo que esto se remonta a la charla de Lev y Roman anteriormente sobre cómo no hay realmente un enfoque único o una respuesta sólida buena en cualquier caso. Todo depende del contexto, ¿verdad, de lo que estás tratando de hacer? Así que cuando hablo con los usuarios todo el tiempo, les digo, ¿cuál es tu objetivo para esa prueba? ¿Y cuál es tu objetivo para tu barrido de pruebas y lo que estás tratando de abordar? Entonces, si estás buscando probar la funcionalidad de tu front-end y no te importa el backend, entonces absolutamente, es totalmente válido simular completamente tu backend. Veo esa implementación muy a menudo. La gente dice, ya sabes, estamos usando microservicios en el backend, o es un equipo completamente diferente, y solo queremos asegurarnos de que nuestra parte esté funcionando correctamente. Si tu objetivo es asegurarte de que tienes todo el funcionamiento de extremo a extremo correctamente, entonces sí, veo ese enfoque muy a menudo también, donde tienes algunos flujos de usuario críticos cubiertos con pruebas de extremo a extremo, luego tienes algunas pruebas de API separadas para los puntos finales que se utilizan mucho, que tal vez tienen lógica empresarial compleja en la que deseas hacer algunas pruebas de unidad y asegurarte de que eso funcione para cubrir todos los casos límite. Y luego tienes tus pruebas de interfaz de usuario simuladas del front-end también para asegurarte de que todo se vea bien, tal vez agregar algunas pruebas visuales allí para asegurarte de que todo se renderice correctamente. Y sí, ese es un enfoque muy válido. Pero nuevamente, la respuesta siempre va a ser, depende, porque siempre habrá contexto en torno a tus objetivos. Sí, y si puedo agregar algo, creo que lo clave para mí es la palabra riesgo. ¿Cuál es el riesgo que estás tratando de mitigar? ¿Es el riesgo en la interfaz de usuario? ¿Es la interfaz de usuario completa y la API? Una vez que identificas dónde está el riesgo, generalmente se responde sobre el mejor enfoque. Pero nuevamente, estás mostrando que Cypress es versátil y puede manejar múltiples formas. ¡Fantástico! Así que TesterJS tiene otra pregunta. Oh, no, lo siento. Me he saltado uno. Entonces, Harlow, hay muchas formas de verificar que se haya enviado una solicitud, pero no parece haber una receta para verificar que no se haya enviado una solicitud. ¿Cuál es la mejor manera de hacerlo en Cypress? Hay formas de hacerlo. Así que cuando la gente me pregunta cómo puedo hacer esto, ¿cómo hago eso? Muchas veces les pregunto por qué están tratando de hacer eso, porque... Eso es lo que estoy pensando, ¿por qué? Porque puedo responder a tu pregunta. Sí, hay un par de formas diferentes. No es fácil, seguro. Siempre es difícil demostrar algo que no es cierto o demostrar que algo no ocurrió. ¿Verdad? Siempre es como, ya sabes, demuestra que esto no sucedió. Una de las formas que he visto es declarar esa ruta y luego escribir una función personalizada para establecer el recuento, el número de veces que ha ocurrido. Si se mantiene en cero, entonces puedes ver que no ha ocurrido. Pero realmente, si tienes una verificación de que algo no ha ocurrido, entonces probablemente haya algo realmente no determinista en esa prueba.

Understanding Network Requests and Assertions

Short description:

Si ocurre una solicitud de red y no debería ocurrir, es posible afirmar que no ha ocurrido. Sin embargo, es importante cuestionar el caso de uso y comprender el propósito detrás de ello. Es común querer ver las respuestas que se envían, especialmente en las pruebas móviles. La confianza en la interfaz de usuario y el sitio web es una consideración clave. Hay muchas preguntas que explorar al respecto.

Y tal vez sea necesario comprender los requisitos de tu aplicación y lo que estás probando. Porque si ocurre una solicitud de red y no debería ocurrir, y solo necesitas afirmar que no ha ocurrido, cuestionaría ese caso de uso y entendería más sobre lo que estás tratando de lograr con eso. Técnicamente, es posible, pero realmente cuestiona por qué querrías hacer eso.

Genial. Sí, no podría estar más de acuerdo. A veces lo he visto en dispositivos móviles, cuando quieres ver las respuestas que se envían porque te preguntas: ¿confío en esta interfaz de usuario? ¿Confío en este sitio web? Pero sí, siento que hay algo positivo en lo que deberíamos enfocarnos. Entonces, ¿por qué nos preocupa que se haya enviado en algún momento? Hay tantas preguntas que hacer. Respuesta genial.

Manejo de la Longitud de la Lista y Traversía del DOM en Cypress

Short description:

Tuve un desafío en Cypress para acceder a la longitud de dos listas. Las propiedades como la longitud solo son accesibles mediante .them, lo que resulta en una cadena de .thems e ifs. El uso de selectores adecuados y comprender el elemento objetivo puede simplificar la traversía del DOM. La gestión de datos de prueba ayuda con la representación no determinista. Considera utilizar los comandos .its y .children para mayor flexibilidad.

Entonces, Tester.js, ahora vuelvo a ti. Hace algún tiempo, tuve un gran desafío en Cypress para acceder a la longitud de dos listas porque las propiedades como la longitud solo son accesibles mediante .them. Por lo tanto, para acceder a listas desde otra lista, tenías que terminar con una cadena de .thems y luego una cadena de ifs que no es muy limpia. Me llevó mucho tiempo y no pude encontrar una mejor manera de hacerlo, ¿algún tips?

Eso no tiene sentido para mí, espero que lo entiendas. Supongo que probablemente querría obtener un poco más de detalle, pero sé que también puedes aprovechar .its para obtener propiedades de un sujeto. Y luego, otra cosa a tener en cuenta también es si estás tratando de obtener la longitud de algo y luego tal vez meterte en él de nuevo, no estoy seguro de cuál sería el caso de uso allí. Es difícil de entender sin ver el código. Pero hay un par de cosas que están en mi mente, ¿verdad? Si estás utilizando selectores realmente buenos y puedes acceder a lo que sea que sea esa segunda lista, por así decirlo, o si puedes ser un poco determinista acerca de lo que estás obteniendo. Parece que tal vez lo que está sucediendo es que alguien está seleccionando una primera lista, obteniendo su longitud para entender qué elemento de esa lista necesitan obtener y luego intentando obtener otro elemento dentro de ella. Tal vez sea un poco difícil de entender, como dije. Definitivamente puedes usar .its. También puedes ejecutar, como usar un comando .children para ver qué hijos están disponibles en esa lista y analizarlo de esa manera. Pero siempre recomiendo nuevamente, es como tener selectores realmente buenos y comprender qué elemento estás tratando de seleccionar para no tener que hacer tanta traversía del DOM. Dicho esto, no siempre es fácil. Si no tienes acceso al código fuente, si, si va a ser una representación realmente no determinista, ahí es donde entra en juego una buena gestión de datos de prueba donde puedes saber qué se va a representar en tu aplicación y en tu entorno de prueba y ser más determinista de esa manera. Pero diría que eches un vistazo a .its y eches un vistazo a algunos de los, como .children si tienes que hacer mucha traversía del DOM porque esos serían más flexibles para ti que .pen. Ahora entiendo la pregunta. Pensé que las listas eran una característica en Cypress. Realmente significa una lista en el sitio web. Creo que de eso está hablando. Sí. Oh, no tienen idea de quiénes son de qué pueden estar hablando.

Manejo de la Carga Perezosa y el Stubbing en Cypress

Short description:

Melad tiene una pregunta sobre la carga perezosa en Cypress. La carga perezosa se puede manejar desplazándose a la vista o enviando la acción que activa la carga del componente. Es crucial comprender la aplicación y lo que activa la carga del componente. Es importante considerar el estado y si es necesario probar la carga perezosa. Las solicitudes y respuestas HTTPS se pueden stubbar, y un método de intercepción general se puede almacenar como un comando personalizado para su uso en diferentes pruebas con modificaciones variables.

Excelente. Muy bien, Melad tiene nuestra próxima pregunta y también noticias para ti. Comenzaron a usar Cypress hace tres meses. Sin embargo, tienen un problema cuando lo uso que es que no puedo manejar la carga perezosa. La única opción que conozco es el comando wait pero la carga perezosa no carga los componentes en el tiempo exacto. ¿Tienes alguna recomendación para manejar la carga perezosa?

Sí, esto es algo que estamos viendo cada vez más con los modernos frameworks de front-end que utilizan la carga perezosa o, por ejemplo, a veces es necesario desplazarse a la vista para activar la carga. De hecho, creo que Gleb recientemente hizo una publicación en el blog o podría hablar en un video sobre esto para cargar dinámicamente los resultados en la página. Y así, con los resultados de búsqueda, te desplazarías hacia abajo, esperarías a que se carguen, te desplazarías hacia abajo, esperarías a que se rendericen. Y también hay algunas otras cosas que puedes hacer. Si estás utilizando un almacén de front-end como Vuex o si estás utilizando Redux, puedes acceder a tu almacén de front-end y forzar que se active algo para cargar algo. Entonces, si sabes qué acción se envía para renderizar ese componente, puedes enviar manualmente esa acción a Cypress para forzar que suceda. Y luego siempre habrá una afirmación de que el DOM está listo. Y así, la carga perezosa puede ser difícil pero si comprendes qué activará la carga de ese componente, entonces realmente puedes trabajar con eso para asegurarte de que aparezca en la pantalla, ya sea desplazándote, haciendo clic. A veces he visto a personas que escriben en el botón, pero luego lo que hacen clic no es realmente el elemento que se carga, que dispara el evento. Entonces, simplemente no están seleccionando el elemento correcto. Así que gran parte de eso es comprender realmente tu aplicación y qué causa que se carguen esos componentes.

No podría estar más de acuerdo. Como comprender el estado, una vez que conoces el estado y también a veces ¿estás tratando de probar la carga perezosa? ¿Puedes desactivarla? Porque a veces estas cosas solo están ahí para ser agradables de tener, ya sabes, un poco de estilo, un poco de elegancia, pero si no estás tratando de probar el estilo elegante, desactívalo, haz tu vida más fácil, facilita la prueba de estas aplicaciones. Ese es un punto muy válido, Richard, sin duda. Es como, ¿qué estás tratando de probar, verdad? Y si no es necesario probarlo, entonces tal vez no habilites eso en tu entorno de prueba. Así que eso es, eso es un buen punto. Exactamente. Pregunta de Amanda Law. Espero que sea una pregunta relativamente sencilla, supongo, pero ¿se pueden stubbar las solicitudes y respuestas HTTPS? Sí, absolutamente. Sí, eso es en realidad, creo que una de las opciones en esa coincidencia dinámica que mencioné es para que HTTPS solo coincida con las solicitudes seguras, creo. Jobs nos está preguntando, ¿es posible almacenar un método de intercepción general y llamarlo en diferentes pruebas con una ligera modificación de las variables? Sí, recomendaría algo como un comando personalizado para eso. Entonces, en Cypress, puedes declarar comandos personalizados. Así que recomendaría pasar, por ejemplo, si quieres un cierto parámetro de consulta y llamarlo como sci.intercept con consulta y luego puedes pasar los parámetros de consulta y declarar el sci.intercept allí. Pero sí, absolutamente. Excelente.

Documentación para principiantes de Cypress

Short description:

¿Hay documentación para principiantes para alguien nuevo en Cypress? Sí, en docs.cypress.io. Además, Test Automation University ofrece cursos de Cypress. Gracias, Cecilia, por la excelente charla y sesión de preguntas y respuestas.

Podemos tener tiempo para una pregunta más de Malcolm. ¿Hay documentación para principiantes para alguien nuevo en Cypress? ¿Hay documentación para principiantes para alguien nuevo en Cypress? Sí, en docs.cypress.io. Así es como aprendí Cypress cuando recién estaba comenzando, sin duda. Además, ya sabes, Test Automation University es una plataforma gratuita que ofrece algunos cursos sobre Cypress. Tienen un curso para principiantes y uno de nuestros embajadores de Cypress acaba de lanzar un curso más avanzado en Test Automation University, así que... También hay uno en este sitio web. En fin...

¡Genial! Muchas gracias, Cecilia. Realmente disfruté esa charla. Respuestas realmente fantásticas en la sesión de preguntas y respuestas, así que gracias por unirte a nosotros. Sí, absolutamente, muchas gracias y espero que todos tengan un gran evento.

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
38 min
Testing Pyramid Makes Little Sense, What We Can Use Instead
Top Content
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
Top Content
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
Top Content
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.
TestJS Summit 2022TestJS Summit 2022
21 min
Tiny Tests, Large Results
Yes, Big things do come in small packages. For example, isn’t a unit test’s speed, feedback, and reliability fantastic? Did you know we can also have fast, focused, and reliable feedback from our functional e2e tests? Atomic e2e tests are those that are targeted and focused. They’re tiny in size but large in their impact. This tutorial will teach you how to create atomic e2e tests with several code examples. First, we will use Cypress.io to authenticate by setting a cookie. Instead of using a UI. Second, we will use Cypress.io to set a JSON Web Token for authentication. Join me, and let’s write tiny tests for large results.

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
Top Content
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.