Solicitudes de Red con Cypress

Hola, soy Cecilia Martinez, y soy una gerente de cuentas técnicas en Cypress. Y estoy realmente emocionada de estar aquí hoy para hablarles sobre las solicitudes de red con Cypress. He hecho las diapositivas para la presentación disponibles en la URL en la pantalla, y puedes conectarte conmigo en Twitter en Cecilia Creates.

Entonces, para aquellos de ustedes que no están familiarizados con Cypress, es un framework open-source gratuito 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 de usuario gráfica 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 suena es un registro de todos los comandos que tu code de prueba está ejecutando contra tu aplicación. Esto nos da buena información sobre las solicitudes de red que están ocurriendo dentro de tu aplicación a medida que avanzan las pruebas. Entonces, 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 code de prueba ha hecho clic en un elemento, ocurrió una solicitud de post. Podemos ver el code de estado, podemos ver el punto final, así como cómo podemos o no estar interactuando con esa solicitud a través de nuestro code de prueba. También podemos hacer clic en cualquier solicitud en el registro de comandos para enviarla a la console. Esto te da información adicional útil como encabezados de solicitud, cuerpo de respuesta, que puede ser útil cuando estás solucionando problemas o debugging pruebas fallidas, o tratando de entender mejor qué está pasando con las solicitudes de red de tu aplicación.

Entonces, además de ver las solicitudes de red dentro del corredor de pruebas de Cypress, también puedes interactuar con ellas. Entonces, vamos a hablar de dos comandos hoy que te permiten trabajar con 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, estaré usando algo de code de la aplicación real world de Cypress. La aplicación real world de Cypress es un gran recurso. Fue desarrollada por nuestro equipo de Developer Experience. Es una aplicación completa de React que muestra las best practices, casos de uso, y luego esencialmente todas las diferentes cosas que puedes hacer con Cypress. Entonces, es de código abierto. Entonces, si vas al enlace de github en la pantalla, puedes ver el code fuente así como un conjunto completo de pruebas de UI y API para la aplicación. Es una aplicación de pago estilo Venmo. Entonces, estás lidiando con cosas como usuarios, transacciones, cuentas bancarias, y mucho

Entonces, ¿por qué usarías cydot request? El caso de uso más popular es en realidad para pruebas de API. Aunque Cypress, es mayormente conocido por las pruebas de UI y de extremo a extremo, también puedes usar el comando cydot request, junto con el mismo lenguaje de aserción con el que estás familiarizado, para validar las respuestas que vienen de tus endpoints de servidor. Entonces, en el ejemplo aquí, esto viene directamente del conjunto de pruebas de API en nuestra aplicación real-world de Cypress. Estamos validando una solicitud GET a nuestro endpoint de cuentas bancarias, y el bloque para 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 endpoint. Y luego, estamos obteniendo la respuesta y estamos haciendo aserciones contra ella. Entonces, esperamos que ese estado de respuesta sea igual a 200. Y esperamos que el cuerpo de la respuesta contenga el ID del usuario en los resultados. Entonces, de nuevo, puedes aprovechar la misma sintaxis de Cypress que estás acostumbrado para pruebas de API junto a tu conjunto de pruebas de UI. También puedes usarlo para recuperar, crear o actualizar data para testing.

Entonces, la gestión de data de prueba es un tema realmente popular cuando se trata de testing, especialmente cuando estás haciendo pruebas de extremo a extremo. Y entonces, si necesitas recuperar data de un endpoint, 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 probarlo, 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 endpoints antes de proceder con tu prueba. Entonces, si tienes quizás un endpoint o backend poco fiable que podría ser más lento o estar caído, o si estás usando un servicio de terceros o microservicio y solo quieres asegurarte de que todo está listo antes de proceder con tu prueba, puedes disparar una solicitud de cierre de sesión validar que su estado de respuesta es 200, que está listo para funcionar, y luego seguir adelante y proceder con la prueba que requiere ese endpoint.

Muy bien, eso fue sign-out request, ahora vamos a profundizar en SCI.INTERCEPT. SCI.INTERCEPT es un comando muy potente, muy flexible. Hay muchas cosas que puedes hacer con él, así que tenemos bastante que abordar, pero primero hablemos de cómo funciona.

Así que esta imagen es de una presentación llamada Cómo funciona SCI.INTERCEPT, y esencialmente como puedes ver en la imagen aquí, CIFRS enruta todas las solicitudes HTTP a través de un proxy. Así que te permite esencialmente interceptar literalmente cualquier solicitud que entra y sale de la ruta desde tu aplicación, el navegador, hasta internet. Así que cualquier solicitud puede ser observada o lo que llamamos espiada o falsificada y luego también te proporciona un manejador de ruta que permite un emparejamiento realmente dinámico o realmente controlado de las solicitudes que te gustaría interceptar, de las que hablaremos ahora. Así que primero vamos a profundizar en el espionaje de red. Así que puedes declarar un espía con sci.intercept. Quieres hacer esto lo más temprano posible en tu test code 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 un coincidente de ruta. Si no se pasa ningún método, entonces cualquier tipo de método coincidirá. Así que si solo pasas un endpoint entonces cypress interceptará, obtendrá la solicitud, publicará la solicitud, solicitará el lote, lo que sea que ocurra en ese endpoint. Así que esta va a ser la sintaxis que vamos a mirar. Como dije, puedes hacer una URL, un método, o un coincidente de ruta. Así que vamos a empezar con solo sci.intercept pasa un endpoint. De nuevo cualquier tipo de método coincidirá con ese endpoint. También puedes especificar el método en sí y puedes usar un coincidente de ruta. Así que el coincidente de ruta es un objeto usado para coincidir qué solicitudes HTTP serán manejadas. Así que es como una mezcla y combinación de diferentes propiedades opcionales que puedes aprovechar para ser realmente muy granular alrededor de las solicitudes que te gustaría interceptar. Así que en nuestro ejemplo aquí estamos aprovechando las propiedades de URL y de consulta para decir que solo queremos interceptar solicitudes a esta URL que tienen una propiedad de consulta que coincide con el término esperado. Y así de nuevo puedes ver cómo puedes ser muy, muy específico aprovechando las propiedades que necesitas que te den la especificidad que estás buscando.

Así que una vez que has declarado una interceptación, quieres poder aprovecharla y lo haces asignándole un alias con .as. Así que te permite guardar las solicitudes interceptadas para usarlas a lo largo de tu test code. Así que lo que eso parece es que en el ejemplo de que acabamos de hablar hemos establecido interceptamos estamos pasando a través de nuestro coincidente de ruta y estamos diciendo que cualquier solicitud de red que coincida con esta ruta que coincida con estos criterios. Queremos guardar eso y queremos darle un nombre de búsqueda. Así que ahora tendremos esencialmente esta ruta con alias esta solicitud con alias llamada búsqueda que podemos aprovechar a lo largo de nuestro test code. Un caso de uso común para eso es esperar así que puedes esperar a que ocurra una solicitud con SIDOT wait. Así que después de declarar la interceptación y después de haber dado un alias entonces puedes usar SIDOT wait para esperar a que ocurra esa solicitud en cualquier lugar de tu test code. Así que en este ejemplo aquí tenemos SIDOT intercept estamos diciendo que cualquier solicitud get a nuestro endpoint de usuarios por favor intercepta eso y guárdalo como get users. Entonces en cualquier lugar de nuestro test code, sabes que podemos desencadenar algo, hacer clic en algunos elementos, pasar un buen rato, y luego podemos esperar y decir

Muy bien, los ejemplos de los que hemos hablado hasta ahora son esencialmente coincidencias estáticas, ¿verdad? Así son criterios que has establecido de antemano cuando estás definiendo esa ruta. También puedes hacer coincidencias dinámicas. Esto es realmente útil específicamente para dar alias a las solicitudes de GraphQL. Así que el comando intercept de Cypress tiene algunos métodos adicionales que están disponibles a través de la API. Así que REC, al pasar esa opción REC a SIDOT intercept, nos da acceso a esos comandos de la API. Uno de ellos es REC.alias. Así que REC.alias reemplaza a dot as para permitir dar un alias a una ruta solo si coincide con los criterios que estás definiendo programáticamente.

Así que veamos a qué me refiero. En nuestro ejemplo, estamos diciendo SIDOT intercept, por favor intercepta cualquier solicitud post a nuestro endpoint de la API GraphQL. Si estás familiarizado con GraphQL, normalmente tienes un solo endpoint que maneja muchos tipos diferentes de consultas y mutaciones. Así que en este caso, vamos a pasar esa propiedad REC para acceder a algunas opciones de la API. Así que podemos hacer un poco de interceptación programática aquí. Así que vamos a ir adelante y tomar el cuerpo de cualquiera de esas solicitudes. Vamos a definir eso y vamos a decir si el cuerpo tiene una propiedad de consulta y esa propiedad de consulta incluye lista de cuentas bancarias, entonces, y solo entonces, queremos dar un alias a esa solicitud como consulta de lista de cuentas bancarias de GraphQL. Así que esto nos permite, de nuevo, tomar dinámicamente una solicitud, decir, hey, ¿esta solicitud realmente tiene lo que necesitamos? Sí. Genial. Ahora voy a ir adelante y nombrar eso. Y de nuevo, eso está sucediendo en el momento de la solicitud porque, ya sabes, esencialmente estamos tomando una solicitud que está teniendo lugar, estamos analizando el cuerpo, viendo si coincide con lo que necesitamos que coincida. Y luego vamos a darle un alias. Así que de nuevo, realmente útil para las solicitudes de GraphQL específicamente.

Así que una vez que has definido tu interceptación, le has dado un nombre, has esperado por ella. Uno de los usos más comunes y luego también puedes hacer afirmaciones sobre ella, ¿verdad? Así que puedes hacer eso de la misma manera similar que hicimos para las solicitudes de la API. Así que en este ejemplo, vamos a seguir utilizando nuestro endpoint de get users que hemos declarado la interceptación. Vamos a esperar por ella. Y luego vamos a hacer algunas afirmaciones sobre ella. Así que podemos usar el estilo de cadena donde estamos diciendo que es solicitud que la URL debería incluir usuarios. Esto puede ser ciertas cosas que están disponibles para ello, como el cuerpo de la solicitud, el estado de la solicitud que puedes encadenar directamente, o puedes usar un dot then, y luego tomar la interceptación para acceder a cualquiera de las propiedades de nivel inferior de la interceptación. Así que eso sería la solicitud, la respuesta, los encabezados, el estado,

Muy bien. Así que eso fueron las solicitudes de red. Nuevamente, hablamos de interceptar, dar alias, esperar y luego hacer afirmaciones sobre las solicitudes que van y vienen de tu aplicación. Ahora hablemos de los simulacros de red. Así que los simulacros de red te permiten esencialmente eludir la respuesta real de tu red y decir, dale algo más en su lugar. Te permite esencialmente engañar a la UI o al front end de tu aplicación. Así que puedes pasar el cuerpo de la respuesta a cy.intercept para simular 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. Así que Cypress te permite esencialmente tener activos estáticos que puedes pasar en tu prueba code. Así que en este ejemplo aquí, estamos diciendo cy.intercept, cualquier cosa que vaya a nuestro endpoint slash users dot JSON, adelante y simula eso usando el fixture users dot JSON que tenemos junto a nuestro código de prueba. También puedes simular la respuesta con un cuerpo JSON, simplemente uno que hayas escrito tú mismo que debería coincidir con lo que se espera que sea la respuesta del servidor. Y luego también puedes esencialmente crear un cuerpo que aproveche ciertas propiedades. Así si quisieras definir un estado code cuerpo encabezados, puedes hacerlo con un objeto también. Esas son todas respuestas estáticas. Al igual que podríamos hacer coincidencias dinámicas de rutas, también podemos hacer simulacros dinámicos. Así que 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 simulada 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 da algunas opciones adicionales si quieres hacer cosas como forzar errores de red o retrasar o limitar la respuesta. Pero en la mayoría de los casos, es esencialmente para todo lo demás, si una cadena o un objeto no tiene sentido o si quieres algunas opciones adicionales. Así que en nuestro ejemplo aquí, de nuevo, estamos interceptando al endpoint de facturación. Vamos a pasar a través de rect para que tengamos 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. Así que de nuevo, esto es algo que podemos hacer

Entonces, de nuevo, 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 simularlas de manera diferente. Entonces, a partir de la versión 7.0, tenemos esta opción y luego los manejadores de solicitudes suministrados a Santa interceptarán, comenzando con el interceptor más recientemente definido. Esto permite a los usuarios anular el simulacro anterior llamándolo de nuevo. Entonces, en nuestro ejemplo aquí, declaramos una interceptación a nuestro punto final de inicio de sesión. Lo estamos simulando con el nombre de usuario uno, y lo estamos guardando como inicio de sesión. Vamos a seguir, luego tendremos algún code de prueba aquí, y luego vamos a esperar a que ocurra esa solicitud de inicio de sesión y debería tener el nombre de usuario uno porque esa es nuestra respuesta simulada. Luego estamos declarando la interceptación de nuevo, esta vez pasando el nombre de usuario dos. Esto va a anular esa primera interceptación. De nuevo, lo estamos guardando como inicio de sesión de nuevo, estamos usando el mismo alias. Y luego esta vez, después de haber hecho algún code de prueba para desencadenar esa respuesta, vamos a seguir adelante y esperarla de nuevo. Y esta vez, va a tener el nombre de usuario dos, porque esa segunda interceptación de Cylot ha anulado la primera. Entonces, somos capaces de simular respuestas de múltiples maneras diferentes a lo largo de nuestro code de prueba, dependiendo de lo que necesitemos. Cosas muy interesantes.

Muy bien, entonces hablamos de simulacro de red. Hablemos de los pros y los contras de ello. ¿Cuándo querrías hacerlo? ¿Cuándo no querrías hacer simulacro de red? Entonces, el primer enfoque es aprovechar tus respuestas reales del servidor. Esto es, sabes, una verdadera prueba de extremo a extremo. Esto es, um, no aprovechar el simulacro de red en absoluto, dejando que todas las respuestas reales de la API, todas las respuestas reales del servidor vuelvan y pasen por tu prueba 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, ¿cuáles son los pros? Es más probable que funcione en producción. Entonces, tu prueba va a imitar mejor tu entorno de producción real y luego, sabes, proporcionará una mejor garantía de que tus pruebas van a funcionar de la misma manera que tu aplicación va a funcionar y que tienes más confianza de que el usuario va a tener la experiencia que espera. Obtienes cobertura de prueba alrededor de los puntos finales del servidor y es genial para la renderización tradicional del lado del servidor en HTML. Se vuelve realmente difícil simular mucho HTML si no estás utilizando respuestas reales del servidor. Hay algunos contras, ¿verdad? Requiere declarar data.

Si estás utilizando un back end real, vas a necesitar datos reales. Definitivamente va a 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 UI. Tienes que forzar esos casos límite a través de la aplicación en lugar de crearlos a través de respuestas simuladas.

Por lo tanto, el uso sugerido es usarlo con moderación. Es genial para los caminos críticos de tu aplicación cuando realmente necesitas esa cobertura de extremo a extremo.

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

Las ventajas, obviamente, obtienes ese control. Puedes forzar ciertos comportamientos de respuesta como retrasos en la red. No tienes que preocuparte por los cambios de código en tu servidor. Incluso puedes empezar a probar el front end de tu aplicación antes de que el servidor o el back end estén completados. También es mucho, mucho, mucho, mucho más rápido. Pero obviamente, no vas a tener garantías de que tus datos simulados coincidan con los datos reales. No vas a tener cobertura de prueba en algunos puntos finales del servidor. También no es tan útil para una renderización tradicional del lado del servidor en HTML.

La sugerencia aquí es mezclar y combinar. Ten una verdadera prueba de extremo a extremo para esos caminos críticos, y luego simula todo lo demás. Dale a tu semana de pruebas una mayor velocidad. Dale a ti mismo ese control que necesitas.

Muy bien. Esto ha sido Solicitudes de Red con Cypress. De nuevo, soy Cecilia Martinez. Muchas gracias por tu tiempo, y espero que esto te sea útil.

Qué fantástica charla, claramente una herramienta muy versátil. Y antes de sumergirnos en las preguntas y respuestas, vamos a traer a Cecilia y echar un vistazo a los resultados de la encuesta. Hola, Cecilia. Así que preguntaste a la gente cuántas conferencias de tecnología has asistido. Antes de mirar los resultados, ¿a cuántas has asistido tú? Oh, definitivamente estoy en esa categoría de más de cuatro. Para mí, las conferencias virtuales como esta han hecho que sea realmente fácil asistir a muchas más de ellas. 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 la gente parece que está en esa categoría de una a tres conferencias. Parece que tenemos a bastantes personas que es su primera vez, también, lo cual es bastante emocionante. Elegimos una buena en venir aquí y echar un vistazo. Así que sí. Sí. Parece que tenemos a algunas personas que están en esa categoría de más de cuatro también, pero tal vez no tantas. Y al igual que tú, estar en línea ha abierto tantas puertas para los oradores para diferentes tipos de eventos. Así que sí, he asistido a muchas. Pero todo es diferente en este momento, ¿no es así? Así que, tenemos algunas preguntas para ti.

Y no me sorprende porque, como en tu charla, esto, llamémoslo una característica, puede ser utilizada para muchas cosas. Y vamos a empezar con Malcolm. Él preguntaba, ¿cómo registramos las respuestas a las solicitudes o podemos registrar las respuestas a las solicitudes? Sí, absolutamente. Entonces, hay un par de opciones diferentes, ¿verdad? Así que puedes usar realmente el comando site outlog que te permite esencialmente registrar eso en el registro de comandos de Cypress si estás buscando registrar eso también en tu salida. Tenemos algunas opciones allí. Hay algunas herramientas diferentes que puedes usar. También siempre puedes capturar esas respuestas y aprovecharlas de diferentes maneras. Si necesitas, por ejemplo, documentarlas, la salida, y para validar eso. Así que, además de ese registro, probablemente será el aspecto inicial más amigable para el usuario 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 aconsejable probar el front end de toda la API de backend simulada, por supuesto, acompañado con algunos recorridos de usuario críticos reales de extremo a extremo? Sí, creo que esto se remonta a la charla de Lev y Roman de antes sobre cómo no hay realmente un enfoque único para todos o una respuesta sólida de cualquier manera. Todo depende del contexto, ¿verdad?, de lo que estás tratando de hacer. Así que cuando hablo con los usuarios todo el tiempo, les pregunto, ¿cuál es tu objetivo para esa prueba? ¿Y cuál es tu objetivo para tu suite de pruebas y lo que estás tratando de abordar? Así que si estás buscando probar la funcionalidad de tu front end y no te importa el backend, entonces absolutamente, está totalmente bien simular completamente tu backend. Veo esa implementación mucho. La gente dice, sabes, estamos usando microservices en el backend, o es un equipo completamente diferente, y solo queremos asegurarnos de que nuestra pieza está funcionando correctamente. Si tu objetivo es asegurarte de que tienes todo el extremo a extremo funcionando correctamente, entonces sí, veo ese enfoque mucho 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 quizás tienen lógica de negocio compleja que quieres hacer algunas pruebas de unit y asegurarte de que eso está funcionando para cubrir todos los casos extremos. Y luego tienes tus pruebas de interfaz de usuario del front end simuladas también para asegurarte de que todo se ve bonito, quizás lanzar algunas pruebas visuales allí para asegurarte de que todo se está renderizando correctamente. Y sí, es un enfoque muy válido. Pero de nuevo, la respuesta siempre va a ser, depende, porque siempre va a haber contexto alrededor de tus objetivos. Sí, y si puedo añadir, creo que la clave para mí es la palabra riesgo. ¿Cuál es el riesgo que estás tratando de mitigar? ¿Está 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 a sí mismo sobre el mejor enfoque. Pero de nuevo, estás mostrando que Cypress es diverso y puedes manejar múltiples formas. ¡Fantástico! Así que TesterJS tiene otra pregunta. Oh, no, lo siento. Me he saltado una. Así que Harlow, hay muchas formas de comprobar que se ha enviado una solicitud, pero no parece haber una receta para comprobar que no se envió una solicitud. ¿Cuál es la mejor manera de hacer eso en Cypress? Sí, hay formas de hacerlo. Así que cuando la gente me pregunta, ¿cómo puedo hacer esto? ¿Cómo hago eso? Muchas veces les preguntaré 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 probar una falsedad o probar que algo no ocurrió. Correcto. Siempre es como, sabes, prueba que esto no sucedió. Una de las formas que he visto es declarar esa ruta y luego hacerlo, escribir una función personalizada para establecer el conteo, el número de veces que ha ocurrido. Si se mantiene en cero, entonces puedes ver que no ha sucedido. Pero realmente, si estás teniendo una comprobación de que algo no ha ocurrido, entonces probablemente hay algo realmente no determinista sobre esa prueba.

Y tal vez se necesita entender un poco más sobre los requisitos de tu aplicación y contra qué estás testing. Porque si una solicitud de red ocurre y no debería suceder, y necesitas simplemente afirmar que no ha sucedido, yo desafiaría ese caso de uso y entendería más sobre lo que estás tratando de lograr con eso. Así que técnicamente, es posible, pero realmente cuestiona por qué querrías hacer eso.

Genial. Sí, no podría estar más de acuerdo. Lo he visto a veces en móviles, como que recibes muchas respuestas y quieres ver el tipo de respuestas que se están enviando porque, ¿confío en esta UI? ¿Confío en este sitio web? Pero sí, siento que hay, estoy de acuerdo contigo, probablemente hay un positivo que querría mirar. Entonces, ¿por qué nos preocupa que se haya enviado en algún momento? Hay tantas preguntas que hacer. Excelente respuesta.

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

Eso no tiene sentido para mí, espero que tenga sentido para ti. 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 la otra cosa a tener en cuenta también es si estás tratando de obtener la longitud de algo y luego tal vez como volver a entrar en él, no estoy seguro de cuál sería el caso de uso allí. Es un poco difícil de entender sin ver el código. Pero un par de cosas que están en mi mente, ¿verdad?, es si estás usando 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 sobre 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 es un poco difícil de entender, como dije. Definitivamente puedes usar .its. También puedes correr, como usar tal vez como un comando .children para ver qué hijos están disponibles a partir de esa lista y analizarlo de esa manera. Pero siempre recomiendo de nuevo, es como tener selectores realmente buenos y entender qué elemento estás tratando de apuntar para que no tengas que hacer tanto recorrido del DOM. Dicho esto, no siempre es fácil. Si no tienes acceso al código fuente, si vas a tener una representación realmente no determinista, ahí es donde entra en juego una buena gestión de los datos de prueba, donde puedes saber qué se va a representar en tu aplicación y tu entorno de prueba y puedes 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 tal vez .children si tienes que hacer mucho recorrido del DOM porque esos serían más flexibles para ti que .pen. Lo entiendo, entiendo la pregunta ahora. Pensé que las listas eran como una característica en Cypress. Realmente significa una lista en el sitio web. Creo que eso es de lo que está hablando. Sí. Oh, no tienen idea de quiénes son de lo que podrían estar hablando.

Excelente. Bien, entonces Melad tiene nuestra siguiente pregunta y también noticias para ti. Empezaron a usar Cypress hace tres meses. Sin embargo, tienen un problema cuando lo utilizo que es que no puedo manejar la carga diferida. La única opción que conozco es el comando de espera pero la carga diferida no carga los componentes en el tiempo exacto. ¿Tienes alguna recomendación para manejar la carga diferida?

Sí, esto es algo que estamos viendo cada vez más con los modernos frameworks de front-end que utilizan o aprovechan la carga diferida o, por ejemplo, a veces necesitas desplazarte hasta la vista para activar la carga. De hecho, creo que quizás Gleb recientemente hizo una entrada de blog o una charla como un video sobre esto para esencialmente con resultados que se cargaban dinámicamente en la página. Y así, como con los resultados de búsqueda, te desplazarías hacia abajo, esperarías a que se cargara, te desplazarías hacia abajo, esperarías a que se renderizara. Y también hay un par de otras cosas que puedes hacer. Si estás utilizando un almacén de front-end como Vuex o si estás utilizando Redux, puedes entrar en tu almacén de front-end y esencialmente forzar las cosas a activar para cargar algo. Así que si sabes qué acción se envía para renderizar ese componente, puedes seguir adelante y enviar eso manualmente en Cypress para forzar que eso suceda. Y luego siempre va a haber esencialmente asegurando que el DOM está listo. Y así, la carga diferida puede ser difícil pero si entiendes qué activará la carga de ese componente, entonces puedes trabajar realmente con eso para asegurarte de que va a aparecer en la pantalla, ya sea que sea un desplazamiento, ya sea que sea un clic. A veces he visto a personas donde les gusta, escribirán en el botón, pero luego en lo que hacen clic no actúa, no es realmente el elemento que carga, que dispara el evento. Así que no están simplemente, simplemente no están agarrando el elemento correcto. Así que mucho de eso es realmente entender tu aplicación y qué está causando que esos componentes se carguen.

No podría estar más de acuerdo. Como entender el estado, una vez que conoces el estado y también a veces ¿estás tratando de probar la carga diferida? Como, ¿puedes apagarlo? Porque a veces estas cosas están ahí para ser agradables, ya sabes, un poco de destello, un poco de estilo, pero si no estás tratando de probar el destello y el estilo, apágalo, haz tu vida fácil, facilita la prueba de estas aplicaciones. Ese es un punto realmente bueno, Richard, seguro. Es como, ¿qué estás tratando de probar, verdad? Y si no necesita ser probado, entonces tal vez simplemente 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 relativamente simple, creo, pero ¿puedes simular 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 HTTPS solo para coincidir con las solicitudes seguras, creo. Jobs nos está preguntando, ¿es posible almacenar un método de interceptación general y llamarlo a lo largo de diferentes pruebas con una ligera modificación a las variables? Sí, recomendaría algo como un comando personalizado para eso. Así que esencialmente, en Cypress, puedes declarar comandos personalizados. Así que recomendaría pasar esencialmente, como si quisieras un cierto parámetro de consulta y lo llamaras como sci.intercept con consulta y luego puedes pasar cualesquiera que sean los parámetros de consulta y luego tener el sci.intercept declarado allí. Pero sí, absolutamente. Excelente.

Podríamos tener tiempo para esta última pregunta de Malcolm. ¿Existe documentation para principiantes para alguien nuevo en Cypress? ¿Existe documentation para principiantes para alguien nuevo en Cypress? Sí, en docs.cypress.io. Así es como aprendí Cypress cuando estaba empezando, seguro. Además, ya sabes, Test Automation University es una plataforma gratuita que tiene un par de cursos sobre Cypress. Tienen un curso para principiantes y luego uno de nuestros embajadores de Cypress acaba de lanzar un curso más advanced también 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 a las preguntas y respuestas, así que gracias por unirte a nosotros. Sí, absolutamente, muchas gracias y espero que todos tengan un gran evento.