Cómo empezar con Cypress

Hoy me gusta enseñar a los probadores sobre desarrollo web y enseñar a los desarrolladores sobre pruebas. Puedes encontrar todo lo que hago en mi página web, filibris.com, donde publico consejos sobre Cypress casi todas las semanas. Tuve un gran intervalo porque estaba haciendo muchos cursos nuevos. Y seguiré con eso. Pero sí, toda la página está dedicada básicamente a Cypress y brindar diferentes consejos. Entonces, si estás buscando algo, también puedes buscar allí. Y sí, hago talleres, presentaciones, webinars y todo eso. Creo que ya dije todo sobre mí. Este es un enlace a mi página. Entonces, Filip Nits, ese es mi nombre, .com slash workshop, donde puedes encontrar la versión completa de lo que vamos a experimentar hoy. Entonces, como dije, no todos estaban aquí. Esta es una versión de demostración más pequeña del taller, si quieres. Y si quieres experimentar todo, tengo un próximo taller que comienza la próxima semana. Entonces, si quieres inscribirte en eso y obtener la experiencia completa, puedes hacerlo. Y si estás considerando hacerlo, contáctame en Discord con un mensaje directo. Te daré un código promocional, porque no tiene mucho sentido hacer algunas partes dos veces. Entonces, para obtener algo de valor de eso, te enviaré un código promocional si estás interesado en tener la experiencia completa.

Entonces, el formato del masterclass será así. Por cierto, puedes escanear este código QR, porque lo usaremos. Pero el formato del masterclass es el siguiente. Haré una descripción general del capítulo, básicamente te diré lo que aprenderás en ese capítulo. Y luego pasaremos a una demostración. O más bien, yo haré la demostración, básicamente te mostraré cómo funciona todo. Y luego tendremos un desafío práctico. Así que estaré en silencio y tú harás el trabajo de codificación. Siéntete libre de hacerlo.

Y para las preguntas y respuestas, podemos hacerlo continuamente. De hecho, somos un grupo bastante pequeño. Solo tenemos como 15 participantes. Eso incluye a mí y a Alex, que también está en la llamada de Zoom, del equipo de TestJS. Así que creo que podemos desactivar el silencio de Mike y hacer una pregunta. Siéntete libre de hacerlo. Para obtener un valor adicional de esto. Pero también podemos usar Slido. Eso es de donde soy. Es una gran herramienta para tener interacción. Si eres tímido o sientes que tienes una pregunta estúpida, no la tienes. Pero si te sientes así, puedes usar Slido para preguntar de forma anónima. Y probablemente diré que no es una pregunta estúpida, es una gran pregunta. Y la responderé. Pero también tengo una pregunta para ti. Y por eso quería que escanearas ese código QR. Así que déjame entrar en eso. Y mi pregunta es ¿qué tanto conoces Cypress? Me gustaría saber en qué nivel te encuentras actualmente con tus conocimientos. Y una estrella significa que estás comenzando. No sabes mucho o no sabes nada. Y seis estrellas significaría que lo usas a diario, ya conoces cómo funciona y básicamente estás aquí para mejorar tus conocimientos. Tal vez encontrar algunos tips adicionales. Muy bien, estamos muy bien distribuidos aquí. Oh, tenemos 1 sexta estrella, eso es genial. Así que estamos distribuidos en ambos lados, principalmente en el medio. Oh, eso es bueno. Eso es bueno. Por cierto, no te preocupes si estás demasiado a la derecha o demasiado a la izquierda lado. Normalmente, cuando hago esto, creo salas de grupos para dividir esta reunión en grupos más pequeños. No estoy seguro si podremos hacer eso hoy, pero veremos. Veremos cómo lo manejamos. Tal vez nos quedemos en la misma sala. Muy bien. Muy bien. Así que obtuvimos una puntuación de 3.6. Tenemos algunos principiantes, algunas personas que están en el medio, algunos son más avanzados. Eso es increíble. Gracias. Gracias por responder esa pregunta. Eso realmente ayuda a darme una idea.

Permíteme continuar explicando cómo funcionará este masterclass. Ya dije un poco sobre esto, pero para la demostración, haré una breve presentación. Así que durante eso, no intentes codificar al mismo tiempo. De hecho, es mejor que no lo hagas porque tiendo a ir un poco rápido. Y si estás alternando entre codificar y observar, es posible que te pierdas algunos puntos. Así que es mejor que solo observes. Para que no te pierdas, puedes ver todo lo que hice en el archivo de fin de demostración y comenzar en el archivo de inicio de demostración. Así que eso es inicio de demostración, fin de demostración. En la carpeta del proyecto, tendrás el nombre del capítulo. Oops, eso no era subrayado, sino tachado. Así que tienes el nombre del capítulo en el que estaremos y siempre comenzaré desde el inicio de la demostración y el estado final estará en el final de la demostración. Así que obtendrás una idea de todo. Además, todo lo que planeo ver está dentro de la carpeta de notas, pero tiendo a improvisar así que no encontrarás todo, pero espero que encuentres la mayor parte de la información que necesitas.

Después de hacer la demostración, pasaré a los desafíos prácticos y nuevamente, te muestro aquí la estructura de carpetas. Entonces, lo que harás durante los desafíos prácticos es echar un vistazo a el archivo challenge.cy.js. Dentro de él encontrarás instrucciones sobre lo que debes hacer y dentro de la solución del desafío encontrarás la solución para ese ejemplo en particular. No te sientas mal si lo consultas. De hecho, te animo a que lo hagas, maximiza tu aprendizaje obteniendo la mayor cantidad de información posible, no intentes resolverlo de memoria o algo así. Utiliza la documentación, utiliza el archivo de solución, haz todo lo posible para obtener conocimiento. Nota importante sobre los desafíos prácticos, no es necesario que los termines todos. De hecho, mi objetivo es mantenerlos activos incluso después del masterclass, así que si no los terminas todos y te sientes incómodo porque no están terminados, eso es realmente algo bueno, me gusta eso, porque eso probablemente te obligará a abrir ese repositorio nuevamente y jugar un poco más con Cypress.

Entonces, sí, solo una nota sobre la cantidad de desafíos prácticos. Además, ayuda a nivelar a las personas que son principiantes con las personas que ya están avanzadas, por lo que no todos terminarán al mismo tiempo o harán la misma cantidad de desafíos prácticos.

De acuerdo, así que pasemos a las herramientas que utilizaremos. Yo usaré VSCode, está bien usar cualquier otra herramienta. Si estás usando WebStorm, está perfectamente bien, o Sublime, o no sé qué. Solo asegúrate de tener una terminal, porque la utilizaremos. En cuanto a Cypress, utilizaremos la versión, oh, ¿cuál era esa versión? Creo que la versión instalada en el repositorio es, sí, 10.10. Si actualizaste la versión de Cypress, no hay problema, está perfectamente bien, cualquier versión por encima de la versión 10 está bien. Y solo realizaremos pruebas de extremo a extremo, no pruebas de componentes hoy. El masterclass de pruebas de componentes será en el futuro. Muy bien. Y utilizaremos esta increíble aplicación Trello. Así que este es un masterclass de pruebas, por lo que necesitamos algo para probar. Y te mostraré qué vamos a probar. Aquí tengo el repositorio y tengo mi proyecto de Cypress y todo. Pasaremos por eso. Y dentro de la aplicación Trello, tenemos la aplicación que vamos a probar. Para ejecutar la aplicación, ejecutarás npm start, y esto iniciará un servidor local, por lo que cada uno tendrá su propia aplicación en su computadora. Y si vas a HTTP localhost 3000, encontrarás la aplicación abierta aquí.

Así que se ve algo así. Lo hice... Oops, ¿qué hice? Y eso no es lo que quería. Muy bien. Así que se ve algo así cuando lo abres por primera vez. Cuando creas un nuevo tablero, se creará un nuevo tablero. Así que si estás familiarizado con la aplicación Trello, es básicamente una aplicación de tareas pendientes donde puedes crear múltiples listas de tareas, como Lista 1, Lista 2. Y puedes crear esas tareas pendientes, que aquí se llaman tarjetas. Así que Tarjeta 1, Tarjeta 2. Puedes ver los detalles de la tarjeta. Puedes marcarla como completada. Incluso puedes hacerlo aquí. También puedes arrastrar y soltar esas tarjetas. Puedes arrastrar y soltar esas listas. Puedes marcar el tablero como favorito. Así que puedes hacer clic en la pequeña estrella aquí. E incluso hay un inicio de sesión. No estoy seguro si lo usaremos hoy. Veremos. Pero sí, puedes iniciar sesión o registrarte o lo que sea. Y sí. Así que esa es básicamente la funcionalidad.

En cuanto a la base de datos, en realidad es bastante simple. Realmente, realmente me gusta esto, este backend muy simple que tenemos aquí. Así que dentro de la carpeta de la aplicación Trello, tenemos esta carpeta de backend, tenemos nuestras APIs, blah, blah. Además, tenemos la carpeta de data. Y dentro de ella, hay un archivo JSON de base de datos. Y esto es básicamente nuestra base de datos. Esto es todo lo que se necesita. Así que tenemos nuestros tableros, nuestras tarjetas, nuestras listas. Esta es básicamente toda la estructura de lo que está sucediendo aquí. Así que cuando creamos ese nuevo tablero, se crea este objeto, este elemento en nuestra base de datos. Tiene algunos atributos adicionales como start, cuándo se creó, el ID, etc. Y lo mismo ocurre con todas las demás cosas dentro de nuestra aplicación. Así que tenemos nuestras tarjetas. Como puedes ver, aquí está la tarjeta uno, tarjetas dos que acabo de crear, y sí, eso es todo. Así que si quieres examinar la base de datos y ver qué está sucediendo allí, este es el archivo. Y aquí es donde debes ir para verlo.

Además, para facilitarte un poco la vida, he creado estas herramientas especiales, las llamo herramientas de API. Cuando presionas la tecla F2, si estás en una Mac, puedes presionar Function y F2, verás estas pequeñas herramientas en la esquina inferior derecha. Que pueden ayudarte a restablecer tu aplicación. Básicamente, puedes eliminar todas las tarjetas de la base de datos, todas las listas, incluso todos los tableros o todo, todos los usuarios y todo lo que esté a la vista. Y cuando hagas eso, y vuelvas a la base de datos, verás que está vacía. Así que esta es solo una pequeña herramienta para facilitarte un poco la vida. Y sí, eso es todo. Te familiarizarás más con la aplicación pero esto es suficiente para empezar. Creo que será suficiente. Y sigamos adelante.

Oh sí, una cosa que hago en este masterclass es que podrías ver un mensaje como este. La base de datos se borró y se inicializó antes de todas las pruebas.

Esto es, una vez más, algo en lo que estoy tratando de facilitarte un poco la vida, y esta es una captura de pantalla de Cypress. Así que si ves este mensaje en Cypress, sabrás que la aplicación se ha reiniciado básicamente y todo lo que hayas creado en tu aplicación se borrará y se reemplazará con algunos datos. Con algunos datos que... Sí, con algunos datos. Así que tenlo en cuenta para que no te confunda. ¡Oye, ¿dónde están mis datos? Acabo de crear un nuevo tablero y ya no está aquí. Es algo diferente. Así que esta es la razón por la que hay un script en segundo plano que hace esto, no para todas las pruebas, pero para algunas de ellas.

Muy bien, pasemos a lo que podríamos llamar el capítulo cero. ¿Dónde debería? Muy bien, necesito un poco de mis notas. Muy bien, en el capítulo cero, aprenderemos cómo instalar Cypress, cómo se ve un proyecto de Cypress, cuál es el propósito de las diferentes carpetas del proyecto y también cómo elegir un navegador diferente en Cypress, y sí, creo que eso es todo.

Así que pasemos a la demostración. Tengo aquí mi repositorio que usaremos para el masterclass, pero por un momento voy a abrir una nueva ventana y voy a ocultar esta. Y en lugar de trabajar en mi repositorio, voy a empezar desde cero. Así que vamos a aprender ahora cómo empezar con un proyecto de Cypress. Voy a crear una nueva carpeta, llamémosla test.js-workshop, y simplemente la arrastraré y soltaré en mi VS Code.

En el VS Code, tengo la carpeta abierta, y si quiero iniciar un nuevo proyecto de Cypress, lo primero que suelo hacer, aunque no es totalmente necesario, pero es una buena práctica, es ejecutar npm init y sí. Entonces, lo que esto va a hacer es crear mi archivo package.json, y como estamos en el entorno de Node, este package.json generalmente contiene información sobre el proyecto en el que estamos trabajando. El script que acabo de llamar npm init-y básicamente significa que cuando hago npm init, me va a dar esta pequeña encuesta o cuestionario, ¿cuál es el nombre de tu proyecto, cuál es la versión del proyecto? Básicamente, va a hacer un par de preguntas, y la opción -y significa responder sí a todas esas preguntas. Si hago eso, va a crear un archivo package.json como este, así que eso es básicamente el paso cero. No es necesario si quieres iniciar un nuevo proyecto, pero en algún momento necesitarás tener un archivo package.json, así que es mejor empezar con eso. Muy bien, eso es el paso cero, y ahora, ¿cómo instalar Cypress? Dado que estamos en un entorno de Node y podemos usar npm, haremos exactamente eso: npm install Cypress, y lo estoy poniendo en latest tag, aunque realmente no tengo que hacerlo porque de todos modos va a instalar la última versión, pero lo he estado usando por alguna razón, así que se autocompletó para mí. Muy bien, ahora tengo Cypress instalado, y puedes ver que tenemos dos elementos nuevos en nuestro proyecto. Tenemos nuestra carpeta NodeModules y tenemos nuestro archivo package.log.json. La carpeta NodeModules contiene todas las dependencias que utiliza Cypress. También contiene Cypress con todo lo que hay dentro. Básicamente, hay muchas cosas aquí, así que no olvides agregar tu NodeModules al archivo .gitignore para que no lo subas al repositorio. Ese es un error de principiante, pero nadie aquí es tan novato, ¿verdad? Nadie lo ha hecho, no yo, sí. Muy bien, solo sí, no te olvides de eso. Package.packagelog.json es básicamente lo mismo que package.json. Solo contiene mucha más información. Básicamente, es para que tu computadora pueda leerlo y resolver todas las dependencias y dependencias de pares y cosas así. Así que no tenemos que hacer nada con eso, es para que las computadoras lo lean.

Muy bien, hemos instalado Cypress. Hemos inicializado nuestro proyecto. Ejecutemos Cypress. Para ejecutar Cypress, tenemos dos comandos. Tenemos npx cypress run, que es un modo headless que ejecutará todas nuestras pruebas que tenemos en el proyecto. No tenemos ningún archivo en nuestro proyecto, así que lo que haremos es ejecutar npx cypress open, que abrirá la interfaz gráfica de usuario de Cypress. Y eso nos dará la bienvenida con esta bonita pantalla de bienvenida. Así que podemos decidir qué tipo de pruebas queremos hacer aquí. Y dado que estamos en un masterclass de pruebas de extremo a extremo, elegiremos pruebas de extremo a extremo. Y básicamente, lo que Cypress hará en este paso es crear un conjunto de archivos de configuración. Así que creará este archivo Cypress config.js, algunos archivos de soporte de Cypress, archivos e2e, algunos archivos de comandos y archivos de fixtures. Pasaremos por ellos en un segundo. Pero básicamente, esto es lo que Cypress hizo por nosotros. Así que cuando continúo, ahora puedo seguir adelante y elegir un navegador. Ahora Cypress va a echar un vistazo a mi sistema e intentará encontrar todos los navegadores que son compatibles y mostrarlos aquí. Recientemente, Cypress ha añadido soporte para un navegador WebKit. Pero dado que eso todavía está en modo experimental, necesitas hacer un paso extra allí. Necesitas instalar WebKit. Dato curioso, en realidad es el mismo WebKit que utiliza Playwright. Así que en realidad vas a hacer algo como npm install Playwright web kit o algo así. Y luego puedes seguir adelante y probar en WebKit. Pero suelo elegir Chrome. Ahí es donde me siento como en casa. Oh, mírame, estoy haciendo rimas. Muy bien. Y sí, cuando hago eso, mi navegador Chrome se abrirá y tengo esta bonita interfaz de usuario aquí donde puedo generar archivos de ejemplo o crear un archivo de especificación vacío si quiero. Y además tengo esta pestaña de configuración donde tengo todas estas configuraciones para el proyecto. Básicamente, ahora está configurado como predeterminado. Y tengo ejecuciones, que es una nueva interfaz de usuario a la que puedes conectar con un panel de control de Cypress. Así que el panel de control de Cypress es un servicio, es un gran informe y análisis de tus pruebas. Así que puedes conectarlo aquí, pero no vamos a profundizar demasiado en eso. Así que empecemos con la generación de algunos archivos de ejemplo. Si eliges esto, Cypress básicamente va a crear un par de archivos de prueba para ti y aquí están ahora. Así que si hago clic en cualquiera de ellos, Cypress ejecutará una prueba, básicamente abrirá ese archivo y ejecutará todas las pruebas que haya dentro. Así que déjame hacer esto un poco más grande. Se ejecutó todo en tres segundos.

Entonces, si lo ejecuto nuevamente, puedes ver a Cypress interactuando con esta aplicación. Si quiero, puedo abrir otra prueba y ver cómo se ejecutan. ¿Oh, va a fallar? Oh, tenemos una prueba fallida. Sí, esto es como una demostración de las capacidades de Cypress. No estoy seguro de por qué falló esa prueba. Tal vez hice clic dentro del navegador o algo así. Sí, apuesto a que lo hice. Así es como puedes ver a Cypress en acción. Y sí, eso es todo. Volvamos a VS Code.

En nuestro VS Code, tenemos dos elementos nuevos desde la última vez que lo vimos. Tenemos el archivo cypress-config.js y tenemos una carpeta cypress aquí. El archivo cypress-config.js es un archivo de configuración. Básicamente, sigue los estándares del desarrollo web. Si alguna vez has trabajado con Veed o Tailwind o cualquier otra cosa, hay una especie de convención de tener un archivo config.js o .ts donde se encuentra toda la configuración. Con la versión 10, Cypress cambió eso para seguir exactamente esta convención. Antes era un archivo JSON donde tenías tu configuración. Y sí, así es como se ve. Esto es lo que hay dentro de él de forma predeterminada. Y puedes ver que no hay mucho, lo que significa que no necesitamos configurar mucho para ejecutar Cypress, pero si lo necesitáramos, podríamos poner cosas como la URL base aquí para decirle a Cypress cuál es la URL de la aplicación que queremos probar, hay cosas como cambiar la altura del viewport, el ancho del viewport. Todas las configuraciones predeterminadas estarían dentro de este archivo. Así que eso es CypressConfig.js y tenemos una carpeta Cypress. Y la carpeta tiene una estructura muy sencilla. Tenemos la carpeta E2E, donde, como puedes imaginar, tendríamos todos nuestros archivos de prueba. Así que puedes ver el to do, CY y el action CY que ejecutamos dentro de nuestro navegador Chrome. Todos los archivos que están dentro de la carpeta E2E se mostrarán aquí. Esa es la carpeta predeterminada donde Cypress busca las pruebas. Por supuesto, puedes cambiar eso. Y cambiarías eso en cypressconfig.js. Muy bien, tenemos dos carpetas más. Una es fixtures, donde se encuentra todos tus datos estáticos. Así que si tienes archivos JSON o imágenes o cosas que quieres cargar durante las pruebas, etc., aquí es donde irían normalmente. Y también tenemos la carpeta support y tenemos dos carpetas. Esto es como un andamio del proyecto. No contiene demasiado. Básicamente, este archivo E2E JS contiene una importación del archivo de comandos que está aquí. Y este archivo de comandos no incluye nada, solo un par de comentarios para mostrarte básicamente lo que se supone que debe hacer el archivo. El archivo E2E, que a menudo se denomina archivo de soporte, se carga antes de que se ejecuten todas tus pruebas. Así que si tienes un módulo externo o un complemento o algo así que quieres usar, lo agregarías aquí. Si tenemos suficiente tiempo, hablaremos sobre complementos y te mostraré cómo instalar uno. Muy bien, eso es básicamente todo. Espero haber cubierto todos los conceptos básicos del proyecto Cypress. Así es como se ve. Así es como empezarías desde cero. ¿Tienes alguna pregunta en este punto? Y obtenemos silencio. Muy bien, el silencio está bien. Nuevamente, si te sientes tímido y no quieres activar tu micrófono para hacer una pregunta, puedes usar Slido para hacerlo de forma anónima o también estoy revisando el chat de la reunión y el Discord. Así que si quieres, siéntete libre de preguntar allí. Muy bien, eso es todo para el primer capítulo o más bien para el capítulo cero, porque quiero llamar al capítulo uno aquel en el que realmente hagas algo y trates de programar por tu cuenta, y ese es la creación del primer test. Aprenderás cómo crear tu primer test o qué tipo de sintaxis utiliza Cypress. ¿Cómo configurar la URL de la página que deseas probar? ¿Cuáles son las capacidades de la aplicación Cypress? Así que veremos todo eso. Cómo hacer clic, escribir, interactuar con nuestra aplicación y también qué tipo de comprobaciones realiza Cypress en segundo plano. Pasaremos por muchos conceptos básicos, pero después de eso, comenzaremos a programar. Muy bien, mi pantalla está haciendo algo divertido. Muy bien, vamos a la demostración. Voy a abrir mi proyecto Cypress aquí. Y vamos a... Voy a eliminar la carpeta. Ya no la usaremos. Y sí, durante el taller quiero mostrarte ahora, si quieres pasar por el desafío práctico, necesitarás tener dos terminales abiertas. Entonces, en la primera terminal, escribirás npm start y esto iniciará la aplicación. La aplicación que queremos probar, la aplicación Trello que te mostré, y mantendrás esto en ejecución y luego abrirás otra terminal. Y dentro de ella, abrirás Cypress. Así que npx cypress open. Probablemente no sea la mejor forma de ver eso. Lo tenemos. Muy bien, npx cypress open. Así que tenemos npm start, la aplicación en ejecución. Otro será npx cypress open para abrir nuestro Cypress. Y esas son las dos cosas que necesitas tener abiertas para hacer los desafíos, etc. Así que seguiré adelante y elegiré pruebas de extremo a extremo. Elegiré Chrome, porque es mi favorito, y organizaré un poco mis ventanas. Y vamos a comenzar con la demostración.

De acuerdo, así que tengo dos pruebas aquí y déjame abrir este archivo de inicio de demostración en el VSCode también. Aquí lo tengo abierto. Y sí, déjame explicarte qué está sucediendo aquí porque hay mucho. Tenemos dos pruebas aquí. Así que tenemos esto primero. Crea una lista con una tarjeta en ella y marca un tablero. Y puedes ver los nombres de esas pruebas reflejados en la interfaz de usuario de Cypress, ¿verdad? Crea una nueva lista, marca un tablero. En Cypress, hay muchas herramientas que se incluyen en Cypress, y una de ellas es Mocha. Así que si alguna vez has trabajado con Mocha, probablemente ya estés familiarizado con lo que está sucediendo aquí. Si no lo has usado, básicamente hay esta función it. Y esta función it toma dos parámetros. El primero va a ser el nombre de la prueba. Y el segundo es un callback. Y eso contendrá todos los comandos, todos los comandos de Cypress que queremos que Cypress ejecute. Básicamente, un bloque it significa una prueba. Así que si tengo varios bloques it, si lo guardo, tendré varias pruebas. Todos están vacíos ahora, así que Cypress no está haciendo nada. Solo quería mostrarte que un bloque it equivale a una prueba. Muy bien. Así que escribamos nuestra primera prueba. Voy a volver a poner estas dos pruebas que tenía aquí. Y si quiero que se ejecute solo una de esas pruebas, puedo hacer it.only, y solo se ejecutará la primera prueba. Déjame guardar esto. Y ahora podemos ver que solo se está ejecutando la primera prueba. Muy bien, retrocedamos un poco porque ya tengo un comando aquí y puede que no sea, aunque la sintaxis es bastante legible, pero puede que no esté totalmente claro qué estoy haciendo aquí. El primer comando que suelo enseñar en mi taller es el comando visit porque es el más fácil, ¿verdad? Así que si hago CY.visit y le digo a la aplicación qué URL quiero visitar, se vería así, ¿verdad? Así que tenemos tres partes aquí. Esto es el CY y ese es el objeto global de Cypress. Así que no tienes que importar nada, no necesitas hacer nada adicional. Simplemente tienes ese CY en cada archivo que creas. Cuando usas el CY, tienes todas las funciones aquí dentro. CY.visit, la visita es la función que está dentro del objeto global. Así que vamos a CY.visit, CY.click, CY.get, CY, todos los diferentes comandos. Esta es básicamente la sintaxis que usarás en todas las pruebas. Así que desde el objeto globalCy, quiero usar la función visit. Ahora, el localhost 3000 que tengo aquí es básicamente un argumento de esa función de visita. Así que si hago CY.visit http://localhost:3000, básicamente le estoy diciendo a Cypress que visite la ubicación. Localhost 3000. Déjame guardar eso. Y ahora puedes ver que estoy abriendo la ubicación 3000. Es posible que ya hayas visto eso antes. Simplemente tenía una barra aquí, ¿verdad? Así que solo visito la barra. Ahora, ¿por qué tenía eso aquí? Bueno, la razón es muy simple. Si voy a mi cypressconfig.js y registro mi URL base como localhost:3000, entonces todo lo que necesito hacer es visitar la barra. Y básicamente se agregará lo que tengo en mi comando de visita a mi URL base. Así que si vuelvo y hago visitar barra, básicamente abrirá mi página de inicio. Si quiero abrir los detalles de los tableros, como este tablero de cosas para comprar, no puedo verlo aquí, pero la URL completa es localhost:3000/board/1. Así que si quiero visitar esta ubicación en su lugar, puedo ir a /board/1 y visitará directamente el tablero. Así que en lugar de ir a esta pantalla de inicio, aterrizamos directamente en los detalles. Podríamos ir a /login/signup si quisiéramos. Así que sí, así es como funciona. Muy bien, ahora que hemos visitado nuestra aplicación, hagamos algo. Escribamos una prueba. Oh, se me olvidó mencionar una cosa que probablemente ya hayas notado, pero cada vez que presiono Command + S y guardo mi archivo, Cypress está observando los cambios en ese archivo, en el que se está ejecutando actualmente. Así que si decido cambiar algo y guardarlo, se volverá a ejecutar automáticamente, lo cual es genial. Proporciona un ciclo de retroalimentación muy rápido. Y uso esto mucho, básicamente, para ver qué está haciendo mi prueba en todo momento. Cada vez que agrego un nuevo comando, puedo ver qué está sucediendo. Ahora, sí, creo que eso es todo lo que quería decir en esa parte.

De acuerdo, vamos a escribir una automatización. Queremos, tenemos nuestro tablero de Trello. ¿Qué tal si automatizamos un escenario muy simple? Vamos a ir a este estilo de lista, creamos una nueva lista y luego hacemos clic en 'añadir otra tarjeta' y creamos una nueva tarjeta. Ese será un escenario lo suficientemente simple. Así que hagámoslo.

Ahora, ¿cómo lo hacemos? Permíteme ejecutar de nuevo mi prueba, se va a restablecer la base de datos. Así que quiero seguir adelante y escribir en este campo. Ahora, para obtener un elemento de nuestra página, utilizamos un comando llamado CY get. Ahora, el CY get en realidad no tenemos que definir si queremos seleccionar un elemento por ID, por clase o por algo más. Utilizamos la misma sintaxis de consulta que se utiliza en CSS. Así que si alguna vez has escrito CSS, es posible que ya estés familiarizado con eso. Si quieres seleccionar un elemento que tiene un ID, utilizas el símbolo de almohadilla y el ID del elemento, ¿verdad? Así que elemento, así es como seleccionarías un elemento con un ID de 'mi elemento'. Si tienes una clase, entonces la antepones con un punto. Así que punto, 'mi elemento', es un elemento con una clase llamada 'MyElement'. Y también puedes hacer todo tipo de selecciones locas, si quieres seleccionar un elemento hijo de ese elemento o algo así, puedes hacerlo. Así que todo lo que los selectores CSS te permiten hacer, puedes hacerlo con el comando get, además hay muchos comandos auxiliares que puedes usar para prácticamente cualquier cosa. Recientemente tuve un debate con alguien en Twitter que decía que tenían que usar expats. Argumentando que tal vez no los necesiten, pero realmente no conozco completamente la situación, pero la principal ventaja de expat es que puedes seleccionar un elemento hermano, como el siguiente o el anterior. Puedes encontrar el elemento hijo o puedes encontrar el elemento padre, pero en Cypress puedes hacer todo eso. Obtienes tu elemento y luego agregas otro comando básicamente para seleccionar un elemento anterior o el siguiente elemento. O si quieres encontrar elementos hijos, puedes encontrarlos o puedes encontrar un elemento padre e incluso especificar qué tipo de elemento debería ser. Así que un elemento padre con una clase de 'padre' o algo así. Así que en cuanto a la selección, puedes ir prácticamente a cualquier lugar con eso. Pero hay otra herramienta realmente útil que puedes usar en Cypress y se llama selector playground. El selector playground está aquí mismo en el navegador. Este pequeño icono básicamente te ayuda a seleccionar cualquier elemento en la página de la misma manera que podrías hacerlo con el panel de elementos dentro de las Chrome DevTools. Así que si hago clic en eso, en realidad va a generar todo el comando y solo tengo que copiarlo al portapapeles y pegarlo en mi prueba y ¡voilà!, ahora tengo un selector exactamente el que necesito. Sí, déjame guardar eso. Y ahora estoy seleccionando ese elemento. Está un poco borroso aquí, pero si me pongo encima, puedo ver el elemento seleccionado y resaltado, no estoy seguro de lo bien que lo ves, pero está resaltado aquí. Y sí, volvamos al escenario que queríamos probar, ¿verdad? Queremos crear una nueva lista y luego una nueva tarjeta. Así que lo que voy a hacer, como ya tengo el elemento, quiero escribir en él. Así que voy a escribir, no sé, lista de compras. Y lo escribiré, guardaré mi prueba. Y como puedes ver, ya estoy escribiendo en la lista de compras, lo cual es bueno. Así que el siguiente paso, en realidad tengo dos opciones. Puedo ir y hacer clic en este botón 'añadir lista', lo que lo agregará, o borrar esto y presionar la tecla Enter, que hace lo mismo. Entonces, ¿qué pasa si quiero presionar la tecla Enter dentro de este comando de escritura? En realidad es bastante fácil. Solo pongo llaves aquí y escribo Enter. Cuando guardo esto, puedes ver que escribe la lista de compras y luego presiona Enter, y eso creará mi lista aquí. Ahora, ¿cómo sé cómo hacer eso? Me alegra que lo hayas preguntado. Todo está en la documentación. Y sé que todos te dirán que leas la documentación, pero realmente, realmente me gustaría que leas la documentación, porque en realidad es bastante buena. Ahora, lo único de lo que no he hablado es este tipo de referencia que Cypress tiene aquí, que es básicamente un tipo especial de comentario en mi código, que básicamente le dice a VS Code que busque tipos del espacio de nombres de Cypress. Lo que eso significa traducido al lenguaje humano es que cuando empiezo a escribir C, Y y punto, en realidad me sugiere automáticamente estos comandos. Ahora, sin esto, no lo haría, y además de darme el autocompletado, cuando me pongo encima de cualquiera de los comandos, me da esta pequeña documentación para cada comando. Y si me pongo encima del comando de escritura, también puedes ver que tengo este CY, obtengo input type hello y presiono Enter. Así que tengo la información aquí, pero si copio este enlace, también tengo el enlace directamente en la documentación. Así que cuando hago eso, puedo ver qué hay aquí. ¿Qué hace este comando? Escribe en un elemento del DOM. Puedo ver la sintaxis. Veo el uso correcto. Veo el uso incorrecto. Y también veo todos los caracteres especiales que puedo escribir con el comando de escritura. Así que sí, además de eso, Cypress tiene muchos ejemplos aquí, muchos fragmentos de código pequeños que puedes ver, como cómo interactuaría mi comando con eso, etc. Es realmente bueno. Aprendí mucho de esto. Y sí, definitivamente recomiendo leer esto y echarle un vistazo y trabajar con eso, porque sí, el taller va a terminar en unas dos horas, pero la documentación es para siempre. Así que úsala.

De acuerdo, volvamos a nuestra prueba. Ya hemos escrito la lista de compras. Así que ya sabemos qué viene a continuación. Queremos seleccionar estos elementos 'añadir otra tarjeta'. Así que vamos a copiar eso, pegarlo aquí y queremos hacer clic en eso. ¿Qué tan difícil debería ser eso? Hacer clic. Eso es todo lo que necesitamos hacer. Así que cuando guardamos nuestras pruebas, ¿ves lo que hace ahora? Puedes ver que hemos creado la lista de compras y ahora hemos hecho clic en 'añadir otra tarjeta' y vemos este campo de entrada aquí.

Entonces, sigamos adelante y seleccionemos eso, copiemos al portapapeles, péguelo en nuestra prueba. Y ahora quiero usar type nuevamente para agregar algo a nuestra lista de compras. Compremos un poco de pan. Presionemos la tecla Enter. Y nuestra prueba está completa. ¡Increíble! Ahora pasemos a la segunda prueba porque hay algo que me gustaría mostrarte.

Quiero marcar un tablero. Básicamente, cuando quiero marcar un tablero, puedo hacer clic en esta estrella y se colocará el tablero en la categoría de marcados y la estrella se volverá amarilla. Hagamos eso. Sigamos adelante y seleccionemos nuestros elementos. Vamos a utilizar el comando get y lo que puedo hacer, ya que estoy en un navegador, es simplemente hacer clic derecho e inspeccionar elementos. Así que hagamos eso. Eso no es lo que quería. Aquí está. Así que puedo usar todas las DevTools que están disponibles para mí en un navegador normal. Puedo encontrar un elemento usando mi herramienta de inspección de elementos. Puedo encontrar el tablero y puedo ver que hay un elemento de estrella de datos aquí o una clase de estrella. Puedo seleccionarlo por clase. Si quiero, punto clase y luego interactuar con eso. Además, Cypress realmente hace uso de estas DevTools. No solo puedes usarlas todas, sino que también puedes ver toda la red, las fuentes y las cookies, etc. Realmente utiliza muy bien esta consola. Así que cuando voy a esta línea de tiempo, como puedes ver cuando me pongo encima, veo el estado anterior de mi aplicación. Cuando me pongo encima, puedo retroceder en el tiempo y ver lo que hizo mi aplicación en un cierto punto. Pero si hago clic en alguno de estos comandos, puedo ver los detalles de los comandos. Por ejemplo, el comando visit, puedo ver cuál fue la URL resuelta de ese comando. Si echara un vistazo al comando click o al comando type, podría ver qué hicieron. Y si hago clic en estas solicitudes XHR, puedo ver los detalles de esas solicitudes y examinar la API que mi aplicación está llamando. Además, tengo estas instantáneas con solicitudes y respuestas y todo. Es bastante bueno. Tengo esta estrella seleccionada. Así que ahora hagamos clic en ella. Y cuando veo mi prueba, en realidad va a fallar. La razón de eso es que mi comando get, cuando busqué un elemento de estrella, en realidad encontró dos elementos. Y cuando usé mi comando click para hacer clic en el elemento, dice: `Lo siento, no puedo hacer clic en dos elementos a la vez`. Así que o me das un elemento o me das un argumento, múltiple verdadero, y simplemente haré clic en ellos en serie, lo cual es bueno. Un usuario real no haría clic simultáneamente en dos elementos a la vez. Así que esto es una buena protección. Hagamos clic en un solo elemento. No voy a usar el clic en serie. No voy a pasar la opción múltiple verdadero. En cambio, lo que voy a hacer es, cuando encontró dos elementos, simplemente voy a filtrar el primero. Puedo hacer eso de dos maneras. Puedo usar el comando first, que va a filtrar de todos los elementos que el comando get ha encontrado, en este caso, dos, y solo reducir la selección al primero. O puedo usar el comando eq, que hace prácticamente lo mismo si paso el número cero, está numerando desde cero. Así que cero, uno, dos, tres, cuatro. El elemento cero sería el primer elemento. O puedo usar cualquier número, si quiero pasar el segundo elemento, será el número dos, etc. Básicamente te da más opciones. Así que hagamos eq cero y luego hagamos clic en nuestro elemento. Guardemos mi prueba, veamos qué está pasando ahora. Y en realidad está fallando de nuevo. La razón de eso se explica en el error de Cypress, así que Cypress maneja estos errores muy bien aquí. Y de nuevo, así que Cypress estaba tratando de hacer clic en el elemento. En realidad intentó durante cuatro segundos, pero falló porque el elemento no estaba visible. ¿Y por qué no estaba visible? Bueno, porque tenía una propiedad de display none. Y si un elemento tiene esa propiedad, no está visible. Así que Cypress realmente verifica si el elemento es visible, si es interactuable, si no tiene el atributo disabled, lo cual no permitiría que un usuario interactúe con ese elemento. Básicamente hace todas estas verificaciones en segundo plano en la interfaz de usuario para asegurarse de que un usuario real realmente pueda interactuar con ese elemento o con la cosa en una página. Y el problema aquí es que solo vemos nuestro elemento de estrella cuando nos ponemos encima de este elemento del tablero. Así que es posible que quieras buscar un comando hover, pero en realidad no hay tal comando en Cypress, lo cual es una de las limitaciones, pero no es realmente, bueno, déjame reformular eso. Cypress, cuando interactúa con nuestra aplicación, realiza toda la interacción utilizando JavaScript. Y dado que hover es en realidad una propiedad de CSS y no una propiedad de JavaScript, entonces no tenemos forma de usar JavaScript para activar un estado de CSS. Dicho esto, hay dos formas de solucionarlo. La primera se sugiere en el mensaje de error. Podemos simplemente pasar un force true en nuestro comando click y básicamente decirle a Cypress: `Sabes cómo estás verificando la visibilidad y si el elemento está deshabilitado, etc. Bueno, no hagas eso. Simplemente haz clic en eso, simplemente activa un clic en ese elemento, lo veas o no`. Esa es una forma de hacerlo. Otra forma es instalar un complemento. Y Cypress tiene este enorme ecosistema de complementos.

Y básicamente, hay toda una comunidad de código abierto que contribuye a Cypress con diferentes complementos y extensiones, etc. Y hay un complemento que en lugar de activar un evento utilizando JavaScript, va a utilizar el protocolo de herramientas de desarrollo de Chrome, que casualmente es la misma forma en que lo hace Selenium 4. Creo, no estoy seguro si lo hacen de forma predeterminada, pero sé que pueden usar el protocolo de herramientas de desarrollo de Chrome para activar diferentes estados. Por ejemplo, hover es uno de ellos. Sí, tengo eso en las notas para que podamos verlo. Y sí, ahora es básicamente el momento para que finalmente comiencen a codificar. Dentro de esta demostración, tengo esta carpeta de creación que está aquí. Tengo un desafío para ustedes, así que creen la primera prueba, challenge.js, challenge.cyyjs. Así que hay un par de ejemplos para que lo intenten. Así que pueden seguir adelante y probar eso. Y les daré alrededor de, no sé, 10, tal vez 15 minutos y prometo que los próximos capítulos serán más cortos. Este en particular tenía mucha información para darles al principio. Eso es lo que les he mostrado. Muy bien, adelante. Tengo, oh, tengo una pregunta en Zoom para María. ¿Puedes mostrar cómo podemos reescribir esta prueba haciendo que Cypress encuentre primero el tablero y luego la estrella en él? Oh, gracias. ¿Cómo podemos reescribir esta prueba haciendo que Cypress encuentre primero el tablero y luego la estrella en él? Tengo un caso en el que tengo varios elementos y no conozco su orden, pero sí sé cómo se llama el elemento hermano. Mm-hmm. Hay varias formas de abordar este problema. Entonces, si quieres seleccionar un elemento que... Oh, bueno, empecemos de forma sencilla porque ya estoy pensando tres pasos adelante. Así que usemos el comando get y simplemente encontremos un elemento, un elemento de tablero, eso es lo que queremos. Así que veamos por qué, elemento de tablero. Y cuando guardo esto, mi comando get, ups, cometí un error tipográfico, elemento de tablero. Entonces, mi comando get en realidad va a encontrar dos elementos. Así que si tengo dos elementos, lo que puedo hacer es filtrar, ¿verdad? Puedo filtrar EQ o algo así. Y dijiste que tienes un caso en el que tienes varios elementos y no conoces su orden, pero sabes cómo se llama el elemento hermano, los elementos hermanos. Hay otra forma, si sabes cómo se llama una cosa, hay otra forma de seleccionar un elemento y es usando el texto. Así que podemos usar contains. Y por ejemplo, en este caso, iría a cosas para comprar. Y esto va a seleccionar un elemento basado en el texto. Ahora, como puedes ver en el resaltado, en realidad está encontrando un elemento que está debajo del elemento de tablero del caso. Así que lo que puedo hacer es básicamente ir un nivel hacia arriba, puedo darle a este comando contains dos argumentos. Y el primer argumento va a comportarse exactamente de la misma manera que get. Pero el segundo argumento va a reducir la selección a un elemento que contiene ese texto. Así que si voy a data, cy elemento de tablero, va a seleccionar un elemento de tablero que contiene este texto. Así que en realidad está seleccionando el elemento de arriba, pero es el elemento que contiene ese texto. Leyendo tu pregunta, creo que eso podría ayudar en tu situación, pero sería útil si pudieras mostrarme una parte de la estructura del DOM, ya sea dentro de Discord o en otro lugar. Y tal vez mostrarme qué elemento quieres seleccionar. Porque hay muchas situaciones en las que quieres seleccionar diferentes elementos, etc. Un momento, muy bien. Muy bien, les daré un poco de tiempo para que intenten codificar junto conmigo. Démosnos quizás, hablé durante cuatro minutos, así que démosnos 10 minutos y luego pasaremos al siguiente capítulo. Muy bien. Espero que hayan tenido la oportunidad de completar al menos un par de esos desafíos. Y esos desafíos. Deberíamos avanzar porque tenemos un par de capítulos. Ya veo que es posible que no podamos cubrir todos ellos. Si, si también tenemos un descanso, hagamos un capítulo más, prometo que será más corto y luego tendremos un breve descanso y luego pasaremos a los siguientes. Sí, el próximo capítulo, capítulo 2, trata sobre afirmaciones simples. Así que vamos a adentrarnos en eso. Echaremos un vistazo al comando should. También, ¿qué es un gancho beforeEach? Y también cómo verificar el estado de visibilidad, la clase de número o el número de elementos y qué buscar al hacer afirmaciones. Así que vamos a pasar a la demostración. Demostración de inicio, ese es el archivo que voy a abrir en mi VS code. Y también voy a abrir el mismo archivo dentro de la carpeta de afirmaciones simples en Cypress. Muy bien, tengo un par de pruebas aquí. Me pregunto por qué la primera está fallando. Supongo que no es un gran problema. Tengo como cuatro pruebas aquí y vamos a filtrar la primera. Y una novedad que tenemos en esta prueba es este gancho beforeEach. Se parece un poco a lo que tenemos aquí con estas funciones it, pero no contiene un nombre, pero básicamente es un gancho y hace exactamente lo que podrías esperar. Simplemente ejecutará el código dentro del callback antes de cada una de esas pruebas que tenemos aquí. Así que tenemos cuatro pruebas y antes de cada una de ellas va a visitar el tablero/uno. Esta es la URL. Sí, también hay un gancho before, lo que significa que antes de todas las pruebas va a haber algo sucediendo.

Y también hay un gancho after y también after each. Así que si quieres hacer eso, tal vez para borrar tus datos o algo así, puedes hacerlo. En general, te aconsejaría comenzar con un estado limpio en lugar de terminar con un estado limpio. La razón de esto es que el estado pendiente de tus pruebas podría ser algo bueno para ti, porque es posible que desees seguir interactuando con tu aplicación mientras creas esa prueba. Si borras todos los datos y tratas de hacer algo, entonces tus API no funcionarán, etc. En realidad, es algo bueno. Y también, si algo en el gancho no funciona, es mucho mejor que no funcione antes de la prueba en lugar de después de la prueba. Porque si sucede después de la prueba, podría afectar a la siguiente prueba. Y si tienes la prueba número uno, prueba número dos y tu prueba número dos falla, la razón podría ser la prueba número uno si estás usando el gancho after each. Así que eso es algo que tal vez debas considerar. En general, el gancho before each funcionó mucho mejor para mí que hacer ganchos after each.

Muy bien, vamos a pasar a la primera prueba. En la primera prueba, queremos crear un nuevo carrito. ¿Qué está pasando aquí? No tengo una lista aquí, así que vamos a crear una nueva lista. Presiono la tecla Enter y ahora creo que deberíamos estar bien. Sí, lo estamos, muy bien. Esta prueba crea un carrito. Va a hacer clic en el botón de nuevo carrito y luego va a escribir `bread`. Lo hago un poco más pequeño. Creo que aún se lee bien y no envuelve mi texto. Sí, creamos un nuevo carrito y hacemos la automatización, pero queremos hacer una prueba, ¿verdad? Se podría argumentar que aún no hemos probado nada. Solo estamos interactuando con la aplicación. Creo que habría algo de mérito en esa crítica porque sí, interactuamos con la aplicación, pero al ver la prueba, no tenemos forma de saber si el carrito realmente se creó. ¿Qué sucede cuando presionamos la tecla Enter? En realidad, hay un carrito aquí. Podemos ver eso. Así que deberíamos poder ver que es visible. Voy a seleccionar este carrito y escribir una afirmación. Y para escribir una afirmación, hay este buen comando llamado should. Y este comando should nos dará todas las afirmaciones que están dentro de Cypress. Hay bastantes como puedes ver. Así que podemos buscar entre ellas. Estamos tratando de encontrar algo que sea visible y hay una afirmación be visible. Así que hagamos eso. Y voilà. Ahora hemos afirmado que ambos elementos de `bread` son visibles. Nuevamente, esto es algo en lo que podrías pensar cuando no limpio el estado de la aplicación, entonces tengo problemas. Tengo dos elementos en lugar de uno.

Muy bien, pasemos a nuestra segunda prueba y vamos a verificar si tenemos el número adecuado de tarjetas. Copié un montón de código de aquí y lo voy a pegar aquí dentro. Oh, no copié eso. Oh, hagamos eso entonces. Vamos a crear nuevamente una tarjeta. Y cuando creo eso, quiero asegurarme de que haya un cierto número de tarjetas. Vamos a crear una segunda. Así que tendremos dos. Vamos a empezar con una y creamos otra y luego hacemos una afirmación. Así que voy a seleccionar mi tarjeta nuevamente. Y quiero asegurarme de que al final de esta ejecución de prueba, tendremos dos tarjetas. Así que vamos a usar should nuevamente. Y la forma en que voy a hacerlo es verificar la mitad de la longitud de dos. Cuando guardo esto, va a pasar. Así que tengo dos tarjetas y estoy afirmando que hay dos de ellas. Ahora podrías preguntarte por qué tenemos una afirmación tan extraña aquí. ¿Por qué es la mitad de la longitud de dos? ¿Por qué no tener un recuento? ¿Por qué no tiene algo que cuente y tenemos una longitud en su lugar? Bueno, la razón de esto es que cuando usamos un comando get y ese comando get encuentra varios elementos, Cypress los va a poner todos en un array. Podemos ver eso cuando echamos un vistazo a la consola y a los detalles. Así que hice clic en el comando. Ha impreso la información en la consola. Y puedo ver este atributo yield aquí que me dice que hay dos elementos y están en un array. Aquí están. Tenemos dos elementos. Así que lo que estoy haciendo aquí en mi afirmación con should have length two es afirmar la longitud de ese array. Cuántos elementos se encontraron en el DOM. Así que sí, por eso tenemos esta longitud.

Muy bien, pasemos a la siguiente prueba. Y en esta prueba, voy a eliminar una de estas tarjetas. Y lo que voy a hacer aquí es marcar una casilla y luego asegurarme de que tenga el estado adecuado. Así que hagamos, cya.card.checkbox. Voy a usar el comando click para marcar la casilla. Y cuando lo hago, puedes ver que está marcada y tengo este fondo verde detrás de la fecha aquí. Ahora, voy a darte un pequeño consejo aquí. Si ejecuto esta prueba varias veces, puedes ver que siempre termino en un estado diferente.

Entonces, ahora la casilla de verificación no está marcada. Ahora está marcada. Si lo ejecuto nuevamente, vuelve a estar sin marcar. Si lo ejecuto nuevamente, vuelve a estar marcada. Así que en lugar de usar el comando click, lo que podemos hacer es usar el comando check. Y esto se asegurará de que cada vez que ejecutemos la prueba, terminemos en un estado marcado. Es posible que desees estar en esa situación, es posible que no quieras estar en esa situación, pero el comando check funciona para casillas de verificación y botones de opción. Así que si realmente quieres terminar en un estado marcado, el comando check es la mejor opción.

Entonces, no importa cuántas veces ejecute la prueba, siempre terminará en un estado marcado. Ahora hay dos cosas que suceden después de marcar la casilla de verificación. La primera es que la casilla de verificación está marcada. Así que podemos escribir una afirmación, buscar una afirmación de marcado, tenemos una afirmación de marcado. Así que eso es algo que está pasando, eso es genial. Y la segunda cosa está aquí. Cuando echo un vistazo, déjame abrir el panel de elementos de Inspeccionar, ahora resalto este elemento de fecha de vencimiento, está aquí, está resaltado. Y mientras interactúo con mi casilla de verificación, puedes ver aquí, tenemos una clase completada y cuando desmarco, mi casilla de verificación desaparecerá. Así que mientras interactúo con eso, está apareciendo o desapareciendo. Esto es algo que se agrega a mi elemento cuando lo marco. Así que seleccionemos mi elemento y quiero asegurarme de que se agregue la clase. Así que hagamos esto. Y quiero asegurarme de que tenga una cierta clase. Así que debería tener una clase y ese nombre de clase se llama Completado. Ten en cuenta que no estoy escribiendo punto Completado porque estoy afirmando el nombre de la clase. Así que no estoy como, el punto Completado sería como cuando quiero seleccionar algo, pero esto es simplemente el nombre de la clase. Así se llama la clase. Debería tener la clase Completado sería entonces la afirmación. Así que guardémoslo. Y mientras me aseguro de que la casilla de verificación esté en el estado correcto, también me aseguro de que la clase esté, que el elemento tenga una cierta clase.

Muy bien, una prueba más que quiero mostrarte, luego puedes comenzar a codificar. Y el elemento que tenemos es un nombre de lista correcto. Así que queremos asegurarnos de que este nombre de lista tenga un nombre correcto. Así que vamos a verificar el texto de ese elemento. Así que lo seleccionamos, cya.list.name y hago la afirmación should have text de una nueva lista. ¿Correcto? Guardémoslo y veamos qué sucede. Mi prueba está fallando. Entonces, ¿por qué es eso? Bueno, puedes ver el error que dice que queríamos tener un texto nueva lista, pero el texto estaba vacío. Entonces, ¿qué está pasando aquí? Podemos ver claramente la lista. Entonces, ¿por qué es eso? Ahora, si echamos un vistazo, a través del elemento de inspección y echamos un vistazo a nuestro elemento, podemos ver que esto es en realidad un elemento de entrada. Y realmente no vemos el texto, el texto de la nueva lista dentro de aquí. Y eso se debe a que el elemento de entrada es un elemento HTML5 que realmente contiene la entrada del usuario. Así que en realidad contiene un valor. Y aunque podemos ver eso, podemos verlo como un texto, no es un texto, es un valor de ese elemento. Así que es diferente de un elemento de encabezado o un elemento de párrafo o un elemento div, que tendría una etiqueta de apertura y cierre y un texto entre los elementos de entrada no tienen una etiqueta de apertura y cierre. Es solo un elemento de entrada. Y contiene ese valor que ingresa el usuario. Entonces, dado que esta aplicación utiliza estos elementos de entrada para mostrar el nombre de la lista, la afirmación correcta no sería have text sino have value. Y ahora está pasando. Así que la situación sería diferente en comparación con, por ejemplo, este elemento de pan que podemos ver que este es un elemento div, ¿verdad? Entonces, esto es un div y podemos ver el texto pan aquí. Entonces, en este caso usaríamos have text pero en el caso de una entrada u otra cosa que contenga un valor, tendríamos un have value.

Tengo una pregunta de Sebastian. Él dice, ¿puedes mostrarnos cómo aseguras que tus pruebas se puedan ejecutar repetidamente, por ejemplo, ejecutar pruebas de humo varias veces durante el día? Tal vez haya algo más adelante para aclarar esto. Bueno, la forma en que hay múltiples formas y esto realmente no es una pregunta de Cypress, sino una pregunta sobre cómo diseñar nuestras pruebas. Para que sean repetibles y cuando las ejecutes en paralelo no interfieran entre sí, etc. Y hay mucho que se podría decir al respecto. Así que no voy a entrar en eso, pero lo que me gusta hacer es, en algunas de las pruebas mencioné que al principio tengo este script que borrará la base de datos y la generará con los datos correctos. Entonces, generar la base de datos sería una de las formas de hacerlo, asegurarse de que antes de comenzar la prueba tengas los datos adecuados. Otra forma sería utilizar llamadas a la API para crear la información y los recursos que deseas para esa prueba y luego abrir tu interfaz y interactuar con los datos creados. Así que eso podría ser una forma de hacerlo. Y otra forma sería utilizar objetos de página y simplemente crear lo que deseas a través de la interfaz antes de comenzar a probar lo que deseas. No es la forma ideal, solo usar la interfaz para todo, pero a veces estás limitado a eso. Así que sí, esa sería mi respuesta breve a una pregunta muy compleja. Y obviamente hay múltiples estrategias de cómo puedes hacer eso. Lo que hago dentro de esta aplicación, tengo esto para enviar una solicitud como esta para avanzar, pero tengo una API de restablecimiento y eso básicamente hace lo mismo. Estoy enviando una solicitud HTTP para restablecer la aplicación. Y cuando presiono F2 y hago clic en este botón, básicamente está haciendo lo mismo. Simplemente restablecerá toda la base de datos. Pero sí, esta es solo la aplicación de prueba. No vas a tener una solicitud HTTP como esta disponible para ti. Pero sí, pondría todo lo que necesito hacer en el before each y luego me aseguraría de que estas pruebas realmente dependan de que se realicen las acciones del before each.

Y eso es como el estado en el que quieren comenzar. Así que aquí podría tener como restablecimiento de la base de datos o configurar el escenario para algo, básicamente, si conoces la estructura de organizar, actuar, afirmar para tu prueba, entonces en el beforeEach, tendría toda la parte de organizar, y luego el actuar comenzaría en el bloque de visit o algo así. Y luego habría una afirmación o un par de afirmaciones en realidad. Así que sí, gracias por esa pregunta.

Muy bien, tenemos un par de desafíos en este capítulo también. Me gustaría que los intentes. También me gustaría tener un pequeño descanso. Así que tal vez fusionemos eso en una sola cosa, y podemos encontrarnos de nuevo en unos 15 minutos, y luego continuaremos con el resto de la masterclass si eso está bien. Espero que hayas tomado algo para refrescarte. Tal vez también hayas tenido la oportunidad de codificar un poco. Así que ahora podemos pasar a los siguientes capítulos.

Y una de las cosas más importantes que me gusta enseñar en mi masterclass es este encadenamiento y reintentos que ocurre en Cypress. En realidad, es algo muy importante, que incluso si estás leyendo la documentación, a veces se pasa por alto. Y es realmente importante que puedas escribir pruebas estables y asegurarte de que no se vuelvan inestables. Así que hay un par de principios que me gustaría explicar en este capítulo. Ahora, una cosa sería cómo funcionan los comandos encadenados en Cypress. También el reintentos incorporados y cómo escribir comandos efectivos en cadenas y asegurarse de cómo escribir una prueba si tu aplicación es inestable. Así que, pasemos a la demostración y sí, hagamos la demostración, encadenamiento y comienzo de la demostración. Muy bien, de nuevo, tengo tres pruebas aquí. Así que comenzaré con la primera, uno dos comienzo de la demostración. Y aquí lo tenemos. Muy bien, tengo esta lista de compras. Puedes ver que estoy un poco atrasado en mis compras. Ya es fin de año y tengo artículos de marzo y febrero aquí. Así que déjame explicarte un par de conceptos aquí y el primer concepto que me gustaría explicar es el encadenamiento. Así que sigamos adelante e intentemos encontrar una tarjeta con una fecha de vencimiento el primero de marzo. Entonces, lo que puedo hacer, ya te lo mostré en el ejemplo anterior, puedo usar, si tengo un texto, puedo ir y hacer contains. Así que si selecciono un elemento que contiene el texto 02 de marzo de 2022, entonces encontrará un elemento y no estoy seguro de qué tan bien se puede ver, pero ha encontrado este elemento aquí dentro. Aquí están los aspectos destacados. No estoy seguro de qué tan visible está eso. Pero sí, esta es la que quiero. Así que cuando examino más de cerca mi aplicación, puedo ver que hay otro que tiene el 01 de marzo de 2022. Entonces, ¿por qué el contains solo selecciona uno? Bueno, la respuesta es simple, así es como funciona el comando contains. En comparación con el comando get, el comando get simplemente encontrará y seleccionará todos los elementos que básicamente son iguales al selector que hemos dado, ¿verdad? Entonces, si seleccionamos un div, encontrará todos los divs. Si seleccionamos algo con la clase, encontrará todos los elementos con la clase, con una cierta clase. Con cy-contains, en realidad solo encontrará el primer elemento dentro del contexto. Ahora, ¿qué quiero decir con dentro del contexto? Hay un concepto muy importante en Cypress llamado encadenamiento. Y cuando hablamos de encadenamiento, tenemos tres tipos de comandos en Cypress. Entonces, el primer tipo es un comando principal, el segundo tipo es un comando secundario y el tercer tipo es un comando dual. Ya hemos visto todos en acción. Un ejemplo de un comando principal sería este cy.visit. Así que cada vez que usamos un comando principal, será un cy y luego algo, el nombre del comando. Luego tenemos comandos secundarios. Entonces, un comando secundario típico sería un click. Si queremos hacer clic en algo, no podemos simplemente hacer cy.click. Así no es como funciona Cypress. No va a hacer clic en cualquier lugar. Necesita un elemento. Antes de eso, primero debemos hacer get o contains o básicamente seleccionar un elemento y luego podemos hacer clic en él, ¿verdad? Entonces, el comando click, ese sería un ejemplo de un comando secundario. Ahora, el comando contains es en realidad un ejemplo de un comando dual. Este va a comportarse de manera diferente según si está encadenado del objeto Cy o si está encadenado de algún elemento diferente. Permíteme mostrarte eso en acción. Tengo contains March 01. Permíteme duplicarlo, pero con el segundo, vamos a seleccionar este segundo elemento y la forma en que lo voy a hacer es utilizando el encadenamiento. Primero, voy a seleccionar mi lista. Así que hagamos cy-list. Básicamente, esto encontrará dos elementos. Encontrará esta primera lista y la segunda lista. Entonces, lo que voy a hacer es hacer EQ uno. Recuerda, estamos numerando desde cero, así que esto sería cero y esto sería uno. Entonces, en este caso, EQ uno seleccionará este elemento y luego usaré el comando contains. Eso es todo. Así que ahora, cuando guarde mi prueba, aunque el contains tiene el mismo argumento aquí y aquí, se comportará de manera diferente. Entonces, si paso el cursor sobre este primer comando contains, encontrará este elemento. Si paso el cursor sobre el segundo comando contains, puedes ver que encuentra este elemento aquí. La forma en que funciona puede revelarse muy bien utilizando la consola. Abriré la consola y haré clic en mi comando get. Cuando hago clic en él, puedo ver que este comando get con su selector nataseylist ha encontrado dos elementos. Y lo tenemos aquí, tenemos este parámetro yielded. Y vemos lo que el comando ha encontrado realmente y lo que está pasando al siguiente comando.

Esto es lo que sucede con las cadenas de comandos en Cypress. Si observo el comando EQ, puedes ver que se aplica exactamente a esos dos elementos que el comando get ha encontrado. Es el array de dos elementos. El comando EQ está utilizando eso. Y nuevamente, está produciendo algo, por lo que ha filtrado el segundo elemento. Se produce el segundo. Podemos ver esto, hay un div, etc. Entonces, cuando hago clic en contains, nuevamente puedes ver que se aplica a ese elemento. El que el comando EQ ha pasado. Así es como funciona Cypress. Va a pasar información de un comando a otro hasta que hagamos algo con eso, hagamos una afirmación o hagamos clic en él o algo así. Entonces sí, el encadenamiento, un concepto muy importante en Cypress. Muy bien. Otro concepto muy importante en Cypress es la retrialidad. Así que echemos un vistazo a la segunda prueba. Guardo mi prueba y puedo ver que en realidad está tratando de afirmar que hay cinco elementos de tarjeta. Tengo este texto de tarjeta. Va a encontrar cinco elementos y los ha encontrado. Entonces la prueba ha pasado. Ahora, si cambiara este número de cinco a seis y guardara mi prueba, puedes ver que en realidad no falla de inmediato. En realidad está volviendo a intentar y tratando de encontrar esos seis elementos en la página hasta que finalmente la prueba va a fallar. Ahora, si estás trabajando con Selenium, es posible que conozcas esto como un tiempo de espera fluido. Olvidé si era fluido o fluido. Uno de esos. Básicamente, tenemos un límite superior de cuánto tiempo queremos esperar hasta que declaremos que la prueba ha fallado. Entonces, si quiero tener seis elementos, básicamente, el sexto elemento puede aparecer durante ese período de tiempo y la prueba va a pasar, como puedes ver aquí, así que si tengo seis, creo otra tarjeta, ahora está pasando. Ahora, puede haber otro. Oh, una cosa que quiero señalar es que tenemos este comando should que tiene la afirmación de que deberíamos tener seis elementos. Ahora, no solo se vuelve a intentar la afirmación, sino que también se vuelve a intentar el comando anterior. Porque si la afirmación no se cumple, si no hay seis elementos, volveremos a consultar los elementos en el DOM y básicamente llamaremos a ese comando get una y otra vez. Entonces, si tenemos una afirmación como esta, podemos pasar un tiempo de espera más largo y asegurarnos de esperar un período de tiempo más largo. Entonces, hagamos un tiempo de espera y hagamos 60 segundos, ¿verdad? Así que cuando guarde eso ahora, y veas que no hay seis elementos en la página, puedes ver que Cypress está volviendo a intentar, volviendo a intentar, volviendo a intentar hasta que finalmente cuando agrego ese sexto elemento, la prueba va a pasar. Ahora, lo que puede suceder no solo esto, sino que podemos tener un problema opuesto. Entonces, lo que voy a hacer, tengo este código malicioso preparado aquí y tengo esta función cards load slowly, que va a cargar las tarjetas en mi tablero durante más tiempo, así que este es un truco que tengo para mi aplicación. Ahora, si echas un vistazo, oh, vamos a hacer esta inserción a cinco. Entonces, la prueba debería pasar, ¿verdad? Si observas lo que está sucediendo aquí, las tarjetas se están cargando, la prueba falla, pero eventualmente, nuestras tarjetas aparecen, ¿verdad? Entonces, si tenemos una aplicación lenta, esto podría ser un problema, ¿verdad? Porque las tarjetas eventualmente aparecen, por lo que no deberíamos declarar que la prueba ha fallado, probablemente debería pasar. Ya te mostré la solución. Podemos hacer que ese tiempo de espera sea un poco más largo, podemos hacer que ese reintentar sea un poco más largo, por defecto, son cuatro segundos, pero podemos hacerlo más largo. Hagámoslo seis segundos, así que ese es el tiempo en milisegundos, ¿verdad? Entonces, cuando lo guarde ahora, y las tarjetas tardan cinco segundos en cargarse, todavía se cargarán a tiempo para que la prueba pase. Y, por supuesto, incluso si pongo como 60 segundos, mi prueba va a pasar cuando encuentre esos cinco elementos, por lo que no va a esperar 60 segundos completos, solo el tiempo máximo necesario, y luego procede a terminar la prueba o pasar al siguiente comando. Entonces, podemos cambiar ese tiempo de espera tanto a nivel de comando como a nivel de prueba. La forma en que podemos hacer eso es, como mencioné, la función ID tiene dos parámetros, ¿verdad? El primero es el nombre de la prueba, el segundo es una devolución de llamada, pero en realidad podemos hacer que el segundo sea un objeto y que sea como un objeto de configuración de prueba. Entonces, lo que podemos hacer aquí es definir el tiempo de espera de comando predeterminado y decir que debería ser de seis segundos. Entonces, cuando guarde esto, todos los comandos en realidad ahora tendrán no los cuatro segundos por defecto, sino seis segundos de tiempo de espera por defecto. También podemos definir eso no solo a nivel de prueba, sino que podemos hacerlo para todo el conjunto de pruebas. Entonces, si vamos a tiempo de espera de comando predeterminado, oh, lo siento, eso no es un objeto e2e, en realidad está fuera de él. Podemos decir que, bien, estamos probando una aplicación bastante lenta, por lo que hagamos que el tiempo de espera de comando predeterminado no sea de cuatro segundos, sino de seis segundos. Entonces, sí, eso es algo que deberías hacer. Aunque no recomendaría poner ese tiempo de espera de comando en un número muy alto, porque no solo significa que tus pruebas van a tener una reintentabilidad más larga, también significa que van a tardar mucho más tiempo en fallar, lo que podría ser un problema si tienes cientos de pruebas. Si agregas solo un segundo y 60 de tus pruebas deberían fallar, entonces acabas de agregar un minuto de espera a tu prueba, o no un minuto, porque si están fallando, obviamente están tardando más tiempo. Entonces sí, básicamente trata de mantener este número lo más bajo posible, por supuesto, dentro de límites razonables. Muy bien, pongamos todo esto junto. Tenemos el encadenamiento, tenemos la reintentabilidad. Ahora echemos un vistazo a la tercera prueba donde combinamos estos dos conceptos. Tengo otro código malicioso aquí y eso carga las tarjetas al azar. Así que hagamos tres segundos aquí, lo que esto va a hacer es que no todas las tarjetas se cargarán al mismo tiempo, sino que se cargarán al azar, por lo que las tarjetas en la primera lista se cargarán primero o las tarjetas en la segunda lista se cargarán primero. Lo que eso significa al mirar la prueba, tal vez puedas darte cuenta, tal vez no, lo que significa es que estamos seleccionando las tarjetas, ¿verdad? Tan pronto como encontremos las tarjetas, queremos seleccionar la segunda y asegurarnos de que el texto sea `breadth`. Ahora la segunda es `breadth`, ¿verdad? Pero si ejecutamos la prueba un par de veces, podríamos encontrarnos en una situación en la que nuestra prueba fallaría. Intentemos llegar a esa situación, y aquí está. Nuestra prueba está fallando. Y ¿por qué es eso? Bueno, la línea de tiempo nos lo dirá, ¿verdad? Si paso el cursor sobre mi comando EQ, puedes ver que no está seleccionando esta primera tarjeta, ¿verdad? Esta, pero está seleccionando la segunda. Ahora, ¿por qué es eso? ¿Cuál es la razón detrás de eso? Bueno, la razón es que las tarjetas en la segunda lista se cargaron primero, lo que significa que encontramos algunas tarjetas. Luego filtramos la segunda, que era esta tarjeta de jabón en este caso, y afirmamos que contiene el texto `breadth`. Entonces, el problema aquí es que cuando hablábamos de reintentabilidad, ya mencioné eso. Cuando tenemos una afirmación, hará que el comando anterior vuelva a intentar, ¿verdad? Pero no hará que toda la cadena vuelva a intentar. Entonces, lo que sucede es que quedaremos atrapados en un bucle infinito entre estos dos elementos, donde entre estos dos comandos, donde el comando EQ simplemente está filtrando y filtrando, y aún está filtrando esos dos elementos que el comando get ha encontrado, porque este no volverá a intentar. Y nuestro comando shoot está tratando de afirmar algo que simplemente nunca va a cambiar, porque el comando EQ ya está trabajando con esos dos elementos que estaban allí antes. Entonces, si echas un vistazo a la consola, eso puede ser más claro. El comando get encontrará dos elementos. Tan pronto como encuentre dos elementos, pasará al siguiente comando.

Entonces, el siguiente comando es eq, va a tomar esos dos elementos y filtrar el segundo, ¿verdad? Y luego tenemos una afirmación. Esa afirmación no está pasando, ¿qué hacemos? Hey, intentemos ese comando que estaba aquí antes de nuevo. Así que lo intentamos de nuevo, pero eso solo se aplica a esos dos elementos. Va a hacer lo mismo, solo va a filtrar el segundo elemento y básicamente nunca va a llegar a ese comando get nuevamente. Entonces, eso es algo de lo que debes tener en cuenta al escribir tus pruebas, porque si te encuentras en una situación en la que no todos tus elementos se cargan al mismo tiempo o tienes una lista de elementos que cambia, etc., entonces podrías encontrarte en una situación en la que tu prueba se vuelva inestable debido a eso. La forma en que podemos solucionar eso en este caso es simplemente eliminar el EQ y simplemente vamos a buscar todos los elementos e intentar encontrar el que contiene el texto 'breadth'. Si bien esto puede no ser la solución ideal aquí, tendremos la reintentabilidad entre shoot y get aquí, y hay diferentes estrategias de cómo podemos abordar eso. Tal vez lo que podemos hacer es agregar una afirmación de protección. Entonces, primero nos aseguramos de tener cinco elementos en la página y solo después de afirmar que tenemos cinco elementos, pasamos al comando EQ que filtrará los elementos y luego reescribimos nuestra afirmación. Eso podría ser una forma de hacerlo, y nuevamente, hay varias formas de manejar eso. Muy bien, eso es todo para la reintentabilidad y el encadenamiento. Tengo un desafío para ti, pero en este punto, me gustaría preguntarte si quieres hacer el desafío o si prefieres pasar al siguiente capítulo, porque tenemos alrededor de 50 minutos y todavía nos quedan un par de capítulos por delante. Así que tal vez puedas darme un emoji de pulgar hacia arriba si quieres. Oh, gracias, siguiente capítulo. Adelante. Muy bien. Gracias. Usar el chat es probablemente la forma más rápida. Muy bien, tal vez, sí, todavía tienes el repositorio, todavía tienes todos los desafíos, así que puedes probarlo por tu cuenta y luego podemos pasar al siguiente capítulo. Muy bien, afirmaciones de Chai. Muy bien. Voy a hacer esto rápido porque básicamente esto es solo otra forma de escribir el mismo código. Así que hagamos esto rápidamente y luego pasemos a las solicitudes HTTP y la interceptación porque eso es divertido. Muy bien, hagamos esa demostración de afirmaciones de Chai. Muy bien, lo tengo. Bueno, me confundió porque tengo los mismos datos aquí. Muy bien, en esta primera prueba, lo que estoy haciendo es verificar el texto de una primera tarjeta. Quiero asegurarme de que tenga el texto 'milk'. Así que eso es lo que estoy haciendo. Tiene el texto 'milk'. La prueba está pasando. Ahora, con el comando shoot, puedo escribir una afirmación muy simple. Pero lo que también puedo hacer es, en lugar de escribir mi afirmación así, puedo usar el comando then. Entonces, lo que hace el comando then es que tomará lo que el comando get tiene, lo pasará, lo que ha pasado, y luego hará toda clase de lógica dentro de aquí. Así que si simplemente sigo adelante y lo registro en la consola. Entonces, tarjeta entonces, y abro la consola, puedes ver que tengo mis elementos aquí. Así que todos están aquí, están envueltos dentro de una función jQuery, eso es solo una nota al margen, pero sí, mi comando get ha encontrado cinco elementos. Y si uso mi comando then y registro en la consola el parámetro, simplemente se registrará en la consola esos cinco elementos. Entonces, lo que puedo hacer es no solo eso, pero probablemente podría escribir una lógica personalizada si quisiera, pero lo que puedo hacer es usar una de las herramientas incluidas en Cypress llamada chai, así que hay esta función expect, que puedo usar para escribir una afirmación. Así que espero que la tarjeta tenga el texto 'milk', y dado que esto es en realidad una matriz de elementos y estoy haciendo referencia y estoy tratando de escribir una afirmación para el primero, en lugar de EQ, puedo simplemente hacer referencia a ese elemento de matriz para que con el número de índice cero sea el primer elemento en la matriz. Entonces, el primero. Así que si guardo esto, para tener texto era eso, esto está fallando. Oh sí. No escribí la M mayúscula. Escribí la m minúscula. Así que corrijámoslo ahora. Y ahora mi prueba está pasando, ¿verdad? Entonces, lo que hice es básicamente lo mismo que hice antes. En lugar de escribir EQ, cero debería tener texto 'milk', usé el comando then para escribir una afirmación de chai. Ahora estas afirmaciones de chai, básicamente están incluidas en Cypress. Lo que hace el comando should es simplemente un envoltorio alrededor de estas afirmaciones de chai. Y hay muchas de ellas, déjame mostrarte. En las afirmaciones de Cypress, la documentación en realidad tiene toda la lista de todo lo que hay aquí. Así que tenemos chai y chai de jQuery y todo tipo de bibliotecas diferentes que están incluidas. Están listas para que las uses en Cypress. Entonces, cuando uso el comando should y tengo el autocompletado de toda la lista allí, eso fue simplemente envuelto dentro del comando should. Ahora, esta sintaxis es básicamente esas afirmaciones simplemente desenrolladas y escritas en JavaScript plano. Entonces, dentro de la función then, podemos hacer cualquier cosa. Es solo JavaScript plano allí. Así que podemos escribir declaraciones if y bucles for, y cosas así si quieres. De acuerdo, pasemos a la siguiente prueba. De hecho, te mostraré cómo es útil. ¿Por qué es útil escribir la función then? Porque honestamente esto es un poco más complicado. Cuando teníamos el comando shoot, eso era bastante ordenado, agradable. Pero en este caso, estamos usando EQ cero, EQ uno, EQ dos. Estamos siendo realmente repetitivos con nuestras pruebas. Porque estamos obteniendo todos los elementos y luego filtrando, obteniéndolos y luego filtrando, etc. Entonces, en lugar de hacer eso, lo que voy a hacer es refactorizar esto para hacer lo mismo, pero de manera menos repetitiva. Elimino todo esto. Y cuando obtengo mis elementos, en realidad va a devolver cinco elementos.

Entonces, en lugar de filtrarlos por EQ, simplemente voy a usar el comando then, luego pasar una función de devolución de llamada y como parámetro, lo que obtendré son esos elementos. Los llamaré tarjetas y escribiré un par de afirmaciones. Así que hagamos expect cards. Y escribiré un par de afirmaciones aquí. Así que hagamos esto expect cards para tener texto. Y luego agregaremos esos textos. Así que esto será cero, uno, dos, y luego tendremos leche, pan y jugo. ¿Correcto? Así que básicamente tenemos la misma prueba. Cuando la guardo, hará lo mismo pero con menos código. Así que podemos escribir múltiples afirmaciones a la vez, lo cual es genial, ¿verdad?

Ahora, me gustaría mostrarte una cosa aquí. ¿Qué sucede si tienes una lista, pero esa lista en realidad se renderiza durante un instante en un orden y luego se ajusta al orden correcto un instante después? Eso puede suceder. Probablemente hayas visto que sucede. Si no, entonces tienes suerte. Así que voy a cambiar esta afirmación y voy a decir que el segundo elemento tiene el texto jugo y el tercer elemento tiene el texto pan, ¿verdad? Entonces esta no es una orden incorrecta o más bien esta afirmación no está en el orden incorrecto con esta. Cuando guardo mi prueba, por supuesto, como esperarías, fallará. Pero lo interesante de esto es, mira el número aquí. Esto está fallando bastante rápido. Así que son como 599 milisegundos. Entonces, ¿dónde están nuestros cuatro segundos, verdad? Entonces, ¿por qué no se reintentan? Y la respuesta es que no todos los comandos en Cypress tienen esa lógica de reintentos y la función then es uno de ellos. Entonces, ¿qué hacemos cuando queremos reintentar esas afirmaciones? ¿No es una opción? Bueno, es una opción. Podemos hacerlo así. Podemos cambiar nuestra función then por una función should. Y de esta manera, lo que sea que esté dentro se reintentará hasta que devuelva true, se reintentará. Entonces, cuando guardo esto ahora, verás que está esperando que ocurra el orden correcto. Hacer que falle. Ejecutarlo de nuevo. Y tan pronto como el orden se vuelva así, pasará. Así que ahora tengo una prueba que pasa y múltiples afirmaciones que se están ejecutando. Y tan pronto como el código interno devuelva true, pasará. Esto es bueno. Estamos probando múltiples cosas a la vez simplemente cambiando ese comando then por shoot. Entonces sí, esa fue una breve demostración de cómo puedes escribir diferentes tipos de afirmaciones. Se llaman afirmaciones de chai. Y el comando shoot nuevamente es solo un envoltorio alrededor de ellos. Entonces sí, ¿hay ventajas de usar then en lugar de shoot? Sí, las hay. Si estás probando APIs, porque cuando estás probando APIs, cuando usas request, básicamente lo que vamos a estar hablando en un segundo, entonces una vez que llegue la respuesta, simplemente tendrás esa respuesta. Entonces, tener shoot con un reintentos de cuatro segundos no tiene sentido. Porque si lo hicieras, esperarías que algo cambie, algo que nunca cambiará. Estarías esperando que algo que nunca cambiará cambie. Esa es una oración extraña, pero sí, eso es lo que es. Entonces, podrías estar en una situación en la que simplemente quieras usar then en lugar de shoot. Solo ten en cuenta que then no es simplemente una función shoot sin capacidad de reintentos. Entonces no puedes hacer algo como then, y luego tener como visible o algo así. Eso no funciona. No es uno a uno. Es una función diferente. Es solo que puedes usar shoot con una función de devolución de llamada que se puede reintentar. Así que sí.

De acuerdo, vamos a, por cierto, me olvidé por completo de mi presentación. De acuerdo, sigamos con el siguiente. Eso son las solicitudes HTTP. Por cierto, sigan haciendo esas preguntas. Me encanta que estén preguntando.

De acuerdo, entonces las solicitudes HTTP. Aprenderemos cómo enviar una solicitud HTTP, cómo probar la respuesta, cómo configurar diferentes atributos y cómo restablecer la aplicación Trello, la que estamos probando. Así que hagamos algunas pruebas. Demo y demo.

De acuerdo. Filtraré el primero. Lo guardaré. Y en realidad no estoy haciendo nada en esta prueba. Solo estoy usando cy.visit para abrir mi aplicación. Entonces, lo que puedo hacer en Cypress es usar este comando llamado cy.request. Y enviará una solicitud HTTP. Por ejemplo, si quiero crear un nuevo tablero utilizando solicitudes, lo primero que haría es consultar la documentación. Pero sé que eso no siempre es el caso. No todos escriben la documentación. Pero sí, eso sucede. Lo que podemos hacer es aprender sobre la aplicación y lo que está haciendo observando lo que está haciendo. Entonces, si sigo adelante y creo un nuevo tablero, y hago clic en el botón para crear un nuevo tablero, en realidad puedo ver las solicitudes HTTP que ocurren aquí. Así que puedo ver que tan pronto como presiono la tecla Enter o hago clic en Crear tablero, hay una solicitud POST a la API de tableros que está creando esa solicitud. Y si examino los detalles, veré el cuerpo de la respuesta. No veo el cuerpo de la solicitud, no estoy seguro de por qué, pero sí está en algún lugar allí.

Entonces, lo que podemos hacer es imitar ese comportamiento. Podemos intentar crear nuestro tablero utilizando una API. Así que hagamos una solicitud, y lo que voy a hacer aquí es usar el método POST. Usaré la URL de la API de tableros, tal como la que tenemos aquí. Y luego pasaré un tercer argumento a nuestro comando de solicitud, y ese será el cuerpo. Entonces, ese será el objeto que queremos enviar al servidor. Y como conozco la aplicación, porque la hice, sé que hay un atributo de nombre, que será el nombre de nuestro tablero. Así que será 'tablero creado por API'. Entonces, cuando guarde mi prueba ahora, puedo ver que mi 'tablero creado por API' está aquí. Y la razón de eso es que he enviado la solicitud. Así que aquí está mi comando de solicitud, aquí está mi comando de visita. Entonces, cuando hago clic en la solicitud y examino los detalles, puedo ver los detalles de esa solicitud. Veré el cuerpo de la solicitud, veré los encabezados, la respuesta, el estado. Y ya tengo mi atributo 'yielded' aquí. Y sabes lo que eso significa. Podemos probar cualquier cosa que esté aquí. Podríamos usar la función then que acabamos de usar. Eso funcionará. Escribiremos un par de afirmaciones, etcétera. Pero también podemos hacer algo como esto. Podemos simplemente usar el comando its. Y realmente me gusta este porque simplemente echará un vistazo a este objeto y tomará cualquier atributo que necesitemos. Por ejemplo, podemos echar un vistazo a su cuerpo. O no, sabes qué, echemos un vistazo al estado. Así que echemos un vistazo al estado y vemos que el estado es 201. Así que usemos el comando should y debería ser igual a 201. Y puedo eliminar esta visita y ahora solo tenemos una prueba de API pura aquí. Estamos comprobando el estado y es igual a 201. Por cierto, acabo de tener la pregunta, ¿verdad? ¿Cuál es la diferencia entre then y should? Ahora dije que el comando should tiene la capacidad de reintentar y lo reintentará. Entonces, no tiene mucho sentido usarlo con cy.request y sigo pensando lo mismo. En caso de que estés haciendo algo como esto, recomendaría usar un tiempo de espera de cero para que no reintente esto. Y si pongo algo como err a 00 aquí, fallará de inmediato. Si no tuviera el tiempo de espera aquí y lo guardara, intentaría reintentarlo y asegurarse de que el 201 eventualmente se convierta en 200, pero eso simplemente no va a suceder. Así que sí, este es un truco para lograr eso, pero en este caso es una prueba muy, muy simple. Si solo quieres asegurarte de que la prueba sea realmente simple y solo quieres verificar el código de estado o algo así, puedes hacerlo así. Es una forma abreviada de probar tu API, pero si quieres probar algo más complejo, entonces recomendaría hacerlo con el comando then.

De acuerdo, asegurémonos de que la respuesta obtenga un estado 201. Me pregunto si estoy mostrando algo nuevo aquí. En este caso, déjame echar un vistazo a mi... Sí, ya lo mostré, así que pasemos a la siguiente prueba en su lugar. Prueba de lista de tableros. De acuerdo, aquí quiero, en lugar de enviar algunos datos a la base de datos, obtener algunos datos de la base de datos. Así que voy a usar la solicitud y ya te mostré esta sintaxis simple donde tendrías tres argumentos básicamente, ¿verdad? Entonces, el primero sería el método, el segundo sería la URL y el tercero a partir de aquí sería el cuerpo, ¿verdad? En lugar de pasar argumentos así, podemos ser más complejos con nuestra solicitud. Así que voy a pasar un objeto y en ese objeto voy a definir todo.

Entonces, el método en este caso será get, la URL será API boards y no estamos enviando nada aquí, así que mantengámoslo así. Cuando lo guarde, devolverá 200, pero hay un detalle en este caso y esto es muy específico de mi aplicación, así que no se aplica en todas partes, pero en mi aplicación, cuando uso un comando get y no especifico qué tipo de respuesta quiero del servidor, va a responder con un HTML. Así que puedes ver aquí hay un HTML para el cuerpo de la respuesta, lo cual no es algo que quiero. En este caso, quiero tener la respuesta en formato JSON. Por lo general, si quieres enviar alguna información al servidor, son los encabezados donde estaría, así que hagamos los encabezados y especifiquemos el cuerpo de la respuesta. Entonces, especificaré la propiedad de los encabezados para tener un accept y application JSON, así es como se especifica eso. Así que si guardo mi prueba ahora, en lugar de obtener ese HTML, tendré el cuerpo de la respuesta. Tengo la lista de todos los tableros que he creado hasta ahora. Puedes ver que he creado bastantes tableros creados a través de API boards mientras hacía esta prueba. Así que sí, estos son todos los tableros en mi base de datos y lo que puedo hacer ahora es escribir una afirmación, así que usemos then y usemos board y escribiré un par de afirmaciones, así que hagamos expect y quiero que el estado del tablero sea igual a 200. Así que aquí tengo la verificación del estado. Quiero asegurarme de que el cuerpo del tablero tenga una longitud de, ¿cuánto es? Siete, ¿verdad? Y cosas así. Puedes hacer todo tipo de pruebas. Por cierto, solo un poco de publicidad aquí, tengo un taller de API próximamente, así que si estás interesado en eso, creo que deberías inscribirte y mostraré diferentes formas de cómo puedes probar APIs utilizando Cypress. Muy bien, una cosa más que quiero mostrarte. Ya te lo mostré un poco, pero hay una API para restablecer mi base de datos. Así que voy a hacer una solicitud POST a api-reset. Y cuando lo guarde, restablecerá mi base de datos. Pero en lugar de tener esto como una prueba, lo que puedo hacer es usar esto como un before, oops. Entonces, de esta manera, cuando guarde mi prueba, fallará y creo que está fallando porque una de las afirmaciones aquí y tiene una longitud de uno en lugar de dos. Así que sí, las pruebas se están mezclando entre sí. Por eso está fallando ahora. Pero sí, tengo este gancho before, que limpia el estado y luego tengo un par de pruebas que se ejecutan dentro de esta especificación. El uso del comando request es realmente útil para este propósito, donde puedes usar un montón de llamadas a la API para preparar tu aplicación y luego abrir tu aplicación exactamente donde quieres que se abra. Así que sé que hay una convención de usar objetos de página básicamente para configurar un tipo de estado donde pasarías por diferentes pasos para llegar básicamente al punto de interés que realmente quieres probar. Con la, cómo lo diría, mi estrategia personal es, aunque estamos en pruebas de interfaz de usuario, aconsejaría usar la interfaz de usuario lo menos posible. Si puedes evitar usar la interfaz de usuario, evítalo, solo usa la interfaz de usuario para probar la historia de usuario en la que estás interesado. Entonces, si tienes 100 pruebas, no quieres iniciar sesión 100 veces, solo quieres tener una prueba que pruebe el inicio de sesión y luego todas esas otras pruebas, solo abres tu aplicación en un estado de sesión iniciada. Si tengo un tablero, no quiero crear un nuevo tablero antes de cada prueba utilizando la interfaz de usuario, solo llamo a una API para crear mi tablero y luego abro mi prueba en los detalles del tablero porque eso es lo que quiero probar. Y las solicitudes pueden ser realmente, realmente útiles para eso, solo para configurar el escenario para tu prueba. Así que sí, esas son las solicitudes HTTP. Siéntete libre de hacer cualquier pregunta. Voy a tomar agua. Muy bien. Parece que realmente lo lograremos. Así que voy a mostrarte probablemente la parte más divertida de Cypress ahora. Esto es interceptar solicitudes. Te mostraremos cómo observar las solicitudes de API que realiza nuestra aplicación, cómo probar esas solicitudes de API y cómo estabilizar una prueba inestable. Y te mostraré diferentes formas de hacer coincidir las solicitudes. ¿Qué quiero decir con interceptar? Bueno, déjame mostrarte. Demostración comienza. Abramos la demostración, comencemos aquí también. Genial. Entonces, el tablero no tiene listas, no, en realidad quiero esta primera prueba. Muy bien, en esta prueba, tengo un escenario que hemos visto un par de veces, ¿verdad? Estamos creando un nuevo carrito. Entonces, en este nuevo carrito, ¿qué sucede cuando creo un nuevo carrito? Si nos enfocamos en las API, puedes ver que se llama a POST API carts. Ahora lo que puedo hacer en Cypress es combinar el aspecto de la interfaz de usuario de mis pruebas con la API. Y déjame mostrarte a qué me refiero con eso. Voy a escribir un nuevo comando aquí. Se llama intercept. La sintaxis es en realidad algo similar a lo que tenemos en nuestra solicitud de alguna manera en la que tenemos la primera parte donde pasamos el método y la segunda parte donde pasamos la URL. Así que usé el comando y puedes ver que hay esta especie de alias aquí. Y también hay esta tabla de rutas que me dirá cuáles son las solicitudes de API que Cypress está observando ahora. Esto es lo que hace el comando intercept. Lo que realmente hace el comando intercept es decirle a Cypress que observe ciertas llamadas de API que deben ocurrir. Así que en lugar de enviar esas. La gran diferencia entre request e intercept es que con request, soy yo quien envía esa solicitud de API, ¿verdad? Algo así como Postman o algo así. Con intercept, no estoy enviando nada. Simplemente estoy interactuando con mi aplicación y mi aplicación está realizando las llamadas HTTP. Entonces, cuando interactúo con mi aplicación y hago clic en agregar carrito, hago clic en cerrar sesión, hago clic en iniciar sesión, hago clic en lo que sea, se realizan llamadas HTTP. Con intercept, puedo observar esas solicitudes que ocurren y luego realmente escribir una prueba para ellas. Entonces, lo que voy a hacer aquí con este comando intercept es agregar un alias. Así que hagamos alias y haré, crear carrito. Así es como voy a llamar a mi solicitud. Cuando lo guarde ahora, vuelva a ejecutar mi prueba, verá este bonito alias que ocurre aquí. Entonces, lo que puedo hacer ahora es esperar a que ocurra ese alias. Crear carrito. Lo que hice en esta prueba es que no solo estoy interactuando con la aplicación, sino que también espero que se realice una llamada HTTP, ¿verdad? Podría tener fácilmente un error donde haría clic en algo y no enviaría nada a la base de datos. Bueno, con esto, estoy verificando que realmente envíe algo a la base de datos.

Y cuando hago clic en estos comandos de espera y echo un vistazo en la consola en detalle. Nuevamente, tengo este atributo yield y veo todo lo que está sucediendo con esta solicitud. Así que puedo probar la respuesta. Veo el código de estado. Veo el cuerpo de esa respuesta. E incluso envío una solicitud. Entonces, lo que realmente puedo analizar es si el front-end, cuando un usuario escribe algún tipo de texto, no se modifica de alguna manera indeseada. Así que puedo verificar tanto la solicitud como la respuesta. Así que tal vez lo mostremos en una prueba muy simple. Vamos a hacer, vamos a hacer, oh, hagamos una verificación simple. Asegurémonos de que el código de estado de la respuesta sea igual a 201. ¿De acuerdo? Entonces, lo que hice aquí es simplemente combinar una prueba de UI con una prueba de extremo a extremo. Entonces, estoy usando mi UI para interactuar con mi aplicación y luego estoy probando si la API funciona correctamente. Así que sí, pasemos a la siguiente prueba.

Entonces, en esta, te mostraré un poder diferente de nuestro comando de interceptación. En esta prueba, tengo, en esta prueba quiero asegurarme de que el tablero no tenga listas dentro. Así que tengo una afirmación aquí, obtener lista de datos y no debería existir. Pero lo que está sucediendo aquí es que en realidad tenemos una lista aquí. Entonces, ¿por qué es eso? ¿Qué está pasando? Si echo un vistazo a la línea de tiempo, puedo ver que mi afirmación GET realmente se realiza en el momento en que mis listas o mis datos aún se están cargando. Así que estoy obteniendo un falso positivo aquí, ¿verdad? Y eso no es bueno. Entonces, lo que debo hacer es esperar a que las listas de la API me den una respuesta para asegurarme de que todo esté cargado y luego hacer mi afirmación. Puedo hacer eso con intercept. Así que hagamos intercept get. Y luego, si quiero hacer coincidir las listas y hay diferentes estrategias de cómo puedo hacer coincidir esa solicitud. Dado que tenemos listas y tenemos una cadena de consulta de ID de tablero igual a uno, podemos escribir la expresión regular y hacer coincidir algo como estas listas. Entonces, si contiene la palabra listas y es un método de obtener, entonces vamos a hacer coincidir eso y darle un alias de listas, ¿de acuerdo? Entonces, ahora cuando lo coincido, todavía está pasando como debería no, pero lo que puedo hacer es simplemente ir a CY visit y esperar a que ocurra mi solicitud de lista y cuando ahora guarde mi prueba, verá que está fallando como debería porque dice que no deberíamos tener ninguna lista en nuestra interfaz de usuario, pero tenemos una, así que esto debería fallar. Ahora, por supuesto, podemos usar intercept para eso, pero déjame darte una nota al margen sobre esto. No trates de complicar las cosas. Tal vez mostré un ejemplo que podría funcionar, pero esta es una aplicación simplificada. Cuando abro el tablero, se activan tres solicitudes HTTP y sé exactamente cuál quiero esperar. A veces, cuando quiero escribir una prueba y tengo esta situación en la que obtengo mi elemento demasiado pronto, puedo hacerlo de una manera más simple, ¿verdad? Cuando mi aplicación aún se está cargando, tengo este loading data que está sucediendo aquí. Entonces, en lugar de hacer eso, puedo simplemente hacer CY contains loading data, debería, bueno, en primer lugar, quiero asegurarme de que sea visible y luego quiero asegurarme de que desaparezca. Así que hagamos algo como esto. El elemento contains data no debería ser visible, debería ser visible y luego no debería ser visible. Y luego pasamos a nuestra prueba, para obtener nuestra lista y asegurarnos de que no haya ninguna lista. Así que guardemos eso. Y, oh, bien, no está pasando. ¿Hice algo incorrectamente? Loading data. No lo sé. Bueno, quería mostrarte un ejemplo más simple y probablemente solo complicé las cosas aquí. Lo que quería mostrar es que simplemente puedes tomar un elemento que no debería estar allí. Quiero decir, contiene loading data. Contiene algo un poco extra, pero siento que esto debería pasar. Tal vez hubo un, okay, para ser visible, no ser visible, no sé. Bueno, tal vez esto es demasiado. Tal vez debería asegurarme de que no sea visible, pero siempre que hago una afirmación negativa, quiero asegurarme de hacer primero la afirmación positiva y luego hacer la afirmación negativa. Así que esto es menos óptimo y no estoy seguro de por qué. Oh, okay, ahora lo entiendo. Es, hice la afirmación incorrecta. Debería ser no existir y creo que esto podría funcionar. Debería existir y luego no debería. Hmm, okay. No estoy completamente satisfecho con eso, pero esto funciona. Y pensé que iba a mostrarte algo menos complicado y terminé mostrándote algo más complicado. Así que supongo que simplemente usar el intercept sería mejor en este caso, pero si, supongo que si tienes una carga más larga que seleccionar ese cargador y enfocarte en que aparezca y luego desaparezca haría las cosas más fáciles si tienes como 30 solicitudes que están sucediendo, todas son asíncronas, todas terminan en diferentes momentos y solo quieres esperar a que termine la última para poder continuar y probar tu aplicación porque todo está cargado en ese momento. Así que sí, muy bien. Una cosa más que quería mostrarte. Si quieres combinar tus pruebas de UI con pruebas de API, nuevamente, voy a usar este CY intercept y puedo nuevamente, de manera similar a la solicitud, pasar un objeto. Entonces, ese sería el método de eliminar porque estoy eliminando un tablero aquí y luego la URL. Como mencioné, puedes definir explícitamente la URL que deseas observar. Puedes usar expresiones regulares. Y lo que siento que es el más fácil de todos es usar mini-match. Mini-match es esta especie de sintaxis de comodín. Así que voy a ir a URL API / listas / y luego un asterisco representa lo que viene después de la barra de listas. Entonces, cuando guarde eso, en realidad está haciendo coincidir la URL, solo olvidé darle un alias. Así que hagamos S eliminar lista. Y luego, después de hacer clic en el botón de eliminar, quiero esperar a que ocurra esa eliminación de lista. Así que guardemos y voilà, he hecho coincidir la solicitud, en realidad sucede. Así que estamos bien.

Marcus está diciendo, ¿no es el texto de carga de tarjetas y no carga data, en realidad era este, este es el que quería capturar. Hay otro, también hay carga de tarjetas. Así que este es otro cargador, pero quería capturar este. Y por alguna razón no lo capturó. Fue extraño. Como tal vez no apareció el tiempo suficiente para ser capturado por el comando get pero sí, no sé por qué. ¿Por qué sucedió? Como muchas aplicaciones tienen estos cargadores, a veces tardan mucho tiempo en cargarse, son algo así como que lo cubren todo. Así que realmente no puedes comenzar a interactuar con tu aplicación hasta que el cargador desaparezca o deje de existir. Y esto me llevó a uno de los buenos puntos. Como cuando tienes una afirmación, no ser visible y no existir. Esas son realmente bastante diferentes entre sí. Entonces, no ser visible significa que el elemento realmente está en el DOM, pero está oculto. No puedes verlo pero no existir significa que no hay tal elemento como este. Así que asegúrate de diferenciar entre esas afirmaciones. Muy bien, eso es todo para el intercept. En mi masterclass. En la masterclass completa, muestro en realidad más capacidades de intercept porque no solo se trata de observar las solicitudes que ocurren sino que también puedes simular una respuesta del servidor. Así que en lugar de obtener una respuesta real obtienes una respuesta simulada y puedes probar diferentes casos límite y probar esos casos. Así que es realmente divertido. Muy bien, así que estamos llegando lentamente al final. Solo quiero mostrarte una última cosa, la instalación de complementos. Esto es una de las cosas que es realmente, realmente genial porque Cypress al ser de código abierto y tener capacidades de complementos significa que tienes todo el ecosistema de personas que contribuyen a la herramienta, lo cual es genial. Y en realidad creé mi propio complemento que me gustaría mostrarte. Así que hablamos de, hablamos de testing de API. Así que quiero mostrarte un complemento que creé para testing de API. Se llama Cypress API, no Cypress plug in API. No sé cómo se llama mi complemento. Y se ve algo así. Básicamente es una interfaz de usuario para testing de API. Así que puedes imaginar como Postman y Cypress estando en un mismo mundo. Así que déjame copiar eso. Básicamente, cualquier complemento que tengas en Cypress pasa por estos pasos simples. Tienes la instalación o vas a NPM, instalas Cypress plugin API y el nombre del complemento. Y luego lo agregarías en tus archivos de soporte E2E JS. Déjame hacer eso, necesito abrir una nueva terminal, instalar eso importarlo en E2E, guardar mi prueba. Y básicamente lo que hará esto es agregar un comando CYAPI. Así que el comando API hace exactamente lo mismo que el comando CY request hace. Pero además, cuando haces el CY request, si quieres examinar tu API, necesitas ir, abrir la consola, mirar adentro y examinar. Si cambio este CY request, el CY API. Lo que esto va a hacer es, me dará esta bonita interfaz y puedo examinar mi API así. Así que puedo ver la respuesta, puedo ver los encabezados que se enviaron. Si se establecieron algunas cookies, aparecerían aquí. Veo la URL completa, veo el estado, la duración. Incluso hay el tamaño. Creo que necesito arreglar un poco la interfaz. Pero sí, está el tamaño de la respuesta, que no es algo que esté presente en la solicitud. Así que hice un cálculo dentro de eso que te daría el tamaño. Y puedes colapsar y expandir todo eso, todo lo que está adentro. Y es un complemento agradable para darte una visión general de tu API así. Así que esa es básicamente la descripción general de tu API. Así que sí, construí toda una masterclass en torno a esto. Así que si estás interesado, puedes inscribirte en eso. Y si estás buscando más complementos, básicamente para cada problema en Cypress, hay un complemento. Así que ya mencioné que Cypress y Hover no son una historia de amor exitosa, pero hay una solución que utiliza el protocolo Chrome DevTools. Y dónde está, Cypress. Incluso si quieres usar XBox, está aquí. Y Cypress I-Frame, resolviendo el antiguo problema de los I-Frames con Cypress y Cypress real events. Ese es el que tienes, como eventos del sistema nativos como Hover, Swipes, etc. Hay excelentes complementos, por ejemplo, para envolver tus pruebas. ¿Dónde está eso? Cypress wrap, ¿verdad? Puedes filtrar tus pruebas. Si no quieres ejecutar todas las pruebas, puedes ejecutar solo un subconjunto y sí, hay tantas cosas, tantos complementos diferentes disponibles. Como puedes ver, puedo seguir desplazándome y casi puedo llegar al final. Además, hay muchos, muchos más en el sitio npmjs. Así que ve y échales un vistazo. Todos son muy fáciles de instalar. Puedes seguir adelante y ver el mío. Eso es bastante divertido. Envía un problema si encuentras un problema. Me encantaría arreglarlo y sí, estamos llegando al final. Supongo que no hay más preguntas. No hay nada más que decir. Solo gracias, gracias por venir. Gracias por venir a la masterclass retrasada. No sé si lo sabes, pero hace dos semanas, nació mi hijo y chocó con esta masterclass, así que no pude asistir. Así que muchas gracias por venir ahora y por quedarte, nuestro grupo se volvió un poco más lento pero entiendo que la gente tiene cosas que hacer. Así que sí, oh sí, gracias, gracias por las felicitaciones y espero verte en algún momento en el Twittersphere si eso dura, veremos, o en LinkedIn y si quieres aprender más, básicamente profundizar, aquí está el enlace a la próxima masterclass y si estás interesado en venir, envíame un mensaje DM ya sea en Twitter o en LinkedIn o en Discord, te daré ese descuento porque ya has sido parte de esta masterclass aquí. Así que no tiene sentido que vayas y veas lo mismo y pagues el precio completo, obtendrás un descuento. Así que sí, espero verte, gracias por tenerme y sí, nos vemos pronto. Adiós a todos.