Pruebas de Aplicaciones Web utilizando Cypress

Eso es todo. Que tengas un buen día. Gracias por asistir a este masterclass. Amo a Cypress y amo dar este masterclass. Y si eres un usuario realmente avanzado de Cypress, creo que también encontrarás algo beneficioso en este masterclass.

Un poco de organización y reglas. Entonces este masterclass durará 3 horas, ¿de acuerdo? Tomaremos un descanso corto de cinco minutos al comienzo de cada hora. Porque es difícil estar sentado en un lugar durante 3 horas. Y así, porque obviamente estás en tu oficina o en casa o donde estés, puedes tomar un descanso cuando quieras. No puedo controlarte. Así que asegúrate de estar cómodo. Si por alguna razón nos desconectamos, intentaré reconectarme a esta sesión de inmediato para que podamos continuar. Así que a menos que haya algunos problemas realmente graves, espero que la sesión continúe y termine.

Estaré pendiente del chat de Zoom y del chat de Discord. Entonces, uno de los beneficios de un masterclass es que siéntete libre de hacer preguntas, ¿de acuerdo? Intentaré responder tantas preguntas como sea posible. Este masterclass será grabado, por lo que recibirás una grabación y recibirás este video más tarde. Entonces, si tienes alguna pregunta, publícala en el chat de Zoom o en Discord, y las responderé en vivo o en el momento adecuado.

De acuerdo, espero que todos tengan este repositorio clonado y listo para usar. Entonces, si no lo has hecho, clona este repositorio para tenerlo localmente. Necesitarás node, así que asumo que lo tienes instalado. Y lo primero que debes hacer es asegurarte de ejecutar npm install. Puede llevar unos 5 minutos si estás comenzando desde cero, porque instalará las dependencias y cypress y todo. Entonces este repositorio tiene todo, ¿de acuerdo? Tiene la aplicación. Realizaremos testing. Tiene los archivos de especificación ya. Y tiene las diapositivas.

Entonces voy a comenzar a compartir las diapositivas. Todas las diapositivas son solo archivos de markdown. Y estoy usando este enlace get-page para mostrar el markdown. Es bueno que todavía sea enero, porque tendré que mover las diapositivas a otro lugar el próximo mes. De acuerdo. Soy Gleb Bakhmutov. Solía ser VP de Ingeniería. Ahora solo soy un ingeniero, porque no quiero hacer todas las reuniones y como hojas de ruta, y así sucesivamente. Así que ahora soy tan afortunado, puedo simplemente programar y hacer masterclass y escribir publicaciones de blog y hacer cosas que encuentro interesantes. Siempre puedes escribirme un correo electrónico después del masterclass o durante. Soy Gleb en Cyprus. También siempre puedes contactarme en Twitter. Intento ser, ya sabes, reactivo y siempre responder a quien me escriba. Tengo muchas publicaciones de blog en el blog de Cyprus y en mi blog personal. Encontrarás muchas explicaciones detalladas. Y también hago pequeños videos de Cyprus en YouTube. He estado usando Cyprus durante casi cinco años porque trabajé en Cyprus durante cuatro años y lo usé durante un año antes así que estoy realmente feliz con Cyprus. Entonces cubriremos muchas cosas. Quiero decir, según el tiempo permita. Publicaré el enlace al repositorio en todos los canales. Cubriremos muchas cosas. Cubriremos la aplicación. Es una aplicación simple de tareas y VC así que no tendremos que pasar mucho tiempo en ella. Cubriremos muertes básicas, esa página interactiva. Veremos cómo podemos seleccionar elementos usando el selector playground y el nuevo estudio y cómo controlaría la aplicación antes de la prueba para que todos comencemos la aplicación en un estado conocido. Y luego veremos las llamadas de red y cómo podemos espiarlas, detenerlas con data sobre imagen data. Probablemente no llegue a esta sección. Tal vez hable sobre integración continua. Tal vez mencione algo sobre la capacidad de reintentar y la depuración mientras cubrimos la sección anterior, pero este repositorio tiene todo este contenido. Entonces, si quieres ver qué hacen las características, ¿verdad, o cómo hacer complementos, entonces cómo configurar la cobertura de código, el material está ahí, pero simplemente no tendremos tiempo para cubrirlo porque este masterclass puede ser largo. No vamos a almorzar, pero tomaremos descansos cortos. Por lo general, este masterclass lo hacemos físicamente, ¿verdad? Y la gente habla y puede ayudar porque es un masterclass virtual. Es más difícil, ¿verdad? Pero simplemente usa los chats con tus opiniones y preguntas.

Descubrí que un buen masterclass y aprovechar al máximo depende de tres pasos. Primero pasaré por las diapositivas, explicaré el tema, y luego mostraré cómo hacer una prueba específica, ¿de acuerdo? Lo escribiré y mostraré qué sucede dentro de Cypress y así sucesivamente. Y luego, dentro de cada archivo de especificación de integración, habrá ejercicios, ¿de acuerdo? Como escribir más pruebas una por una. Y ambas cosas te animo a hacerlas tú mismo y las haré más tarde, ¿de acuerdo? Y mostraré la solución, pero lo mejor para el masterclass es participar activamente. Así que realmente te animo a trabajar en tu máquina, durante este masterclass, ¿de acuerdo? Y si te quedas atascado, nuevamente, haz una pregunta en Discord o en zoom, ¿de acuerdo? Y trataré de ayudar. Pero lo mejor es escuchar lo que explico y luego codificar juntos mientras codifico e intentar pasar a los siguientes ejercicios. De acuerdo, ya dije que necesitarás clonar el repositorio y hacer NPM install. ¿Larick puede ayudar a las personas porque algunas personas no ven el canal de Discord. De acuerdo. Supongo que duplicaremos. Excelente. Entonces esto es lo que tenemos en nuestro repositorio. Entonces, si miras todos los archivos, ¿de acuerdo?, tenemos muchas cosas. La aplicación está dentro de to do MVC, ¿de acuerdo? Entonces está en la subcarpeta y esto tiene sus propios paquetes. Entonces, si no PM install, en realidad instala las dependencias allí también. Los detalles no son tan importantes sobre la aplicación. Luego tenemos la carpeta de integración de Cypress. Ahí es donde estarán todos los archivos de prueba, ¿de acuerdo? Y así para cada sección, ¿de acuerdo todos están numerados, uno después de otro, mientras que las subcarpetas. Entonces, si voy y miro, digamos, la integración de Cypress verás que el primer archivo de especificación que se abrirá está aquí. Y luego para la siguiente sección es el dos y así sucesivamente. Entonces, cada sección simplemente trabajaremos en una carpeta diferente y todo es independiente. Entonces no tienes que terminar lo que hiciste en el capítulo anterior para pasar al siguiente. Todos son independientes. Y mientras estamos testing la aplicación, la aplicación simplemente se ejecutará. Así que la iniciaremos y simplemente se mantendrá. De acuerdo, ¿todos están listos? De acuerdo, asumo que todos están listos. Entonces, desde la terminal, escribe uno dentro del repositorio. Puedes ejecutar NPM start. Y deberías ver esto, ¿de acuerdo? Si instalas todo, si no tienes problemas, eso es lo que verás, ¿de acuerdo? Literalmente acaba de iniciar la aplicación y debería estar funcionando en localhost 3000.

De acuerdo, así que vamos a ejecutar esa aplicación en segundo plano todo el tiempo. De acuerdo, es un TodoMVC porque es la aplicación más difícil, casi la aplicación más difícil que sé cómo codificar. Si tienes vista, puedes ver la interacción de vista. No importa cómo se implemente la aplicación. Podemos ejecutar el CSS prácticamente contra cualquier implementación porque a Cypress no le importan los detalles de la permutación, ¿verdad? Hace el navegador, hace la interfaz de usuario, ¿verdad? Pero al usuario no le importa cómo se implementa. Entonces, ¿por qué debería importarle a Cypress?

De acuerdo, abramos las DevTools. Entonces, lo primero que queremos saber de inmediato es qué sucede cuando trabajamos con la implementación, como esta aplicación, ¿verdad? Entonces, lo que suelo tratar de observar son las llamadas de red que ocurren cuando se carga la aplicación, ¿verdad? Así que puedo recargar y ver lo que obtenemos en el documento, obtenemos un montón de scripts, ¿verdad? Y al final, nuestra aplicación realiza una llamada AJAX, así que podemos inspeccionarla. Entonces, nuestra aplicación está haciendo un GET a todos, ¿verdad? Y obtiene una lista vacía, porque no hay todos. Entonces, dentro de una página, tenemos algo así como una marca estándar, ¿verdad? Tenemos clases para la sección principal. Tenemos un encabezado, ahí es donde probablemente tendremos una caja de entrada y cuando simplemente jugamos todo en una lista desordenada. Y así, para cada todo, simplemente lo mostraremos en la pantalla. Así es nuestro marcado. Puedes echar un vistazo a todo.mvc.app.js, tiene una vista de almacenamiento, pero son detalles de implementación. No me importa realmente. Pero tengo una pregunta para ti, ¿verdad? Mi audiencia. ¿Qué sucede cuando agregas un nuevo elemento de todo? Puedes hacerlo tú mismo. Escribe, ya sabes, el primer todo. De acuerdo, cuando presionamos Enter, puedes ver que hay otra llamada que la aplicación está haciendo, y es un POST, ¿verdad? Entonces envía algo al punto final de todos, ¿verdad? El servidor responde con 201, lo que significa que se creó un nuevo elemento. ¿Y qué envía la aplicación? Bueno, envía el todo. Y observa que la aplicación envía el título, ¿verdad? Que es el primer todo completado falso. Por defecto, cada elemento está incompleto y el frontend también envía el ID. Entonces, la aplicación está creando el ID para la aplicación, para el elemento de todo, y lo envía, ¿verdad? Así que ni siquiera es del lado del servidor, es solo del lado del cliente. Y si enviamos el segundo todo, ¿verdad?, puedo ver otra llamada, ok, otro ID, otro elemento. ¿Y qué sucede cuando recargamos? Ok, podemos ver que los elementos volvieron. Podemos ver que esta llamada original para obtener todos, ¿verdad?, obtiene los elementos. Entonces, la aplicación, cuando se inicia, obtiene los elementos. Ok, así es como funciona. Así que llega al servidor mediante llamadas de Ajax. Ahora aquí hay otra pregunta, pero debes buscar localmente. Quieres averiguar dónde se almacenaron los elementos. Para esto, cambiaré a mi editor de código. Ok, puedes usar cualquier editor de código, ¿verdad? Pero últimamente amo a VS Code. Es tan simple. Kareem, no, la presentación no es privada. Entonces, si vas al código, ¿de acuerdo?, puedes seguir si te pierdes o si quieres pasar más tiempo, puedes tomar este enlace y hacer clic en cualquiera de los enlaces. Ahora mismo estoy en la introducción. Ok, busquemos dónde la aplicación guarda los datos. Ok, así que lo envía, lo almacena y luego cuando recargamos, podemos ver los datos nuevamente. Así que tiene que almacenarse en algún lugar. Ok, si tienes problemas para ejecutar la aplicación, asegúrate de tener la versión correcta de Node, al menos 12, ¿de acuerdo?, y que puedes ejecutar npm start. Una cosa, podría ser porque esto está usando, ¿dónde está nuestro inicio, si tienes problemas, tal vez ve directamente a la subcarpeta todo.nvc y haz npm start allí. Asegúrate de hacer npm install primero. Entonces, si en mi editor de texto, si miro a mi alrededor, ¿de acuerdo?, y voy a todo.nvc, puedo ver este archivo data.json. Ok, y sí, Martin, tienes razón. No lo estoy ignorando porque generalmente comienza con un archivo simple y vacío. Ok, aquí es donde mi servidor está almacenando los datos. Verifiquemos. ¿Es data.json? Ok, sí, ahí es donde está. Sí, sí, Lindsey, intenta instalar las dependencias nuevamente e intenta iniciar en uno. Ok, supongo que duplicaremos. Excelente. Entonces esto es lo que tenemos en nuestro repositorio. Entonces, si miras todos los archivos, ¿de acuerdo?, tenemos muchas cosas. La aplicación está dentro de to do MVC, ¿de acuerdo? Entonces está en la subcarpeta y esto tiene sus propios paquetes. Entonces, si no PM install, en realidad instala las dependencias allí también. Los detalles no son tan importantes sobre la aplicación. Luego tenemos la carpeta de integración de Cypress. Ahí es donde estarán todos los archivos de prueba, ¿de acuerdo? Y así para cada sección, ¿de acuerdo? todos están numerados, uno después de otro, mientras que las subcarpetas. Entonces, si voy y miro, digamos, la integración de Cypress verás que el primer archivo de especificación que se abrirá está aquí. Y luego para la siguiente sección es el dos y así sucesivamente. Entonces, cada sección simplemente trabajaremos en una carpeta diferente y todo es independiente. Entonces no tienes que terminar lo que hiciste en el capítulo anterior para pasar al siguiente. Todos son independientes. Y mientras estamos probando la aplicación, la aplicación simplemente se ejecutará. Así que la iniciaremos y simplemente se mantendrá. De acuerdo, ¿todos están listos? De acuerdo, asumo que todos están listos. Entonces, desde la terminal, escribe uno dentro del repositorio. Puedes ejecutar NPM start. Y deberías ver esto, ¿de acuerdo? Si instalas todo, si no tienes problemas, eso es lo que verás, ¿de acuerdo? Literalmente acaba de iniciar la aplicación y debería estar funcionando en localhost 3000.

De acuerdo, el archivo cypress.json, permíteme cambiar a esto. Permíteme abrir mi editor de código para que podamos ver todo. Esta es la carpeta. cypress.json es un archivo donde tendré todas las configuraciones. Por ejemplo, si quiero establecer la URL base, ¿verdad?, como qué URL están ejecutando mis pruebas o mi aplicación, puedo hacerlo. Puedo usar Viewport, ¿verdad?, y así sucesivamente. Estas son todas las configuraciones.

Pero la integración es lo segundo más importante. Ahí es donde estarán tus archivos de prueba. Entonces, cuando Cypress se inicia por primera vez, generamos esas carpetas, la integración. Y puedes tener subcarpetas allí y así sucesivamente. Estas son todas las pruebas que creamos como ejemplo. Así que podemos abrir cualquiera de esos archivos que creó y ver cómo se ven las pruebas de Cypress. Llegaremos a esto en un segundo.

La carpeta de fixtures, aquí es donde puedes poner archivos que deseas usar como datos durante tus pruebas. Así que no tienes que volver a codificarlos. Luego está el comando Cypher fixture que puede cargar esos archivos. Support es un lugar para utilidades comunes, ¿verdad? Si quieres ejecutar, por ejemplo, algo antes de cada archivo de especificación o antes de cada prueba, quieres ponerlo aquí. Son cosas comunes que quieres que tus pruebas tengan. También puedes crear comandos personalizados, por ejemplo, para iniciar sesión para que puedas reutilizarlos y ponerlos en support. Y finalmente, el complemento es algo que te permite controlar cómo se ejecuta Cypress, pero se ejecuta en Node antes de que se inicie el navegador. Por ejemplo, podrás consultar una base de datos, ¿verdad? O cambiar la configuración antes de que se ejecute Cypress utilizando el archivo de complementos. De acuerdo. Lo que sugiero es que cuando ejecutes Cypress por primera vez, mires esos ejemplos que acabamos de generar. Bien, así que dentro de la integración, creamos una carpeta completa que tiene un montón de ejemplos, cómo escribir en un elemento, cómo hacer afirmaciones. Cuando Cypress se inicia, muestra esos archivos aquí mismo, ¿verdad? Permíteme cambiar aquí. Así que, por ejemplo, si quiero ver cómo escribe y hace clic Cypress, puedes hacer clic en el archivo de ejemplo, ¿verdad? Mi máquina es más lenta de lo habitual, creo que por Zoom. Bien, ahora muestra cómo escribe, por ejemplo. Establecí el viewport en 200 píxeles en Cypress JSON. Por eso se ve un poco raro, permíteme cambiarlo. Cada vez que cambias algo en Cypress JSON, cierra el navegador porque los cambios pueden ser bastante grandes, ¿verdad? Esto es más típico. Lo que ves a la derecha es el sitio web. Así que cargaremos nuestro sitio web de ejemplo para que podamos mostrar cómo la prueba puede escribir, enfocar, hacer clic, ¿verdad? Realizar todos los comandos y acciones como un usuario real puede hacerlo. Perfecto, así que usando ambos ejemplos que generamos. Puedes tener una idea de qué es Cypress y qué puede hacer, ¿de acuerdo? Estos son ejemplos de diferentes afirmaciones que puede hacer. Lo genial es que puedes abrir cada prueba y ver qué hace, ¿verdad? Como todos los comandos con RAM. Por ejemplo, en mis afirmaciones, ¿verdad? El nombre de una prueba está aquí mismo. Lo mismo. Y luego lo que ves aquí corresponde a lo que sucede, lo que está escrito aquí. Así que puedes ver antes de cada visita de página y luego obtenemos algo con la tabla de afirmación de clase y puedes ver ambos comandos uno por uno. Así que puedes ver cómo lo que escribes, cómo se ejecuta aquí. De acuerdo. Si haces muchas industrializaciones, probablemente no quieras generar esa carpeta una y otra vez, así que tengo un pequeño paquete que te permite omitirlo y simplemente crear Cypress JSON y una carpeta de integración vacía, y así sucesivamente. Así que lo que generamos aquí mismo, todos esos ejemplos, ten en cuenta que se ejecutan en el ejemplo Cypress.AR. Así que llamamos a este proyecto Kitchen Sync. Tiene su propio repositorio y puedes ir a ese enlace de ejemplo tú mismo cuando quieras. Así que si lo generas y ves algo y luego quieres mostrárselo a otra persona, por ejemplo, las mismas afirmaciones, la página está aquí mismo. Así que puedes ver ambos pasos y buscarlos y ver, ¿cómo obtuve la tabla con clase? Oh, de acuerdo. Así es como obtuve la tabla y luego encontré algo y hice una afirmación, pero tiene una clase de éxito. De acuerdo, esto es lo que publicamos y mantenemos en todo momento. De acuerdo.

Entonces, ¿por qué no programamos juntos? De acuerdo, así que tenemos este nuevo proyecto, ¿verdad?, donde no hay nada más. De acuerdo, incluso cerraré el navegador. De acuerdo, en mi editor de texto, simplemente eliminaré esta carpeta, ejemplos, para que solo tenga integración de Cypress y puedo crear un nuevo archivo, spec.js, así que es un archivo JavaScript. Esa será nuestra prueba. De acuerdo. Y esta es la prueba más simple que podemos hacer. Podemos, permíteme pegarla aquí, de acuerdo. ¿Qué hace? Bueno, el nombre de la prueba se llama carga y Cypress utiliza la sintaxis de mocha. Así que cada prueba es una llamada a la función it. Estamos describiendo la página, así que decimos app, se carga. Y luego la función de devolución de llamada tiene todos nuestros comandos. Nuestra prueba será muy simple. Recuerda que tenemos un TodoMVC ejecutándose en localhost 3000. Así que todo lo que queremos hacer es simplemente visitar la página. Si quieres escribir esto en TypeScript, sí, puedes usar TypeScript. De acuerdo, permíteme cambiar. Observa que Cypress está vigilando la carpeta de integración. Así que realmente nota la extensión diferente. Observa que, dado que esto es, permíteme ampliarlo un poco. Observa las pequeñas líneas chillonas. Porque Cypress, estos son objetos globales. Entonces nuestro editor de texto no sabe de ellos, como de dónde vienen. Así que si realmente quieres solucionarlos, puedes decir que las referencias de Cypress son tipos de Cypress. Entonces, esta línea especial que publicaré aquí, ¿verdad? Es algo que le dice a mi editor de código dónde cargar las definiciones de tipo globales para la función it y site. Y buscará dentro de la carpeta node_modules, encontrará el módulo Cypress, que instalamos con npm install, y las cargará y ahora las entenderá. Ahora, mira, si me detengo sobre Cypress, muestra nuestra documentación. De acuerdo. Y muestra la documentación para cada comando, por ejemplo. Así que site visit, ¿verdad? Puedo ver cómo usarlo y así sucesivamente. De acuerdo, vamos a ejecutarlo. Pero una cosa que notarás, Cypress viene con un navegador electron integrado. De acuerdo, este es un navegador que es muy similar a Chrome. Es realmente Chrome, pero como una o dos versiones anteriores a la última versión del navegador Chrome. Puedo cambiar este navegador y encuentra automáticamente los navegadores que están instalados en mi máquina. Así que tengo un montón de versiones de Chrome, un montón de versiones de Firefox, Edge, ¿verdad? Todos los navegadores que Cypress puede controlar y usar. Así que permíteme intentar ejecutar la prueba en Chrome Canary. Y luego hago clic en el archivo de especificación. Ah, pero no instalé TypeScript. Para responder a tu pregunta, también tengo que hacer npm install TypeScript si quiero ejecutar TypeScript, lo cual olvidé hacer.

Entonces, lo más simple es cambiar esto de nuevo a JavaScript. Ahora, Eric, no te decepciones porque cuando usas estos tipos de referencia, esto funciona igual de bien. Observa que aún entiende todo. Bien, así que puedo usar mi IntelliSense simplemente teniendo esto. De acuerdo, déjame ejecutarlo. Bien, esto es nuestra prueba. De acuerdo, nuevamente, lo que ves a la derecha es el sitio web en ejecución en un Iframe. A la izquierda, ves lo que llamamos registro de comandos. Muestra todos los comandos, ¿verdad? Ves una cantidad de pruebas exitosas y fallidas, cuánto tiempo tomó. Sabes, puedo volver a ejecutar la prueba, ¿de acuerdo? También puedo ejecutar la prueba enfocándome en el registro de comandos y simplemente presionando R en mi teclado, ¿verdad? Luego se vuelve a ejecutar. De acuerdo, un par de preguntas. Para nuestros métodos personalizados y archivos de soporte, busca nuestra documentación. Voy a describir la documentación en un segundo, pero la otra cosa es, ¿cómo describo, por ejemplo, diferentes navegadores? ¿Qué pasa si mi navegación está en una ubicación no estándar? Puedes controlar la ruta a un navegador desde el archivo de complementos. ¿Puedo decirle a VS Code que estoy usando Cypress en esta línea? Si usas TypeScript, sí, si no, encuentro que esta es la forma más sencilla de hacerlo. Pero una cosa que quiero señalar, otro secreto, así que estamos en un proyecto de JavaScript. No instalamos nada. De acuerdo. Y aún entiende el comando. Pero si, por ejemplo, digamos que escribimos mal un comando, ¿verdad? Entonces, si ejecutamos esto, obviamente falla. Pero realmente queremos saber sobre esto. Ups. De acuerdo, observa que esto no es una función. Entonces estamos escribiendo nuestros archivos de especificación dentro de la carpeta de integración de Cypress. De acuerdo. Si tienes un error de compilación de Webpack, mira el error de compilación de Webpack y ve qué dice. Pero aquí hay un truco. Debido a los tipos de referencia, entiende el global, pero esto no está ahí. Agrega otro comentario, TS Chuck. Ahora todavía estamos usando JavaScript, ¿verdad? Pero nuestro editor de código resaltará todo lo que no tenga sentido. Observa cómo dice que la propiedad business no existe en el tipo Cy. ¿Quisiste decir visit? Porque sabe dónde se encuentra el método visit muy cerca. Ahora lo arreglaré, y ahora todo está bien. Otra cosa que notarás es que cada vez que edito y guardo un archivo, Cypress lo vuelve a ejecutar, ¿de acuerdo? Lo cual es muy conveniente. Por lo general, mantengo mi editor en un lado de la pantalla, y luego, ya sabes, codifico en otro, y sigo ejecutando la prueba, ¿de acuerdo? A medida que lo actualizo, ¿de acuerdo? Si tu seguimiento de archivos no funciona, mira nuestros problemas, tal vez haya algo relacionado con tu sistema operativo, o tal vez con tu editor, o tal vez tu software antivirus evita el seguimiento de archivos. Hablé de esto. Entonces, esta prueba, ¿verdad? Parece muy simple. Solo estamos visitando una URL, ¿de acuerdo? Ahora, aquí es donde es poderoso. Imagina que, por ejemplo, intento acceder a una URL incorrecta. Tal vez mi servidor está cerrado, tal vez no se está ejecutando, ¿verdad? Si tu prueba se está ejecutando sin cabeza, asegúrate de usar el comando open de Cypress y no run de Cypress. Hablaré de run de Cypress en un segundo. Mi sitio web no responde. Mi servidor está caído. Todo está roto, ¿verdad? Observa que Cypress te da un error significativo. Dice falla, intenta cargar y luego esto. Me dice el error de red, conexión rechazada. Me dice cuáles son las posibles explicaciones de por qué esto está mal. Incluso me dice qué comando falló. Si hago clic en abrir una ID, va directamente a ese lugar en mi archivo. Incluso la visita simple se puede considerar una buena prueba de extremo a extremo porque si el servidor no responde, si responde con un código diferente a 200, si es 500 o 404, este comando fallará. Si tu página no se carga y no dispara el evento de carga de página, este comando fallará. Si tu sitio web es lento, ¿de acuerdo?, y por defecto, visit espera, olvidé, creo, 60 segundos para que la página se cargue correctamente, puedes controlarlo. Puedes cambiarlo en tu archivo Cypress JSON o incluso en tus parámetros de visita. Creo que es timeout. Oh, sí. Creo que timeout es el que puedes cambiar en línea. O hay una opción dedicada en Cypress JSON que puedes configurar. ¿De acuerdo? Pero incluso una simple visita ya nos está diciendo algo. El servidor no se bloquea, ¿verdad? Esto es lo que está sucediendo. Aquí hay algo más que quiero mostrar. Como mencioné, cambiar el navegador, explico cómo configurar IntelliSense. Lo bueno de esto es que una vez que comienzas a escribir más afirmaciones, ¿verdad? Digamos que quiero confirmar que hay tres afirmaciones. Puedo usar Sy Get y decir, to do. Encuéntrame todos los elementos con la clase to do. ¿De acuerdo? Ahora encontró tres elementos. Muestra tres elementos coincidentes. Y observa que Get se ejecutará solo después de que Physit se complete correctamente. De acuerdo? Entonces, digamos que quieres confirmar que hay tres tareas pendientes. Dices, déjame tal vez hacer un poco más pequeña la voz. Es difícil ver qué está pasando. Así que encontraste los elementos. Y cuando dices, Should have length three. Entonces todo lo que encuentres debe tener una longitud de tres. ¿De acuerdo? Esto se llama un comando y Should es una afirmación. Y como dije, tenemos inteligencia para cada comando, pero también tenemos inteligencia para las afirmaciones. Y Cypress viene con afirmaciones chai, afirmaciones chai.jQuery y afirmaciones chai.xenon, como todo en uno. No tienes que instalar nada. Como no instalé nada. Y observa que aquí usamos la afirmación de longitud, should have length three, y observa cuando usas IntelliSense, en realidad te muestra la afirmación correcta. Quiero decir, la documentación correcta para esa afirmación. ¿Verdad? Y los ejemplos correctos, ¿verdad? Should have length three y así sucesivamente. Si, por ejemplo, dices should have class y dices to do, cada elemento encontrado tiene esa clase. Si te pones encima, te muestra nuevamente, documentación para esa afirmación en particular. ¿Verdad? Y los ejemplos correctos, ¿verdad? Should have length three y así sucesivamente. Si, por ejemplo, dices should have class y dices to do, cada elemento encontrado tiene esa clase. Si te pones encima, te muestra nuevamente, documentación para esa afirmación en particular. ¿Verdad? TS check, explico, en realidad usará tipos para resaltar. Y ahora dónde encontrar la documentación. Si nunca has usado Cypress, o si acabas de comenzar, o si lo has estado usando durante años, tu mejor opción siempre, cuando tengas preguntas, es ir a docs.cypress.io. Ahí es donde se encuentra toda nuestra documentación, o la mayoría. Entonces, lo que podría resultarte interesante es cómo funciona Cypress. Como, ¿cuáles son las principales características y conceptos básicos? Como, ¿qué es especial acerca de Cypress? Todo está descrito aquí.

Como ingenieros, no trabajamos en Cypress y luego le decimos a otra persona que escriba la documentación. Cada solicitud de extracción a Cypress tiene solicitudes de extracción correspondientes a la documentación. Literalmente, pasamos como el 25% de nuestro tiempo actualizando los documentos. La mayoría de las cosas que he hecho últimamente han sido solicitudes de extracción de documentación. Pasamos mucho tiempo documentando cosas.

Concepto principal, API de comandos. ¿Entonces, dónde encuentras la documentación de los comandos? ¿Vas a la sección de API, verdad? Y verás que cada comando que he estado usando está aquí. Así que usamos, digamos, visit, ¿de acuerdo? Así es como se documenta cada comando. Mostramos cómo usarlo, como su sintaxis, explicación de cada parámetro, ¿de acuerdo? De lo contrario, el tiempo de espera para registrar el sitio. Mostramos ejemplos, ejemplos con opciones, ¿verdad? Como todos los casos de uso comunes. Discutimos cómo, qué hace cada comando en un caso particular. Por ejemplo, si tu servidor redirige, seguimos las redirecciones cuando hacemos visit. ¿Qué pasa con los protocolos, verdad? Incluso si no tienes un servidor, puedes usar una página. Gracias por las amables palabras, ¿verdad? Te decimos las reglas, ¿verdad? Dije que tu servidor tiene que responder con algo de contenido HTML, pero tiene que ser 200 y eventualmente. Y la página tiene que enviar mucho, ¿verdad? Luego tenemos ejemplos. En la parte inferior, generalmente tenemos un historial, ¿verdad? ¿Cómo cambió este comando si cambias en diferentes versiones? Y una cosa más importante, en la parte inferior de cada comando se encuentran los comandos relacionados. Por ejemplo, si acabas de escribir, comenzaste a usar visit, y luego tienes una pregunta, bueno, ¿qué pasa con visitar otra página, pero retrocediendo en el historial, verdad? Como ir a la página principal, ir a la página Acerca de y luego hacer clic en el botón de retroceso. ¿Cómo funciona eso? Por lo general, ponemos enlaces como ese en Ver también. Entonces, si aprendes visit, ve y lee Ver también. Mira nuestros ejemplos. ¿De acuerdo? Hay muchos comandos. Un buen truco que puedes recordar es que todo lo que hacemos tiene un enlace corto. Por ejemplo, si quieres saber cómo funciona visit, no tienes que ir a docs.cypress.io, sino a cypress.io y luego visit. Esto te redirigirá automáticamente en todo momento. ¿De acuerdo? Entonces, si quieres saber cómo funciona el comando get, tienes que ir a get. Así es como nos aseguramos de que los enlaces no se rompan si movemos la documentación. Como un clip, todos van directamente a esta documentación. ¿De acuerdo? Y cuando editamos algo, si pasas el cursor por encima, en realidad te dice si quieres ir a on cypress.io.visit. Así es como nos aseguramos de que los enlaces no se rompan. Si tienes diferentes configuraciones para el entorno, mira la sección sobre entornos en este repositorio. Otra cosa, si solo quieres saber y aprender, tenemos ejemplos, tenemos recetas más extensas que muestran cosas avanzadas, ¿verdad? Tenemos videos tutoriales y listas de reproducción y ejemplos de construcción de cosas. También sugiero que revises esta página, los cursos, ¿verdad? Estos son cursos externos donde las personas han desarrollado. La mayoría de ellos son cursos en video que muestran cómo usar Cypress, ¿verdad? Y muchos de ellos son, bueno, no muchos, tal vez una cuarta parte. Es gratis. No tienes que pagar para aprender esto, ¿verdad? Puedes encontrar y comenzar viendo cursos gratuitos y luego ver qué más hay. ¿De acuerdo, un par de preguntas? ¿Dónde encontrar la lista de cada afirmación, verdad? Entonces, una cosa que siempre debes hacer al buscar algo es usar la búsqueda, ¿verdad? Observa que escribí afirmación y de inmediato fui a la página de afirmaciones donde documentamos las cosas. Esto no es exhaustivo porque la forma en que funciona Chai, puedes combinar esas cosas, ¿verdad? Y tener afirmaciones, como eso, por ejemplo, combinar varias palabras clave de modificador, ¿verdad? La mayoría de las veces pienso en mi cabeza, ¿qué estoy tratando de decir? Debería tener longitud, debería tener clase, y esa sería la afirmación. Y a medida que escribes, si tienes IntelliSense, te dirá qué está sucediendo. ¿Puede Cypress controlar múltiples navegadores al mismo tiempo? No. Entonces, ¿puede Cypress controlar múltiples navegadores? Tal vez, ¿es eso correcto? Por lo general, puedes encontrar preguntas o respuestas a preguntas como esa escribiéndolas en nuestra búsqueda. Hablé de esto. Una cosa importante, preguntas frecuentes, y mantenemos esto actualizado, preguntas que son demasiado pequeñas para una receta, pero más grandes o no relacionadas con la documentación, ¿verdad? Por ejemplo, ¿cómo verificas el texto de un elemento? Por lo general, dices algo como esto. Pero ¿qué pasa si tiene un espacio sin separación, como todos esos pequeños detalles adicionales, verdad, están aquí? Pero las afirmaciones, intento afirmaciones. Personalmente, no me importan solo las afirmaciones, ¿verdad? Como ChaijQuery ya está funcionando, no vamos a cambiar. Algunas personas intentan, por ejemplo, agregar nuestras afirmaciones, solo afirmaciones, encuentro que son duplicados y no tan poderosos, especialmente si miras Synon, ¿verdad, versus solo mux? Synon es mucho más poderoso, así que no vamos a agregar cosas. Otra cosa. Si quieres saber qué ha cambiado, tenemos un registro de cambios, ¿verdad? Entonces, cada versión de Cypress está documentada y puedes ver qué ha cambiado con enlaces a cada PR y así sucesivamente. Si quieres saber en qué estamos trabajando, está en la hoja de ruta. ¿De acuerdo, cosas importantes tienen su propia hoja de ruta? Pregunta, ¿cómo gana dinero Cypress, tenemos, no? ¿Es Cypress gratis? Sí, todo lo que estoy mostrando hoy es absolutamente nuestro ejecutor de pruebas de código abierto con licencia MIT. Ganamos dinero a través del panel de control de Cypress donde las organizaciones, cuando tienen muchas pruebas, quieren grabar videos con los resultados de las pruebas, ejecutarlas en paralelo, tener análisis de pruebas y cosas así. Una integración de GitHub, Bitbucket, Jira, integración de Slack, así es como ganamos dinero, no con la escritura de pruebas. Entonces, mi consejo al final de esta sección es asegúrate de configurar IntelliSense. Como he hecho aquí con esta línea. Si usas TypeScript, si configuras TypeScript, ni siquiera tienes que hacer eso. Pero si estás comenzando con JavaScript, no quieres meterte con nada, asegúrate de agregar esta línea y es hermoso, funciona, te ayudará a usar el comando correcto, ver ejemplos para ese comando. Es difícil desplazarse aquí, ¿sabes? Pero una vez que lo configures, todo estará bien. Bien, esta fue la introducción al nuevo proyecto. Pasemos al siguiente. Escribamos pruebas para nuestra aplicación. De acuerdo, así que voy a cambiar aquí. Bien, veamos primero el comando contiene y la prueba retrieve, ¿de acuerdo? Así que les pregunto a todos. ¿To Do MVC está en ejecución, verdad? Todo está bien, todavía está ahí. Y ahora queremos cerrar Cypress como si lo estuviéramos ejecutando, ¿verdad? No necesitamos eso. Podemos olvidarnos de ese primer proyecto. En su lugar, voy a volver a mi repositorio de pruebas de Cypress, ¿de acuerdo? Así que mi aplicación está en ejecución. Gamels está aquí. Y aquí puedo iniciar Cypress usando este comando npm run site open o puedo hacer npx Cypress open. De acuerdo, ahora volvemos a nuestro repositorio de pruebas de Cypress. Cambiemos para que no tengamos varios navegadores. Quiero abrir esto, básico cero uno. Básicamente, voy a usar este filtro. Así que puedes limitarte rápidamente a una subcarpeta o parte del archivo. De acuerdo, y en mi editor de texto, quiero abrir el mismo archivo. Voy a abrirlo, así que no necesito esto, aquí está Cypress. ¿Dónde está? Cypress integration spec. De acuerdo, tengo esta prueba y espero que puedas abrirlo en tu editor de texto y en Cypress también, ¿de acuerdo? Veamos. ¿Funciona esta prueba? Si hago clic en ella, esto es lo que sucede. De acuerdo, la prueba falla. Esto es muy común.

Está bien. Estamos escribiendo pruebas. Queremos ver que fallen por la razón correcta, ¿verdad? Y queremos arreglarlos o arreglar la aplicación y queremos ver que pasen. Verás muchas pruebas fallidas, te lo garantizo.

Ok, lo primero que puedes notar es que estamos usando el comando contains. Ok, podemos abrir nuestro editor de texto. Escribe contains. ¿Dónde está la documentación para este comando? Bueno, está en on cypressio contains. Ok, contains. Ok, puedes adivinar leyendo la documentación lo que hace el comando contains. En este caso, permíteme abrir la documentación. Esto es lo que hace. Estás tratando de encontrar un selector con un texto específico, ¿verdad? Nuestro selector es el elemento H1, ¿verdad? El elemento de encabezado con el texto to do this app. Ok, ok. ¿Por qué está fallando entonces? Bueno, veamos esto, ¿verdad? Intenta encontrar to do this app. Hmm, pero nuestro H1, ¿verdad? Como esta gran cosa, no dice to do this. Solo dice to do this, ¿verdad? Así que si quieres ver que esto tenga éxito, probablemente queremos arreglar la prueba y usar not to do this app, sino solo to do this. Ah, cerca, ¿verdad? Tal vez sea to do this. Ok, es to do this. Aquí hay algo importante, ¿verdad? Contains pasó. Ve y pasa el cursor sobre el comando, ¿verdad? Observa cuando pasas el cursor sobre el comando, resalta el elemento que se encuentra, ¿verdad? Get encontró el cuadro de entrada. Encontró el pie de página. Ok. Y luego contains encontró esto, ¿verdad? Así que encontró el elemento esperado. Es muy fácil encontrar un elemento incorrecto, ¿verdad? Por ejemplo, si no usas h1, site-contain sigue funcionando, luego solo busca todos los elementos, ¿verdad? Puedes encontrar cualquier cosa, solo por texto. Así que si miramos los to dos, lo encontró. Pero ¿qué pasa si usamos to do, ok? Aún es el correcto. ¿Qué pasa si usamos to do MVC? En realidad, no, es to-do MVC, ¿verdad? Podríamos asumir que encontró algo en la parte superior. Pero observa que encontró este elemento. Entonces, cuando escribas una prueba y pase la primera vez, asegúrate de inspeccionar lo que hace, ¿verdad? ¿Encuentra el elemento correcto? ¿Podría confundirse con algo más? Y si encuentra algo incorrecto, actualiza la cosa, ¿verdad? Tal vez agrega el selector o un mejor selector, ¿verdad? Para asegurarte de que la prueba pase por la razón correcta.

Entonces, hubo una pregunta sobre cómo hacer esto más legible. Tal vez queremos usar algún tipo de sintaxis especial como cucumber y creo que la mayoría de las cosas son exageradas, como verás más adelante en este taller, pero las pruebas ya son bastante legibles. Personalmente, encuentro que la sintaxis adicional de cucumber no agrega mucho, pero en realidad dificulta mucho la escritura de JavaScript. Y agrega sobrecarga a tu configuración. Así que no creo que tenga sentido agregar algo específicamente. Hablaré sobre selectores en un segundo utilizando objetos de página. Llegaremos a eso.

Ok. Entonces escribimos la cosa, ¿verdad? Por cierto, si lo cambiamos, ¿verdad? Diremos algo como esto, ¿verdad? O si, por ejemplo, usamos las etiquetas correctas pero un selector incorrecto. Ok. Entonces, cuando depuramos algo como esto, podemos abrir DevTools, este es un navegador real, ¿verdad? Así que siéntete libre de abrir DevTools y mantenerlos abiertos. Creo que está bien. Vamos a la pestaña de elementos. Y veamos esto. Encontramos el elemento. Ok. Es H1, ¿verdad? Porque vemos que debería ser. También podemos decir, solo encuéntrame el elemento con un atributo de datos igual a app title. Ok. Así que siempre podemos usar DevTools, ¿verdad?, para encontrar cosas. Ok. Algo más.

Ok. Antes de llegar a los selectores, quiero mostrar algo más. Digamos que estoy usando un selector incorrecto. Observa este spinner azul. ¿Verdad? Y observa que la prueba no falla inmediatamente. Esto es muy importante en Cypress, ¿verdad? Cypress no sabe nada sobre tu aplicación y cómo la implementas, no sabe qué tan rápido debería aparecer ese elemento. Tal vez se crea dinámicamente después de un segundo. ¿Quién sabe, verdad? Tal vez la aplicación primero obtiene el título del servidor y luego lo coloca allí y lo actualiza. Cypress tiene estas afirmaciones que son casi como instrucciones de usuario. Oye, cuando se carga la aplicación, entonces debería haber este texto en ese selector. Si estás levantando la mano, ¿puedes hacer preguntas en el chat, verdad? Aquí está la cosa. Cypress asume que cada comando pasará después de algún tiempo de espera, por defecto cuatro segundos, ¿verdad? Como puedes ver, esto toma cuatro segundos antes de fallar. Así que Cypress vuelve a intentar ese comando, literalmente va y busca nuevamente ese selector o esa prueba. Si no, vuelve a intentarlo, si no, vuelve a intentarlo. Entonces, todos los comandos que pueden volver a intentar de manera segura, vuelven a intentarlo automáticamente. Y con el spinner azul, es lo que ves, el comando vuelve a intentarlo, vuelve a intentarlo. Tal vez tu aplicación se actualice. Por defecto, son cuatro segundos, puedes cambiarlo globalmente o por comando. Déjame ver, establecer muy largo, y ahora volverá a intentarlo, volverá a intentarlo, porque nunca sabemos cuándo tu aplicación realmente terminará de actualizar la interfaz de usuario, ¿verdad? Y esto puede suceder por múltiples razones. Entonces, si puedo ir aquí en esta aplicación, ¿verdad? Y ahora mismo es app title. Pero si lo cambio y agrego to, ¿sabes que la prueba acaba de pasar? porque de repente encontró el elemento, ¿verdad? Los comandos con los comandos de consulta, como encontrar-elemento, debería haber cinco, ¿verdad? El comando más la afirmación, vuelven a intentarlo y ese spinner azul y la barra de progreso te muestran cuánto tiempo tarda en funcionar. La otra cosa importante aquí es que estamos usando Cypress Open, ¿verdad? Aquí está la diferencia. Entonces voy a hacer que esta prueba falle. ¿Verdad? Esto falla después de cuatro segundos. Genial. Voy a cerrar Cypress solo por ahora. Ok. Y ahora está ejecutando esta prueba. Entonces, cuando trabajas con Cypress y trabajas en la aplicación, usas Cypress Open. Eso es lo que trae el navegador, donde puedes ver los archivos, todo. También está el comando Cypress Run. Y ahora tengo mi aplicación en ejecución. En lugar de Cypress Open, usaré Cypress Run. Ahora, como tenemos muchos archivos de especificación diferentes, quiero ejecutar solo el que estábamos editando. Diré spec cypress-integrations 01 basic spec. Este es el nombre del archivo que acabamos de ejecutar.

Entonces, esta prueba falla, ¿verdad? Esto es lo que sucede cuando ejecutas Cypress en modo headless. Y esto es lo que harías en un servicio de integración continua, ¿verdad? Dirías Cypress Run. Y luego dice, bien, esta es mi versión. Estos son los archivos que ejecutaré. Y luego pasa por este archivo, ¿verdad? Y solo tiene una interfaz de usuario de terminal no gráfica. ¿De acuerdo? Pero esto falla, como sabemos que debería hacerlo, ¿verdad? Y nos muestra el mensaje de error. No se pudo encontrar el contenido de texto dentro de ese selector. ¿De acuerdo? Y luego muestra capturas de pantalla. Así que puedes abrir esas capturas de pantalla. Están en las capturas de pantalla de Cypress y se nombran según el nombre del archivo de especificación y la prueba que falló. Así es como se veía mi aplicación cuando falló. ¿De acuerdo? Así es el modo headless, ¿verdad? Nunca vimos que Cypress se abriera o no. También puedes ejecutar lo mismo en modo headed. Por ejemplo, puedes ejecutarlo en el navegador Firefox o en otro navegador. Al usar headless o headed, puedes cambiar cómo se ejecuta. Ahora mismo estamos ejecutando en modo no interactivo pero en modo headed. No hace ninguna diferencia. Todo es lo mismo. Está bien. Simplemente fallará y terminará. Correcto, y la captura de pantalla se guarda. Mi máquina es más lenta debido a Zoom. Aquí hay otra cosa. Toma capturas de pantalla. Puedes desactivar las capturas de pantalla. Puedes desactivar el video, pero se toma automáticamente. Permíteme mostrar un video muy rápido. Nuevamente, se nombra según el archivo de especificación. De acuerdo. Así que en tu CI, en todos los sistemas operativos, no tienes que instalar nada, ¿verdad? Funciona directamente. Toma un video de la ejecución de la prueba. Ahora, observa cómo el video es un poco entrecortado. No es tan fluido como podría ser porque mi máquina está ocupada con Zoom y la grabación, ¿verdad? Entonces, cuando veas pequeñas interrupciones en el video o fotogramas perdidos o pausas e interrupciones, eso significa que tu CI no tiene suficiente CPU, ¿de acuerdo? Para ejecutar correctamente Cypress porque tu aplicación puede ser grande, ¿verdad? Puedes estar haciendo muchas cosas. Cypress agrega su propia sobrecarga, ¿verdad? Como todos estos registros de comandos y también estamos capturando con video. Entonces, si ves interrupciones en el video, necesitas una máquina más potente. La velocidad no importa realmente, tanto headless como headed se ejecutarán aproximadamente igual. Cypress no es bueno para el scraping, pero es bueno para ejecutar pruebas. Bien, esto fue Cypress Run, ¿verdad? Grabación. Entonces, ¿cómo seleccionas un elemento? Tenemos nuestra opinión. Tenemos mejores prácticas, ¿verdad? Y haremos un descanso después de que termine esta pequeña sección. De acuerdo, antes de continuar. Entonces, aquí está nuestra opinión, ¿verdad? Y puedes estar de acuerdo o no. Digamos que tenemos un botón y tiene un ID, ¿verdad? Algunas clases y así sucesivamente, ¿verdad? Tenemos un rol y también podemos agregar atributos personalizados y también tenemos la etiqueta en el botón, ¿verdad? Enviar. De acuerdo. Entonces, si decimos, dame un botón, eso es un poco extraño, ¿verdad? Porque puede haber varios botones. Definitivamente no lo recomendamos. Tampoco recomendamos el uso de clases que se utilizan para el estilo, ¿verdad? Como, por ejemplo, botón de bootstrap y botón grande, o tailwind. Todo esto puede cambiar. Entonces probablemente no deberías hacerlo. Es posible que desees usar IDs. Quiero decir, los IDs son bastante estables, pero aún pueden cambiar, ¿verdad? Y pueden entrar en conflicto o algo así. Usar roles, ¿verdad? O usar algo que uses para el formulario. Quiero decir, puedes usarlo, pero ahora se convierte en una decisión subjetiva y depende, ¿verdad? Tal vez te alejes de un formulario y luego tengas que lidiar con eso. Cosas como texto, ¿verdad? Algo que es visible para el usuario. Creo que es mucho mejor porque son obvios, ¿verdad? Si un sitio contiene submit no está ahí, como no encuentra el elemento, solo miras las capturas de pantalla. Es como, oh, espera, lo hemos renombrado a order. Entonces es fácil de solucionar. Y también preferimos mucho el uso de atributos de datos específicos. De acuerdo, como agregar datos, como test ID o datos de la página. De acuerdo. Entonces, digamos, ¿por qué es mejor? Bueno, porque el texto podría estar traducido, ¿verdad? Tu aplicación podría mostrar un texto diferente. Entonces, por ahora, puedes usar contains, pero al usar IDs, puedes hacer esto fácilmente, de acuerdo. Y cualquiera que vea este marcado y diga, de acuerdo, ¿cómo encuentro el botón? Timur, ¿puedes hacer una pregunta en el chat o en Zoom o en Discord, por favor? Cualquiera que vea este marcado dirá, de acuerdo, data-side es para mis necesidades de prueba. Perfecto, no hay dudas. No recomiendo XPath. Tenemos un complemento de XPath, los XPath son difíciles de entender y ver. Así que no lo recomendaría. ¿Qué más? A la biblioteca de pruebas le gustan los roles. Está bien, obtén por etiqueta. Siéntete libre de usarlo. Solo tienes que importarlo y agrega comandos personalizados. Agrega un poco más, pero tú decides. ¿Qué pasa si quieres usar objetos de página? Entonces, digamos aquí. De acuerdo. Digamos aquí, en lugar de acceder a esto directamente, creas un objeto, ¿verdad? Objeto de página, ¿verdad? Y dices selector de título. Y simplemente lo mueves aquí. Y en lugar de acceder, dices objeto de página, selector de título. Funciona exactamente igual. Depende de ti. Si sientes que tienes muchas tareas que necesitan acceder al selector de título, muévelo a otro lugar y reutiliza el código. Es solo JavaScript normal. Puedes crear tu propia abstracción para no codificar el selector directamente, ¿de acuerdo? ¿Qué selector eliges para el elemento de etiqueta con el elemento de la lista, verdad? Llegaremos a eso en un segundo cuando comencemos a escribir esas pruebas. En esta sección, justo antes de tomar un breve descanso de cinco minutos, mostré cómo los comandos se reintentan. No sucede instantáneamente. Simplemente dices, encuentra algo y realiza una afirmación y sigue reintentando si es seguro hacerlo y puedes controlar la afirmación.

Y luego mostré lo que puedes ejecutar Cypress en modo no interactivo o headless en CI utilizando Cypress Run, y toma videos y captura capturas de pantalla. Bien, tomaré un descanso de cinco minutos. Ahora son las 11:10. Continuemos a las 11:15, ¿de acuerdo? En cinco minutos, estira las piernas y comenzaremos a escribir pruebas y veremos cómo podemos seleccionar el elemento para confirmar. Sí, hay varios complementos de Cucumber para Cypress, por lo que podrás ejecutar y escribir pruebas utilizando Cucumber.

De acuerdo, una pregunta rápida. Si usas Datasite, ¿verdad? ¿Quieres eliminarlo en producción? No, no vale la pena. Ambos atributos agregan muy poco, tu página está comprimida y optimizada. Ambas cosas agregan una sobrecarga mínima. Probablemente tengas una sola imagen que sea diez veces más grande que todo eso. Y si eliminas los atributos de Datasite de tu código de producción, no podrás probar el código de la aplicación, ¿verdad? En producción. Así que digo, déjalos. Por cierto, sí, Cynthia, recientemente publicamos una publicación en el blog sobre cómo ejecutar Cypress en M1, ahora es un blog de Cypress si alguien está teniendo problemas. Personalmente, no tengo M1, mi computadora portátil es antigua. Pero parece funcionar bastante bien. Y tengo todos los puertos, así que no cambiaré pronto. Bien, continuemos. Escribimos la primera prueba, ¿verdad? Pero ahora, ejerzamos nuestra aplicación y veamos cómo podemos organizar nuestras pruebas utilizando los hooks de Mocha.

De acuerdo, tenemos TodoMVC. ¿Cuál es la cosa más importante que TodoMVC tiene como aplicación, ¿verdad? Y esto es lo que discutes con tu equipo o decides tú mismo. ¿Lo más importante es poder marcar o completar un elemento? ¿Lo más importante es eliminarlo o agregarlo? Quiero decir, si no puedes agregar un elemento, ninguno de nuestros otros elementos funcionaría. Yo digo, agregar un elemento. Así que comencemos agregando elementos. Trabajaremos en la integración 02 de Cypress. Esa es nuestra sección actual. Así que abriré ese archivo aquí mismo en mi editor de texto. Así que integración 02 de Cypress agregando elementos. Bien, ya tenemos un par de marcadores de posición ahí. No hacemos nada. Y podemos comenzar Cypress y abrirlo en modo interactivo. 02. Ahora mismo, creo que la mayoría de nosotros no hace nada. Así que fallaremos o no haremos nada. De acuerdo, o ajustamos las pruebas de marcador de posición. Sin comandos para emitir. De acuerdo, lo que noto aquí es que esas pruebas probablemente fallarán porque no estamos eliminando ningún elemento. Entonces, antes de ejecutar la prueba, probablemente quieras asegurarte de eliminar todo y que no haya elementos. ¿De acuerdo? Aprenderemos cómo restablecerlo un poco más adelante. Así que escribamos nuestra primera prueba. Es de extremo a extremo, lo que significa que queremos abrir la aplicación, encontrar el campo de entrada, escribir algo, hacer clic en Enter, escribir algo más, hacer clic en Enter y confirmar que hay dos elementos. Lo haré para mostrar cómo funciona. Y te animo a que sigas el proceso. Permíteme cerrar esto para que esté. Esta es la prueba. Para concentrarnos solo en esta prueba en particular, diré solo. Así que este es un modificador para Mocha que dice que solo quiero ejecutar esta prueba. Si lo guardo, notarás cómo solo Cypress ahora tiene esa prueba en particular. ¿De acuerdo? Entonces, ¿qué hago? Bueno, primero lo primero. Ni siquiera tengo mi sitio. Así que tengo que visitar HTTP localhost 3000. Genial. Luego tengo que encontrar este campo de entrada. Así que lo que puedo hacer ahora mismo es abrir mis herramientas de desarrollo y, en elementos, pasar el cursor sobre ese elemento, ¿verdad? Tal vez inspeccionarlo, ver qué tipo de clases tiene, qué atributos de datos. Observa que cuando pasamos el cursor, las propias herramientas de desarrollo me dicen que es un campo de entrada con la clase new to do, ¿verdad? Como justo aquí. Así que puedo decir, cuando obtengo, a veces no se muestra cuando es tan grande. Input, new to do. ¿De acuerdo? ¿Encuentra la cosa correcta? Encuentra la cosa correcta, genial. Ahora que encontré ese campo de entrada, te animo a que escribas junto conmigo, ¿verdad? Para que te hagas una idea. Escribiré como un usuario, ¿verdad? Así que digamos primero to do. Y cuando queremos escribir Enter con la tecla especial Enter, simplemente diremos enter pero entre llaves, ¿de acuerdo? Piensa en esto. Así que encontramos el campo de entrada, escribimos y observa el registro de comandos, ¿verdad?, muestra algo interesante. Así que voy a hacer clic en un comando para pausarlo. Y ahora muestra, en primer lugar, el elemento de entrada por este comando. Entonces, este punto rojo es el elemento central en el que estamos escribiendo. Y también, porque Cypress mira tu aplicación y nota los cambios antes y después del comando, en realidad tiene dos capturas, ¿verdad? Así que observa, justo aquí cuando pasamos el cursor sobre visit, muestra una aplicación no como está en este momento, sino cómo estaba durante el comando de visita. Así que Cypress toma automáticamente capturas de pantalla. Y cuando pasas el cursor, en realidad restaura esas capturas, ¿verdad? Así puedes ver cómo se veía la aplicación en cada paso en particular. Lo llamamos depuración de viaje en el tiempo. Y cuando escribimos, Cypress notó antes y después, se veía diferente, ¿verdad? Así que antes de escribir, no había nada después se agregó un nuevo elemento, ¿de acuerdo? Si quiero seguir escribiendo, es como encadenar. Si aún tienes un elemento, puedes escribir más. Así que segundo to do, enter. Escribió el primero, luego el segundo. Y ahora tenemos tres elementos en total. ¿De acuerdo? La pregunta fue, bueno, tengo esta prueba y luego tengo esta prueba, ¿verdad? ¿Tengo que usar visit? De acuerdo, así que ejecutemos dos pruebas juntas, ¿de acuerdo? Diré solo y solo. Ahora tenemos dos pruebas. Quieres que tus pruebas sean lo más independientes posible entre sí. Si asumes que la prueba anterior debe ejecutarse antes de que esta prueba pueda comenzar, eso crea dependencias, ¿verdad? Entonces se vuelve difícil concentrarse en una sola prueba porque tienes que ejecutar la prueba anterior una vez, ¿verdad? ¿Qué pasa si quieres seguir trabajando solo en la segunda? Bueno, aún tienes que ejecutar ambas. La forma en que aconsejamos es hacer que cada prueba sea independiente. Si quieres hacer algo antes de la prueba, muévelo al hook beforeEach. Entonces, beforeEach es una sintaxis de Mocha que dice que antes de cada prueba, ejecuta esta devolución de llamada. En nuestro caso, queremos visitar la página antes de cada prueba, así que lo moveré aquí y lo eliminaré aquí, ¿de acuerdo? Ahora, cada prueba se ejecutará en esto. Así es como refactorizas un código común en beforeEach. Pero también hay un before, que se ejecuta solo una vez. No soy un gran fanático del before único, ¿verdad? Para mí, siempre es más fácil entender una prueba si hace exactamente lo mismo antes de cada una.

Otra cosa, oh, terminemos esta prueba, ¿de acuerdo? Antes de continuar. Esta prueba agregó un par de elementos. Pero nunca confirmamos que la aplicación realmente funcione, ¿verdad? Nunca confirmamos que haya un par de elementos. Digamos que tienes un elemento. Quieres confirmar que hay un número esperado de elementos. Nuevamente, permíteme abrir las DevTools. Inspeccionar el elemento. Bien. Y luego tengo una opción. Bueno, tengo la clase de elemento de lista todo. De acuerdo, nada especial, pero ¿por qué no? Así que diré, sci get, así que obtén todos los elementos, elementos de lista con la clase todo. Debería tener una longitud. Y ya mostré esto. Debería haber dos elementos. Y voy a eliminar esto. Genial. Y sé que recomendé no usar clases, ¿verdad? Pero es mi consejo, así que puedo romperlo cuando quiera. No, depende de ti elegir una buena selección, ¿verdad? En aplicaciones de demostración, por lo general, no es tan importante. Otra cosa es que, debido a que esta aplicación es parte de TodoMVC, una especie de estándar, trabajamos con lo que nos dan, ¿verdad? Como no volvimos a implementar esta aplicación. Lo bueno es que estas pruebas funcionan si vas a TodoMVC, ¿verdad? La cosa real, casi todas esas implementaciones, puedes ejecutar nuestras pruebas contra esas TodoMVC y las pruebas funcionan. En una situación en la que no controlas los selectores, debes trabajar con lo que se te da, ¿de acuerdo? De acuerdo, ahora nuestra prueba falla porque nunca restablecimos los datos, lo haremos más tarde, ¿de acuerdo? Pero lo más importante aquí es que ahora funciona. Ahora continuemos.

Ahora que tenemos un par de tareas pendientes, queremos marcar un elemento como completado. Entonces, ¿qué hacemos? Bueno, comencemos con esta prueba. Permíteme hacerla un poco más pequeña para que tenga mucho sentido. Puedo hacer lo siguiente. Puedo tomar este código, agregarlo aquí. Bien. Agregarlo aquí. Y nuevamente, ¿por qué ingreso un par de elementos aquí? Si la prueba anterior ya los creó, porque no quiero que una prueba dependa del estado de los datos que quedan de otra prueba. Quiero que cada prueba cree todo lo que necesita para que funcione en su totalidad. De acuerdo. Lo vamos a refactorizar en un segundo. Como la repetición es muy pequeña. De acuerdo. Tenemos dos elementos, ¿verdad? Ahora queremos asegurarnos, y te animo a que escribas junto conmigo, ¿verdad? Ahora queremos encontrar y marcar un elemento como completado. Entonces, ¿qué hacemos aquí? Bueno, encontramos los elementos de la tarea pendiente. Confirmamos que hay dos de ellos. Luego tomaremos el primero. Entonces, primero es un comando que dice que si tienes una lista anterior de elementos DOM, simplemente toma el primero, y tenemos que cambiarlo de alguna manera, ¿verdad? O marcarlo como completado. Veamos cómo funciona. Tenemos un elemento. Si abrimos las DevTools, pero espera, si las DevTools no se abren por alguna razón, tenemos un problema con el protocolo BIO o algo así, ciérralo y ejecútalo nuevamente. Entonces, ¿qué voy a hacer? Digamos, voy a ir a la clase y voy a especificar el componente COM del equipo. Usemos group para esto para que pueda ir al div y ahora puedo ejecutarlo. Mantengamos esto, debería abrir todas mis listas. Permíteme eliminarlo. De acuerdo, encontró dos elementos, tomó el primer elemento, elemento de lista, y luego encontró el elemento. Entonces, la diferencia entre find y get. Get comienza desde arriba, desde todo el documento y luego encuentra todos los elementos que coinciden con el selector. Find comienza con un elemento anterior. No puedes decir solo find porque no hay un elemento principal. Pero si tienes un elemento anterior, en este caso, lo tienes. Cuando devuelve solo un elemento encontrado con el selector. De acuerdo, en nuestro caso, tomamos todo este gran elemento de lista y dentro encontramos un elemento con la clase toggle. De acuerdo. Y diré clic. De acuerdo, encontró el primero, encontró la alternancia y luego hizo clic. Ahora una pequeña cosa es que el elemento ya no es visible. A veces, especialmente las casillas de verificación y las bibliotecas de interfaz de usuario, tienen que ocultar elementos debajo de otro o solo se vuelven visibles al pasar el cursor, ¿verdad? Entonces, es posible que veas estas cosas o si había un elemento y luego se eliminó, ya no será visible, ¿de acuerdo? Agregamos un par de elementos, confirmamos un número, completamos el primer elemento, fue un comando. Ahora tenemos que confirmar que realmente se muestra como completado. Nuevamente, ¿cómo lo hace nuestra aplicación? Si miramos este elemento, podemos ver que la aplicación agrega esta clase, completado. Entonces, después de hacer clic, queremos confirmar que este elemento ahora tiene la clase completado. Voy a copiar y pegar esto, por lo que vamos a encontrar nuestros elementos nuevamente, vamos a tomar el primero y escribiremos una afirmación. Debería tener la clase completado. Y voy a copiar, por lo que nuevamente, esta es nuestra verificación al final, encontramos los dos elementos, encontramos el primero y luego. ¿Podrías cambiar el should después del clic mientras, así que piensa en esto, cuando encontramos el botón de alternancia, ¿verdad? Y si hacemos clic en él y luego debería tener la clase completado, pero no es el botón de alternancia. Bien, veamos qué sucede. A menudo, solo codifico, solo quiero ver qué sucede. De acuerdo. Falló, ¿verdad? Y muestra dónde está el elemento, ¿verdad? Y muestra que debería tener la clase completado y luego muestra que era una alternancia, ¿verdad? Entonces, no fue así, se agregó en un elemento principal. Entonces, potencialmente podríamos hacer clic y luego decir padre, ¿verdad?, volver al principio. No sé si funcionará o no, pero es un debut. Entonces queremos decir padre al, de acuerdo, aún no. Entonces podemos inspeccionar y ver qué elemento en particular encontró cuando dice padre. Dice que no se pudo encontrar el padre con la clase, ¿verdad? En este punto, la prueba ya es un poco extraña. Permíteme cerrar esto. Así que diría, no. Comencemos de nuevo, como lo hicimos aquí. Donde volvimos al principio. De acuerdo, confirmamos que nuestro primer elemento obtiene la clase. Tenemos que confirmar que el segundo elemento no obtiene la clase. Imagina que nuestra aplicación comete un error lógico, ¿verdad? Tal vez algún usuario dice, de acuerdo. Marqué el primero como completo, pero en realidad marcó todos como completados. Olvidamos como la cosa del filtro. Entonces queremos agregar una segunda cosa. Queremos decir que el segundo elemento no debe tener la clase completado, ¿de acuerdo? Y la pregunta es, ¿cómo seleccionamos el segundo, verdad? Bueno, tenemos un comando especial primero, solo para mayor claridad.

Hay otro comando, equals, ¿de acuerdo? Donde puedes seleccionar, ya sabes, el primer elemento o el segundo, o puedes seleccionar desde atrás con cosas negativas. Entonces, si queremos seleccionar el segundo elemento, usamos equals index equals one, así que moveré esto. De acuerdo, encontramos el primer elemento, ¿verdad? Y tiene la clase completado, y encontramos el segundo elemento y no la tiene, ¿de acuerdo? Y puedes, ya sabes, encadenar. Así que esto, como cualquier selector, funciona, ¿verdad? ¿Verdad? Esto, ya sabes, CSS, jQuery, selector. Así que puedes crear cosas bastante complejas, pero asegúrate de no complicarlo demasiado.

De acuerdo, respondí a esta pregunta. Ahora, ¿qué más hacemos? Así es como lo hicimos. Así que refactoricemos el código. Ya estamos visitando la cosa antes de cada prueba, ¿verdad? Entonces, todas las cosas comunes que hacemos antes de la prueba se factorizan. Otra cosa, estamos codificando la URL, lo cual definitivamente no recomendaría. Entonces, lo que podemos hacer en su lugar, y por cierto, al codificar la URL, fíjate qué sucede aquí. No en este archivo. Si fuera... si fuera una página HTTPS, verías que la página se recarga por completo porque Cypress no sabe qué dominio quieres visitar. Entonces, si es HTTPS, ¿verdad? Quieres poner esa URL en el archivo JSON de Cypress URL, ¿de acuerdo? Entonces, aquí es donde está la URL, pero todas nuestras pruebas funcionan con, ¿de acuerdo? Entonces, ahora en mi archivo de especificación, puedo simplemente decir, visitar como la raíz de la URL base. De acuerdo, esto es mejor por varias razones. Uno, evitarás la recarga en la visita del sitio que ocurre con los sitios HTTPS. Segundo, podrás anular esta URL, la URL base sobre la marcha. Lo más fácil, por ejemplo, si estás ejecutando en CIS, ¿verdad? Y quieres probar tu sitio de preparación, dirás, NPX Cypress run, y luego dirás config base URL y dirás HTTPS, ya sabes, QA company. Así es como cambias tu URL base. Otra cosa que puedes hacer es utilizar variables de entorno en este caso. Entonces puedes decir, Cypress base URL, ya sabes, HTTPS, QA, Cypress, o como sea tu empresa. Esto nuevamente cambia la URL base para que no la codifiques, ¿de acuerdo?

De nuevo, ¿recomendaste no usar clases para los selectores, verdad? Absolutamente, ¿verdad? Pero hacerlo es más semántico. Pero nuevamente, también es útil para el estilo, pero esta no es la aplicación que puedo controlar. Otra cosa es, en lugar de crear objetos de página complejos para todo. Mira este archivo, ¿verdad? Entonces, necesito crear elementos para hacer en todas las pruebas. Entonces, de acuerdo, diré agregar elemento y texto y diré tamaño, ¿qué es? Así que básicamente copio lo que tenía en esta prueba. Y solo tengo que cambiarlo para decir texto, ¿verdad? Entonces, lo que pase aquí, lo escribiré en el cuadro de entrada. Y ahora puedo decir primer elemento por hacer, segundo elemento por hacer, y puedo eliminar estas cosas. Bien, funciona exactamente de la misma manera. ¿De acuerdo? Y estas cosas son muy livianas. Pero funciones individuales ahora mismo, fíjate que dice cualquier texto, solo puedo describirlas usando solo doc, agregar nuevo elemento por hacer. Y puedo decir parámetro texto de cadena, ¿de acuerdo? Ahora IntelliSense está funcionando. Sabe que espera texto. ¿De acuerdo? Y porque typePress ya viene con todo, ¿verdad, necesario? Solo puedes tomar esa función. Y estamos aquí mismo en el archivo de especificación, y luego podemos crear, ya sabes, utilidades. Puedes copiar eso, exportar. Y luego dentro de tu especificación, puedes decir, importar agregar elemento desde utilidades. Perfecto. Funciona exactamente de la misma manera. ¿Verdad? Pero no necesito abstracciones complejas para todo. Tan pronto como vea, ya sabes, oh, estoy usando la misma interacción con mi página, puedo crear pequeñas utilidades. Y fíjate incluso dentro de esta tarea, ¿verdad?, que marca como completada. Solo abstraigo lo que es necesario. Como, no quiero abstraer esto. No quiero crear cosas complejas sobre la interfaz de usuario de mi página, pero digo, oh, ¿dónde está la clase de alternancia dentro de la revisión, verdad? Porque este es el único lugar donde probablemente cambiaré ese botón. Entonces no necesitaré esto en ningún otro lugar. Entonces no abstraigas toda la página solo para poder probarla usando PageObject. Refactoriza tu código según sea necesario. Y recuerda, solo JavaScript. De acuerdo. Codifiquemos juntos, eliminando un elemento, ¿de acuerdo? Así que respondí un poco a la pregunta sobre recomendar PageObjects. No, recomiendo las funciones pequeñas como esta. Creo que son mucho más fáciles de entender que los PageObjects. Entonces, ¿puedes compartir el código de refactorización? Bueno, realmente no es necesario aquí. Así que diría, simplemente codifícalo tú mismo. De acuerdo. Entonces escribamos la segunda, o la tercera prueba, ¿verdad? Podemos eliminar un elemento. De acuerdo. Agrega un par de elementos, y confirmaré que hay dos de ellos. Nuevamente, tengo que eliminar todo antes de que pase. Entonces, Lindsay, estoy limpiando los elementos manualmente, ¿de acuerdo? Antes de volver a ejecutar las pruebas. Entonces, si quiero volver a ejecutar, aprenderemos cómo borrar el estado de la aplicación en unos 15 minutos. De acuerdo, tengo mis elementos, y digamos que quiero eliminar el primer elemento. Tengo que encontrar el primer elemento, así que usaré lo mismo. Ahora necesito hacer clic en este botón. Fíjate que este botón, solo se vuelve visible cuando pasamos el cursor. Desafortunadamente, no hay un hover en Cypress a menos que uses un complemento, porque es un evento nativo, lo cual está bien. No lo necesitamos. Entonces, inspeccionaré mi marcado. Puedo ver que el botón tiene una clase Destroy. De acuerdo. Entonces, lo que puedo hacer, puedo decir, una vez que encuentres el primer elemento, encuentra el botón con la clase Destroy y haz clic. Y después de realizar una acción, queremos agregar una afirmación para asegurarnos de que solo quede un elemento. De acuerdo. Mejor aún, queremos confirmar que el primer elemento. Entonces, mouseover puede funcionar, no puede. Por ejemplo, si es una clase CSS en hover, no funcionará, ¿verdad?, porque el evento mouseover no es lo mismo que establecer un estado de hover. Un estado de hover. Pero pronto tendremos eventos nativos y ya hay un complemento para hacer eso. Entonces, confirmamos que el número de elementos es el mismo, pero tal vez eliminamos un elemento incorrecto. Entonces, lo que podemos hacer es decir contiene por hacer con la clase primer elemento por hacer, segundo. Y digamos que el primer elemento por hacer no debe existir. De acuerdo. Ahora, la vista falla. Mira cómo se niega a hacer clic en un botón invisible. Entonces, recuerda el comando side visit. Tiene todas estas afirmaciones incorporadas. ¿De acuerdo, el servidor tiene que responder, tiene que responder con, como HTML 200.

El evento de carga de la página debe dispararse. Por lo tanto, Cypress, en cada comando tiene aserciones incorporadas. Por ejemplo, si quieres hacer clic en un botón, dice que falló cíclicamente porque el elemento no es visible. Así que imagina a un usuario humano. Si no veo un botón, no puedo hacer clic en él. Entonces, Cypress se comporta de la misma manera. Primero desplaza un elemento dentro de la ventana de visualización, se asegura de que el elemento no esté cubierto por algo más, que sea visible y no esté deshabilitado. Todas estas verificaciones están incorporadas. Y tratan de simular cómo un usuario humano usaría tu sitio web. Entonces, en este caso dice que no es visible. Muy bien, para solucionar este problema, si realmente quieres, puedes usar force true. De acuerdo, usaré force true.

Entonces, en onClick diré force true. Muy bien, ¿qué sucedió aquí? Nuevamente, podemos usar el depurador de viaje en el tiempo. Entonces, encontramos dos elementos de lista. Muy bien, encontramos el primero. Encontramos el destruir. Hicimos clic en él. Y puedes ver cómo Cypress notó que los elementos de la lista cambiaron. Entonces muestra antes y después. Correcto, podemos ver las llamadas execs que la aplicación está realizando, ¿verdad?, al backend. Vemos Li, hacer, ¿verdad?, ahora tiene una longitud de uno. No vemos el primer hacer, texto. Pero todavía vemos el segundo hacer. Todavía existe. Entonces, confirmamos que estamos eliminando el elemento correcto. Y nuevamente, Olga, el hover es un evento nativo y Cypress aún no cuenta con eventos nativos incorporados, pero hay un complemento que simplemente agregas y puedes simular, como, clics reales. No simular. Utilizas el protocolo de depuración de Chrome para enviar el evento real a nuestra página, como un usuario real, así que donde hay un hover también. Muy bien, podemos ampliar esta prueba. ¿Devuelve la aplicación el segundo hacer si recargamos, verdad? Si recargamos la página, como debería, podemos decir, Cy reload. Perfecto, podemos ver qué hay ahí. Solo tenemos que confirmar, así que diremos que todavía debería haber un solo elemento. Entonces, lo interesante es que ahora puedes ver todas las posibles cosas que podrían salir mal. No necesariamente tienes que escribir tareas exhaustivas para todo lo que pueda salir mal. Solo pasa por los casos de uso principales de tu aplicación, asegúrate de que funcionen, ¿verdad? Y las verificaciones más básicas. Luego, si encuentras algún tipo de error y algo falla, luego puedes agregar las pruebas según sea necesario. ¿Verdad? Y esto será tu prueba de regresión. Nuevamente, no, el mouse over no reemplaza realmente el hover nativo porque no activa los cambios de clase CSS. Como todas las clases activas y enfocadas, y las clases CSS de hover, pseudo clases diría yo. ¿De acuerdo? De acuerdo. Una prueba más para terminar esto es, porque es solo JavaScript, si quieres crear múltiples elementos, como escribir un bucle for. Ahora, aquí hay un bucle for, ¿verdad? Así que solo diré esto. Y diré hacer, y solo usaré esta variable que está aquí, K más uno. Y ahora solo confirmaré que para donde se espera el número de elementos. Así que lo limpiaré. Entonces aquí está lo correcto. Agregaré cinco elementos. Cada elemento se llamará hacer uno, dos, tres, cuatro, cinco. Y cuando confirme para nuestros cinco elementos, la prueba debería pasar. Ahora, K no está definido. No es K, es N. De acuerdo. Entonces, creo que Eric hizo esta pregunta, ¿dónde están todos los awaits? Observa que en nuestras pruebas no escribimos código asincrónico JavaScript, por así decirlo. Escribimos comandos y aserciones pero se ven como código síncrono. No hay, digamos, un await aquí. De hecho, si intentas esto, fallaría miserablemente y no funcionaría y sería muy confuso. Y la mayoría de nuestros ejecutores de pruebas, en realidad usan esto. Nosotros no. Entonces, cuando usas async await, ¿verdad? Si declaras una función como async, o si usas, digamos, await aquí, es exactamente lo mismo que usar promesas. Entonces, si usas await aquí, sería exactamente lo mismo que agregar elemento aquí y luego, y luego continuar, es más difícil de escribir, ¿verdad? Entonces, este sería el código equivalente. Incluso peor sería... Esto está bien, ¿verdad? Esto está bien, pero ¿qué sucede aquí? Entonces tengo esta aserción. Primero, es un comando y luego ejecutamos la aserción. Queremos asegurarnos de que haya elementos. Entonces, si usamos async await, como el nuestro, ¿verdad? Podríamos decir, como todos estos elementos solo esperarán. Y esto parece simple, ¿verdad? Y estoy de acuerdo. Es más explícito, menos confuso. Pero luego diríamos, está bien, digamos, esperar que li tenga una longitud, digamos n. Entonces haríamos algo como esto. Entonces, estos son promesas, ¿verdad? Entonces esto es exactamente lo mismo que decir, ¿dónde se fue esto? Como decir, dame, y obtendrás li y harás algo como esto. Entonces, estos son dos equivalentes. Aquí hay un problema. Si hicimos esta sintaxis de await, ¿verdad? Estas son promesas. Para promesas en JavaScript, se ejecutan solo una vez. ¿De acuerdo? Solo una vez. Es un intento único. Entonces, si ejecutas esto una vez y obtienes los elementos de la lista, bueno, adivina qué. Ninguna de estas, como si los elementos de la lista tuvieran un nombre diferente, ¿verdad, si tenemos que reintentar, no podemos volver a esta promesa y ejecutarla nuevamente. ¿De acuerdo? Entonces, si haces esto, usando async await, una vez que tienes esta lista de elementos, eso es todo. Si tiene la longitud incorrecta, si el elemento aún no está allí, si no tiene una clase, ¿verdad?, como escribimos todas estas aserciones. Bueno, no puedes volver a intentarlo. Todos esos spinners serían imposibles. Es por eso que cada ejecutor de pruebas tiene esta sintaxis extraña donde dicen, como expect, sabes, o como esperar, como, entonces tengo que tener una sintaxis extraña para hacer operaciones y también verificar las aserciones de inmediato. Solo para evitar el hecho de que await se ejecuta solo una vez. Entonces, los comandos de Cypress son fragmentos completamente diferentes. Cuando se ejecutan, muy bien, así que digamos esta sintaxis, ¿verdad?, eso es realmente simple. Escribimos instrucciones para un humano, como agregar elemento, agregar elemento, agregar elemento. Lo que hacemos en su lugar, los encolamos, ¿verdad? Entonces encolamos un comando, como, Cy obtener entrada para hacer, escribir. Correcto, así es como realmente es. Entonces, cuando ejecutas esto, agregas todos estos comandos cinco veces a la cola, luego agregas esto a la cola, y luego comienzas a ejecutar.

Luego el navegador se abre, y se ejecutan los primeros comandos que visito. Tenemos toda la lista completa de comandos antes de siquiera abrir el navegador, lo que significa que si este comando, por ejemplo, falla, después de que se ejecute, podemos retroceder, volver a ejecutar como cosas mucho más inteligentes que las Promesas. Promesas, ejecución única, somos un flujo reactivo de eventos donde podemos retroceder y rehacer cosas porque sabemos que tenemos que volver a intentar esos pasos. En este momento, si esta aserción falla, volvemos al comando anterior y lo volvemos a intentar. Probablemente deberíamos hacerlo para volver a intentar todo y así sucesivamente. Pero por eso estas no son promesas, ¿verdad? Y en medio de las noticias async await, porque entonces sería realmente, realmente limitado y esta sintaxis, como escribir pruebas declarativas, sería imposible. Lo cual también explica por qué es imposible asignar el retorno de un elemento. Entonces, digamos que hacemos esto. Y en lugar de esto, hacemos algo como Cy const ele igual. ¿De acuerdo? En el momento en que esto se ejecuta, ¿verdad? En realidad no obtiene los elementos. Solo programa el comando para ser ejecutado. Lo que significa que aquí, li sigue siendo indefinido. ¿De acuerdo? Entonces, si realmente quieres el número de elementos, ¿verdad? Dirías eso. Esto es algo especial que hacemos, que se parece a las promesas, pero no lo es. Entonces, esto se ejecuta tantas veces como sea necesario, y luego pasa los resultados a ese comando. Por eso puedes simplemente decir, constante texto igual a obtener título. ¿Verdad, porque cuando esto se ejecuta y hace la asignación, ninguno de ellos está ahí? ¿De acuerdo? Entonces es 1154. Veamos si tengo algo aquí. Oh, hay este comando llamado ventana de visualización, que es bastante genial. Déjame, puedes probarlo. Entonces, en este momento mi prueba, ¿verdad, pasa? Como puedes ver, estoy ejecutando mi aplicación en 600 por 800. ¿Cómo se ve cuando la ventana de visualización es más pequeña? Puedes cambiarlo y decir ventana de visualización, y decir, no sé. Puedes dar dimensiones o decir iPhone, o decir cuatro. Y ahora así es como funcionaría tu aplicación. Entonces, en este caso, todo está bien. Listo, listo.

Entonces, la pregunta es, ¿puedo hacer algo si el elemento está presente o no, ¿verdad? ¿Puedo hacer algo como si obtengo, digamos, un botón, ¿verdad, si no, entonces para eso lo llamamos testing condicional. Entonces, si vas a la documentación y dices condicional y tenemos toda la discusión sobre por qué no deberías hacer eso. Nunca quieres no saber qué esperar en la página. Si tienes que hacerlo, te damos soluciones alternativas, ¿verdad? Pero siempre quieres ir desde data, ¿verdad? Y siempre saber qué esperas en la página, ¿de acuerdo?

Puedes ver una discusión sobre esto antes de hacer un descanso. Entonces, estos son pruebas unitarias, ¿verdad? Si alguna vez usas solo un MockA, también solo que te gusta obtener tu función o código bajo prueba, realizas una sola acción y luego tienes una sola aserción. Y esto es importante porque si una prueba falla solo tienes el nombre de la prueba. Entonces, si tienes múltiples aserciones y una de ellas falla bueno, generalmente es difícil entender qué parte falló y por qué porque no hay un depurador de viaje en el tiempo. Para pruebas de extremo a extremo como estoy mostrando puedes escribir pruebas más largas. Jennifer, intenta buscar en nuestra documentación este enlace. De acuerdo, probablemente tengamos que. Así que observa, esta es una prueba típica. Va por donde usas la historia, paso a paso y tiene múltiples aserciones porque cada comando generalmente tiene una aserción incorporada. Si algo falla tienes video, tienes captura de pantalla puedes detener la prueba y ejecutarla tú mismo y ver qué hace. Entonces es mucho más fácil depurar una prueba larga y la prueba registrada realmente corresponde a toda la historia. Otra cosa para pruebas más largas es hacer lo siguiente que es bastante genial y mi cosa favorita para hacer después de haberlo aprendido. Mira esto. Voy a eliminar esos elementos. Voy a quitar esto. Solo voy a hacer la pausa del sitio y puedes hacerlo en cualquier lugar. Entonces, ahora mismo solo hizo la visita del sitio, ¿verdad? Y ahora puedo avanzar paso a paso a través de cada comando y puedo ver qué hace. Puedo abrir DevTools, ¿verdad? Puedo investigar qué hace mi aplicación en comparación con. Entonces, la pausa del sitio es realmente buena porque te permitirá escribir tareas más largas, comprenderlas, ¿verdad? Y luego usar el depurador de viaje en el tiempo para comprender tal vez lo que ha sucedido también. Entonces, mi regla personal es si estás describiendo un pequeño fragmento de código solo escribe una prueba unitaria, más larga como una historia de usuario es de extremo a extremo. Puedes dividir, no, especificaciones. Puedes organizarlos por carpetas. Cypress puede ejecutar en las subcarpetas. Y luego estábamos escribiendo pruebas individuales, ¿verdad? Pero también puedes agruparlas, ¿verdad? Puedes decir, esto, digamos, describir, digamos, alternar. Y luego puedes tener una serie de pruebas dentro, describiendo una funcionalidad. Y puedes tener ganchos comunes antes de cada uno, para configurar los datos para esa cosa en particular.

Entonces, Lindsay, si entiendo correctamente, la pausa del sitio es un comando que puedes agregar a tu prueba para pausar en un lugar específico y luego avanzar paso a paso en la prueba, ¿de acuerdo? Así que he mostrado cómo escribir una prueba que recorre la interfaz de usuario de tu aplicación y ejecuta las mismas acciones que el usuario para agregar un elemento, eliminar un elemento, alternar, ¿verdad? Y luego asegúrate de que cuando agregues esos comandos, no solo agregues comandos, comandos, como verificar, obtener, escribir, hacer clic. También quieres asegurarte de agregar aserciones. Si agregas un elemento, debería haber más elementos, ¿verdad? Como, esperamos un número de elementos. Si completas un elemento, debería agregarse o eliminarse una clase. No solo realices acciones, combina acciones y aserciones.

Entonces, Eric, definitivamente recomiendo KitPitch, ¿verdad? Esto es lo que se necesita para escribir una presentación de diapositivas de KitPitch. Solo escribe markdown como se muestra aquí. Separas las diapositivas y luego incluyes imágenes en VectorRepo. Y si usas su URL, el mismo archivo se muestra como una presentación de diapositivas. Lo más simple. Ahora se están alejando, así que tendré que encontrar algo más. Entonces, para mis necesidades y para la empresa, realmente usamos Slides.com porque son increíbles, ¿verdad? Saben lo que están haciendo. Conocen la interfaz de usuario, la experiencia es simplemente increíble. Usan Cypress para probarlos, nosotros los usamos para mostrar. También pueden importar markdown. Así que probablemente cambiaremos a ellos porque git pitch se está alejando, pero fue bueno mientras duró. Así que creo que está bastante cerca. Probablemente podrás tomar el markdown y generar diapositivas en un par de pasos. Eso, pero no lo sé, aún no lo he hecho. ¿Las pruebas de extremo a extremo de Cypress reducen la importancia de las pruebas de integración y viceversa? Entonces, la prueba de integración es una prueba donde tomas, digamos, un par de componentes y tratas de ver cómo funcionan juntos, ¿verdad? Tal vez con algunas otras partes de las cosas. Entonces, sí y no, ¿verdad? Pero yo comenzaría con pruebas de extremo a extremo porque es la única prueba que importa para los usuarios. Y lo que veremos muy pronto es que podrás detener partes de tu aplicación, incluso desde Cypress, por ejemplo, como llamadas de red, etc. Así que diría que comiences con pruebas de extremo a extremo porque no reducen la importancia de la integración, pero creo que son más importantes que la integración cuando comienzas, especialmente. Y cuando puedas agregar pruebas de integración, como ves, cosas que son difíciles de probar para cosas de extremo a extremo. De acuerdo, continuemos.

Entonces, una sección muy corta, seleccionar un playground y Cypress Studio. Así que tengo esto como un capítulo muy corto, así que ni siquiera importa probarlo tú mismo. Pero aquí está la cosa. Entonces, estábamos discutiendo los selectores. Yo uso los elementos de DevTools, ¿verdad, para encontrar el selector? Por ejemplo, este input, incluso Chrome sugiere input con una clase new to do. De acuerdo. Pero, ¿dónde está abrir, podemos abrir el selector playground. Entonces, así es como funciona. Digamos que tengo esta prueba y necesito agregar, ¿verdad, un elemento. De acuerdo, ¿qué es esta caja? Entonces, voy a hacer clic en abrir selector playground. Y ahora, puedo simplemente pasar el cursor sobre los elementos y sugerirá. Por ejemplo, mira cómo si uso data side, el ID de prueba, hablará de vuelta. Si no, elegirá, ya sabes, una clase. Entonces, aquí, una vez que elijo eso, incluso me dice el comando, puedo copiarlo y veamos, pégalo aquí. Y puedo decir escribir, texto más enter. Así es como seleccionaría, ya sabes, un elemento. El problema con ese selector, ¿verdad? Entonces, si, por ejemplo, intento seleccionar este elemento, no creo que tenga mucho sentido. Como este selector. Entonces, todavía es imperfecto, diría yo. Pero aquí hay algo más que muchas personas nos preguntan, como desde hace mucho, mucho tiempo. Digamos que no tengo nada aquí. ¿De acuerdo? ¿Puedes simplemente hacer clic en la aplicación y ver si puedes grabar la prueba a partir de las acciones del usuario? ¿De acuerdo? Entonces, en Cypress 6.3.0, básicamente, la semana pasada, lanzamos una función experimental. Entonces, para que puedas ver esto, debes ir a un archivo Cypress JSON y decir experimental studio true. Así es como controlamos los experimentos, ¿verdad? No los cargamos de forma predeterminada. Pero si lo habilitas en tu proyecto, una vez que la prueba haya terminado, verás esto justo cuando pases el cursor sobre el nombre de la prueba. Entonces, agregar comando a una prueba. Así que haces clic en eso. Ahora esto se llama modo Studio, ¿verdad? Entonces, interactúa con tu sitio para agregar comandos de prueba. Entonces, quiero decir primero to do, enter, segundo to do, enter. Entonces, observa que realmente interpreta correctamente los comandos y no permite todo, solo se observan algunos comandos. Pero cuando hago clic en guardar. Espera.

Nuevamente. Observa que la prueba se ejecuta, ¿de acuerdo? Y esos comandos están aquí. Y observa que se hace combinado el primer to do y el segundo to do porque tienen lo mismo, ¿verdad? Es el mismo elemento que sigo escribiendo. Así que puedes probar eso, ¿verdad? Y puedes darnos tus comentarios. Como, ya sabes, dónde está el enlace, todo. Pero lo que diría es que, observa que cuando grabamos acciones, no había forma de grabar aserciones porque lo ves, ¿verdad? Y no tenemos idea de lo que haces como humano, ¿verdad? Lo que haces. Así que cuando grabes tus pruebas, asegúrate de ir dentro y agregar aserciones. Debería tener una longitud también, porque de lo contrario tu prueba hará cosas a ciegas, pero no tienes idea si la aplicación está haciendo lo correcto en respuesta a esos comandos. Así que definitivamente prueba Cypress Studio y ve qué sucede, ¿de acuerdo? Estoy de acuerdo en que otras herramientas tienen extensiones y complementos de Chrome. Creo que es genial, ¿verdad? No estoy seguro si podremos satisfacer todos los requisitos, ¿verdad? Para tener buenas pruebas, pero lo resolveremos. Escucharemos tus preocupaciones.

Entonces, un par de preguntas rápidas. ¿Tenemos una segunda sesión si no terminamos todos los capítulos? No, desafortunadamente, ¿verdad? Así que tenemos tres horas. Cubriré los conceptos básicos más importantes, pero todo lo que estoy cubriendo, ¿verdad, todo está disponible en las diapositivas y en este repositorio, todo lo que estoy mostrando. Así que no es como si hubiera algo. Es solo una oportunidad para hacer preguntas. Y otra cosa, ¿por qué llamamos a nuestras pruebas integración en lugar de end-to-end? Solo razones históricas hasta ahora, ¿verdad? Probablemente deberíamos cambiarle el nombre a end-to-end y eliminar el nombre de integración. De acuerdo. Entonces, la próxima sesión, nuestro próximo capítulo es restablecer data, ¿de acuerdo? Así que hicimos todo manualmente. Eliminamos todos los to-dos para poder escribir nuevos to-dos y confirmar para los dos. Pero es un poco molesto.

De acuerdo, veamos la prueba número cuatro. Así que retrocedamos. De acuerdo, observa, ¿verdad? Pero todas las pruebas fallan porque ninguna de ellas restablece los data. Entonces, ¿qué hacemos aquí? De acuerdo. Los to-dos, los to-dos se obtienen del servidor, ¿verdad? Ahí es donde se almacenan. Así que visitamos el sitio. Ahí es donde los obtenemos y así sucesivamente. Así que sabemos que los to-dos se guardan en algún lugar y estoy usando JSON server, así que puedo controlar el servidor, ¿verdad? E inserté un middleware especial allí, así que puedo ejecutar un POST, ¿verdad? Mira esto. Así que puedo ejecutar el POST usando curl o algo así, ¿verdad? Así que ahora mismo, tengo todos los elementos. Así que desde la línea de comandos, puedo decir, Reset, y listo. Así que hice una solicitud HTTP a un punto final especial, que introduje solo con el propósito de restablecer los data. Puedo hacer lo mismo antes de mi prueba. ¿De acuerdo? Tenemos un comando especial. Por lo general, no puedes hacer restablecimientos arbitrarios, pero en Cypress, hay un comando, ¿verdad? Que puede hacerlo. Así que esto es lo que podemos hacer. Estoy trabajando con una especificación completa. Así que solo voy a tomar el primero. ¿De acuerdo? El problema es, ¿cuándo queremos restablecerlo? ¿Antes o después de la visita? Así que sabemos que tan pronto como se abre la aplicación, ¿verdad? Comienza, hace una solicitud GET. Así que si no queremos crear una condición donde restablezcamos demasiado tarde después de que la aplicación realmente lo solicite, lo que tenemos que hacer es, antes de visitar el sitio, hacemos una solicitud lateral. Una solicitud lateral es una llamada HTTP que puedes usar. Así que diré restablecer, ¿de acuerdo? Y diré método POST. Y tengo que decir que hacer es solo establecer cuando quieras. De acuerdo, veamos cómo es. De acuerdo, ahora, observa que estoy solicitando esto, ¿verdad? Puedo abrir mi consola, hacer clic en un comando, ver lo que enviamos. Puedo ver lo que respondió el servidor. ¿De acuerdo? Así que ahora, cada vez que inicio la tarea, es todo lo mismo porque restablecimos los data, ¿verdad? ¿De acuerdo? También podemos, en lugar de restablecer, podríamos haber usado algo más. Por ejemplo, tenemos sciwritefile, donde podemos simplemente escribir un archivo diferente para sobrescribir to do MVC data JSON. Podríamos hacer eso, ¿verdad? Solo asegúrate de escribir el archivo correcto. Puedes ver la ruta de un archivo que has escrito. También puedes usar scitask, y esto es lo más poderoso. Así que imagina que no tienes un servidor donde restablecerlo, pero tienes una database en el mismo host donde se ejecuta la aplicación, ¿de acuerdo? Si quieres conectarte a una database y tal vez truncar una tabla, ¿verdad? O verificar la tabla, tal vez durante la prueba con el registro es genial, puedes usar scitask. Ese es un fragmento de código de JavaScript. Se ejecuta en Node. Eso significa que tiene acceso a tu sistema operativo, sistema de archivos, conectarse a una database, ¿verdad? Y puedes usar scitask, llamarlo desde tu archivo de especificación y va al archivo de complementos, se conecta a una database, hace consultas, y así sucesivamente. Así que puedo restablecer esto. Puedo usar scitask. Aquí hay algo más que podemos hacer. Así que ahora mismo, cada vez que restablecemos, enviamos un objeto vacío, ¿verdad? Estamos estableciendo vacío en esto. Pero, ¿qué pasa si no quieres hacer eso, verdad? Tal vez quieras establecer los data, ¿verdad? Y luego inicializar inmediatamente una situación más compleja. De acuerdo, tengo este ejemplo aquí. Así que voy a eliminar esto y voy a ejecutar esta prueba. De acuerdo. Así que aquí en esta prueba. Tengo un archivo de fixture, así que dos elementos. ¿De acuerdo, así que puedo cargar ese fixture, fixture lateral, puedo decir dos elementos. Ahora mismo nada interesante. Luego tengo que hacer esto. Incluso puedo llevarlos a una consola para asegurarme de que se carguen correctamente. De acuerdo, así que estamos cargando el archivo JSON. Tenemos los elementos. Ahora puedo copiar este código y decir restablecerlo. Y solo enviar, pero to-do es cargarlo. Y ahora mira qué genial es. Si ejecuto la prueba, siempre comenzará y ya tendrá un par de elementos. Así que ahora puedo eliminar un elemento, agregar un elemento, lo que sea que haga. Así que esto es bastante agradable. Porque esto significa que puedo configurar datos complejos antes de una prueba en particular, antes de cada prueba. Y la prueba en sí será muy simple. Porque no tiene que, por ejemplo, agregar elementos, marcarlos como completados. Entonces, por ejemplo, si quiero eliminar elementos, también podría restablecer la database desde esta prueba e inmediatamente pasar a eliminar el elemento. Porque mis otras pruebas probarán si agregar los elementos funciona. Entonces mis pruebas estarán separadas por características en lugar de combinar todo en uno solo. Y esta separación ayuda porque si refactorizo cómo agrego un elemento, solo tendré que actualizar la prueba que agrega un elemento. Y mi prueba que usa este fixture para crear un elemento nunca tendrá que ser modificada porque no modificamos cómo eliminamos un elemento. Si modificamos agregar elementos. De acuerdo, cada prueba tendrá su propósito y no se superpondrán tanto.

Respondiendo rápidamente un par de preguntas. ¿Solicitud XHR y marcar websockets? No, Cypress aún no puede hacerlo para websockets. Entonces, en el futuro tal vez. ¿Por qué restablecer en un before-each en lugar de un after-each? Veamos si tengo esto. Aquí está por qué lo harías usando before-each. Así que déjame simplemente quitarlo e ir aquí. Entonces, sugiero restablecer los data usando before-each. También podríamos decir, cuando la prueba termine, se limpiará después de sí misma. Entonces, podemos tener after-each. Podemos hacer esto y moverlo aquí. Aha, ¿ves el problema? Lo movimos, pero ya había resultados de la prueba cuando se ejecutó antes. Nuestra prueba puede limpiar después de sí misma, pero ¿qué pasa con otras pruebas? ¿Estás seguro de que se limpian después de sí mismas todo el tiempo, correctamente? Tal vez no. Así que recomiendo usar before-each, porque no sabes qué están haciendo otras pruebas, si realmente se limpian.

Y eso significa que introduces dependencias. Ahora, aquí hay otra cosa. ¿Qué pasa si la prueba se bloquea por completo? Como si el navegador se cerrara por completo. Bueno, el after-each nunca se ejecutará. Y así bloqueará otras pruebas que asumen que todo está limpio. Por estas dos razones, siempre recomendamos limpiar y configurar todo lo que tu prueba necesita utilizando before-each, y nunca uses after-each. after-each está bien para cosas extrañas. Cuando tal vez quieras cerrar database o enviar un mensaje, ¿verdad? Pero no asumas que funcionará, porque tu ejecutor de pruebas puede bloquearse y nunca hacer eso. Y así no quieres afectar a otras pruebas. Por eso recomendamos usar before-each en nuestras mejores prácticas.

Entonces responde a esto... ¿Cómo puedo usar el restablecimiento dentro de before-each? Tal como mostré, simplemente ejecutas la solicitud dentro, antes de que los datos sean realmente necesarios. Muy rápidamente, Karim, todas las diapositivas que estoy mostrando, ya están ahí. Son solo documentos de markdown, por lo que están presentes, por lo que nunca tienes que descargar nada. Si miras todos los capítulos, todo lo que he mostrado, estos enlaces, solo están mostrando estos documentos de markdown ya en este repositorio. Así que esto permanecerá allí para siempre. Una pregunta rápida de Dmitry, si quiero verificar la diferencia entre el valor antiguo y el nuevo valor, ¿cómo lo haría? Solo voy a hacer esto muy rápidamente. Imagina que tienes un valor cuando haces clic en un botón, y se modifica, y es diferente, pero no sabes cuál es el nuevo valor, pero sabes que debería ser diferente. Solo voy a enviar esto. Este es un ejemplo de una prueba que agrega un elemento y luego verifica que la lista tenga un elemento genial. Puedes ver que debido al modelo de canal de Cypress, si quieres obtener el número de elementos, haces un comando, usas el callback then. Ahí es donde obtienes el valor. Guárdalo en una variable de cierre local. Haz clic en un botón y luego puedes usar la nueva longitud aquí mismo. No es tan sencillo. Lo importante aquí es que este tipo de prueba en la que no sabes qué esperar es un patrón anti. Deberías saber, especialmente si puedes restablecer los datos o como veremos en el control de la red sabemos cómo detener la red, debes preparar todo para que sepas exactamente lo que la aplicación mostrará. Porque entonces puedes confirmarlo todo y no tener pruebas en las que tal vez no haya elementos y en ese caso haga una cosa y tal vez haya elementos que hagan otra cosa.

Creo que tenemos media hora, que es exactamente el tiempo para la última sección que es el control de red. Personalmente, creo que esta es una de las mejores características de Cypress y acabamos de mejorarla enormemente. Así que te gustará. Nuestra aplicación realiza llamadas de red para obtener los elementos, realiza llamadas de red para eliminar elementos, agregar nuevos elementos, etc. Así que queremos asegurarnos de que esas llamadas se realicen y se realicen correctamente. Entonces, ¿qué podemos hacer? Sugiero que todos abramos 05-xhr-spec. Esto tiene un montón de tareas que en este momento están prácticamente vacías y no hacen nada. Y aquí, cerraré todo. Y voy a 05-xhr-spec. Así que estoy preparado.

De acuerdo, vamos a comenzar con un problema. Y el problema es molesto. Tengo esta prueba. Comienza con cero elementos, ¿verdad? Porque pensamos, sí, cuando se carga la aplicación, debería tener cero elementos. ¿De acuerdo? Ahora, la prueba pasa. Todo está en verde. Y sin embargo, no creo que esto sea correcto. Definitivamente puedo ver dos elementos aquí. Entonces, ¿qué ha sucedido? Bueno, aquí está el problema, ¿verdad? Y aquí es donde es importante comprender el ejecutor de pruebas y el comportamiento de la aplicación. Piensa en la secuencia de eventos durante la prueba. Entonces, la aplicación se carga, hace una llamada al servidor, ¿verdad? Así que va y obtiene los elementos. ¿Qué hace mientras los obtiene? Puede mostrar un indicador de carga, tal vez, pero básicamente no muestra elementos, ¿verdad? Entonces, nuestra prueba, inmediatamente, porque no tiene idea de qué tiene que esperar, muestra obténme todos los elementos. No debería haber ninguno, ¿verdad? Entonces, no se encontraron elementos, ¡boom! La afirmación pasa, y la prueba se completa, porque no hay otros comandos aquí. Entonces, tan pronto como esa afirmación pasa, ¿verdad, la prueba se completa? Entonces, la aplicación devuelve algunos elementos. Los muestra, genial, pero la prueba ya está hecha, por lo que nunca fallará. Puedes ver lo que sucede, ¿verdad, si agregamos una espera incorporada? Entonces, por cierto, esto es realmente un patrón anti, pero si tenemos que hacerlo, lo hacemos. En Cypress, debido al seguimiento de comandos, no quieres esperar un segundo o cinco segundos. Quieres decir, espera hasta que haya dos elementos en una lista, o espera hasta que haya una clase y un elemento. Muy bien, lo haces usando CyGet y Assertion, no usando wait. Wait puede esperar otras cosas. Entonces, ahora la prueba está fallando correctamente. Pero el problema es que no sabes cuánto tiempo debes esperar. ¿Debo esperar 10 milisegundos? Eso parece funcionar, ¿verdad? ¿Debo esperar un milisegundo? Eso debería funcionar, ¿verdad? Pero la cosa es que, incluso si dices, espera un segundo y medio, podría estar bien en tu máquina local, ¿verdad? ¿Ves cómo esto es realmente incorrecto? Pasa demasiado rápido. Entonces 50, 150, ¿de acuerdo? Está bien, eso es bueno. Tal vez solo 50. De hecho, ¿por qué no vemos cuánto tiempo lleva esto? Podemos ver esta solicitud de red. Tomó 25 milisegundos. Entonces, localmente, si nuestra prueba se completa en 25 milisegundos se completa incorrectamente. Y si son 30, entonces realmente falla. De acuerdo, la prueba fallida es correcta. Eso es lo que debería suceder. Cualquier cosa que pase es incorrecta. Pasa por una razón equivocada. Entonces, al ejecutar localmente, podría tener un período de espera. Cuando ejecutas en CI, podría tener otro. Tal vez más largo, ¿verdad? Porque ahora el servidor está en otro lugar, por ejemplo. O los datos están en otro lugar. Y esto es muy molesto porque ahora tienes inestabilidad. Al ejecutar en CI, a veces pasa a veces no. Porque está justo en el límite de ese umbral. ¿Y qué hacemos? Bueno, seguimos aumentando el umbral y muy pronto cada prueba tiene 30 segundos incorporados solo por si acaso para evitar pruebas inestables. Entonces, en este caso, en primer lugar, puedes decir en Cypress si una prueba falla, puedes decir reintentos y digamos que se reintentará hasta tres intentos adicionales. Bien, diré, fallaré después de 100 milisegundos. Entonces, si falla, se reintentará una vez más. Entonces, si hay un poco de inestabilidad y no puedes resolverlo, hay reintentos de prueba incorporados que puedes intentar. Puedes intentarlo en el modo abierto de Cypress o simplemente en el modo de ejecución de Cypress. Eso está bien. Pero en realidad vamos a solucionar la inestabilidad en este caso. Entonces, en nuestro caso, no queremos esperar un segundo codificado.

Queremos esperar a que la aplicación haga algo. Por lo general, nuestra aplicación se actualiza con una interfaz de usuario ficticia. Entonces, lo que queremos decir, por ejemplo, obténme los elementos de la lista con la clase 'to do' deberían existir, y tener una longitud de uno. Así que en realidad puedes escribir múltiples afirmaciones adjuntas al mismo comando usando should, múltiples shoulds o su sinónimo, que es lo mismo que should. Simplemente se lee bien: obtén los elementos de la lista. Deberían existir y tener una longitud de cero. Así que nota en este caso, hace las cosas correctamente porque primero, dice que debería existir en el DOM. Esto se encargará de esperar a que la aplicación realmente responda. No puede ser indefinido, y luego decimos longitud cero. Así que puedes agregar más afirmaciones para esperar a que el DOM haga algo. Permíteme eliminar donde intenta. Y la cosa es que, nota cuando adjuntamos múltiples afirmaciones, todas deben pasar con el mismo elemento a la vez. Así que esto pasó, pero este siempre falla porque siempre hay dos en lugar de cero.

De acuerdo, lo responderé más tarde. De acuerdo, podemos esperar a que se actualice el DOM. Pero en este caso, también sabemos que nuestra aplicación está haciendo esta solicitud. Entonces, lo primero que queremos hacer es asegurarnos de que esa solicitud haya terminado. Ahí es donde podemos comenzar a trabajar con la aplicación. No solo con el DOM, no solo con document y el navegador y los elementos son observables. Eso es lo que podemos, desde la consulta de Cypress y así sucesivamente. La red es algo más que el navegador puede observar desde Cypress, y esperar. Entonces, lo que queremos hacer cuando visitamos la página, es espiar las llamadas de red. Y tenemos un comando llamado Sciintercept donde podemos espiar o detener. Lo más importante es asegurarnos de hacer el espionaje o detener antes de que ocurra. Lo cual significa, si quieres espiar algo, ¿verdad?, entonces, no puedo simplemente interceptar. A aquellos. En realidad, lo eliminaré. Entonces, esta es mi interceptación. Si hago esto cuando es demasiado tarde, ¿de acuerdo? Puede ser, ya sabes, capturado, pero es una condición de carrera. ¿De acuerdo? Quieres interceptar. Quieres crearlo antes de visitar una página, antes de que ocurra con seguridad, ¿verdad? Entonces, esta es la forma correcta. Puedes darle, ya sabes, a esta interceptación un alias, para que puedas guardarla como, digamos, loading. Puedes darle un nombre. Y luego, puedes ver que realmente aparece en el registro de comandos. Así que puedes ver cómo ocurre. ¿De acuerdo? Cuando creas esas interceptaciones, puedes ver esta nueva tabla. Así que, estamos viendo todas las URL, pero vamos a la URL, todos. No estamos deteniendo, solo estamos espiando. Solo queremos saber cuándo ocurre, ¿verdad? Y le dimos un alias, y ocurrió una vez. Podemos ser más específicos y podemos decir, get. Porque agregar un elemento también irá a la misma URL, pero usando post, ¿verdad? Así que ahora, somos más específicos. ¿De acuerdo? Y en lugar de esperar un segundo, una vez que tenemos un alias, podemos decir, cy.wait. ¿De acuerdo, ahora falla correctamente? Porque esperamos a la aplicación, nota ahora cómo solía ser antes. Observa aquí, obtuvimos los elementos antes de que ocurriera la red, pero al agregar la espera, tenemos que visitar primero, esperar a que ocurra la red, y luego intentaremos obtener todos estos elementos, ¿verdad? Así que reordenamos los comandos y las acciones. Así que ahora hemos esperado, ahora lo estamos obteniendo, y ahora no hay más confusión acerca de cero elementos, elementos no deseados. Entonces, así es como puedes espiar las solicitudes de red y asegurarte de que ocurran, ¿verdad? Antes de asumir incorrectamente que puedes comenzar a trabajar con la aplicación. De acuerdo, así está bien, ¿verdad? ¿También puedes especificar parámetros de una solicitud de red en la interceptación? Puedes hacer lo que quieras, ¿verdad? Entonces, una buena cosa acerca de esas interceptaciones de red, ¿verdad? No solo... Quiero decir, déjame mostrarlo, ¿verdad? Así que esto es correcto, ¿verdad? Asegurémonos de que inicialmente, ¿verdad? Y vamos a restablecer la cosa. Entonces, primero restablecemos la solicitud. Entonces, antes de ejecutar, nos aseguramos de que no haya data. Así que cargamos los data, ¿verdad? Y ahora la aplicación cargó los data. Asegurémonos de que en realidad, como devuelve lo correcto. Entonces, si haces clic en esta solicitud, puedes ver lo que Cypress ha hecho, ¿verdad? Como dice que esta es la URL en la que estás interesado. ¿Verdad? Así es esto. Si haces clic en la espera, en realidad imprime toda la interceptación. ¿Verdad? En una unidad de comando. Así es donde puedes ver cuál fue la solicitud de mi aplicación. ¿Verdad? Todos los encabezados y todo. ¿Cuál fue la respuesta de mi servidor? Y si puedes esperar, ¿verdad? Puedes decir que es... Mira esto. Estamos y lo llamamos yielding. Entonces, una vez que obtienes este comando, te da un objeto grande. Dentro del gran objeto, tienes la propiedad de respuesta y tiene cuerpo. Entonces podemos decir que el cuerpo de la respuesta debería ser igual a vacío. Así que estamos espiando la interceptación. Supongo que tal vez no lo sea. Así que podemos profundizar con las solicitudes de red y hacer afirmaciones sobre las cosas que enviamos o las cosas que recibimos. El comando es bastante complicado. No solo puedes especificar parámetros, también tienes control programático que puedo mostrar brevemente aquí. Pero depende de ti buscar ejemplos porque hay muchas cosas que interceptar. Comando incorrecto, de acuerdo. Entonces, por ejemplo, puedes tener puedes escribir tu propia lógica donde puedes inspeccionar la cosa que tu aplicación está enviando y agregar una afirmación puedes modificar lo que tu aplicación está enviando. Entonces, si la aplicación envía una cosa que interceptas, modificas y cuando continúa puedes responder, lo que significa que la aplicación está enviando una cosa la miras, haces una afirmación y luego respondes de inmediato, por lo que detienes la red para que no vaya a la cosa. También puedes, una vez que la aplicación responda, aquí déjame ver. Una vez que la aplicación responda, quiero decir, la aplicación envía la solicitud, la interceptas, la permites continuar va a la respuesta del servidor y ahora puedes modificar la respuesta o agregar afirmaciones. Entonces, por ejemplo, si quieres asegurarte de que tu aplicación envíe como texto de mi proyecto, puedes hacerlo, puedes modificarlo, ¿de acuerdo? Así que tienes control programático completo de lo que se envía por la aplicación al servidor y de lo que la aplicación recibe de vuelta. Así que es bastante poderoso. Entonces, si se envían múltiples solicitudes una tras otra, ¿verdad?, ya olvidé esta sintaxis, para ser honesto. Creo que es algo como, puedo hacer algo como esto. Como el sec, no, no es esto. Olvidé, tenemos que buscar cómo obtener una solicitud separada de una llamada separada. Entonces, si la inserción falla en tu interceptación, también debería fallar la prueba, ¿verdad? Entonces, por ejemplo, aquí, si agregamos algo como esto, ¿verdad?, y dices como expect rec body para incluir, ¿verdad? Debería fallar, si no lo está, entonces es nuestro error, ¿de acuerdo? Y si hay una forma de combinar múltiples esperas como promise all, creo que sí, pero tienes que consultar nuestra documentación. Entonces, ¿puedes hacer algo como esto?, e imagina donde es como, no sé, post-it, como múltiples Alice. Entonces, site intercept, como se supone que debe hacer, ¿verdad? Creo que sí, pero tienes que consultar la documentación. De acuerdo, ¿qué más es útil para interceptar? Entonces, estábamos restableciendo los data, ¿verdad? Cada vez antes de que se cargue la aplicación, lo solicitaríamos. Quiero decir, solicitar, restablecer, ¿de acuerdo? Pero aquí hay algo más que podemos hacer. En lugar de hacer esto, podemos decir, cada vez que la aplicación hace una solicitud para obtener esos, simplemente responde con una lista vacía, ¿de acuerdo? Así es cómo funciona, de acuerdo, un segundo. Algo está sucediendo aquí, tal vez así esto respondió con cuerpo, de acuerdo. En realidad no, esto es correcto, ¿por qué no se carga? Entonces, si no hago esto, Veamos, Un segundo. Esto es extraño, porque en realidad muestra las cosas. Ya estoy empezando a hacer esto correctamente. Solo estoy tratando de entender porque esto es lo que queremos hacer. Queremos simular e interceptar. Y cuando la aplicación hace solicitudes, queremos responder con una lista vacía. Entonces, veamos, podemos esperar. Veamos. De acuerdo, esta vez nuestra tabla de rutas está diciendo que hay una llamada de la aplicación a un servidor. Eso coincide. Y lo simulamos. Eso significa que no permitimos que esa llamada vaya realmente al servidor. Interceptamos y devolvemos una lista vacía.

Aquí hay algo más que podemos hacer. Muy bien. ¿Por qué empezamos con una lista vacía? Podemos decir fixture, ¿verdad? ¿Y cuáles son los buenos fixtures que tenemos en esta carpeta? Tal vez dos elementos. OK, dos elementos JSON. En este caso, tenemos que modificar la afirmación. Muy bien. Entonces, la aplicación intenta cargar las tareas al inicio. Interceptamos la llamada. Y en lugar de ir a un servidor, decimos: aquí está el archivo JSON. Aquí lo tienes. ¿De acuerdo? Muy conveniente. Ahora, en este caso, no permitimos que ocurra una prueba completa de extremo a extremo. ¿De acuerdo? Porque estamos interceptando la carga inicial de datos. Nuestras otras llamadas, ¿verdad?, van al servidor real, porque en realidad no estamos interceptando el jefe. Podríamos, ¿verdad?, por ejemplo, podríamos decir, typefirst o algo así, enter. ¿De acuerdo? Antes de hacer eso, podemos interceptar el jefe. Así que cada vez que haya un jefe para /todos, podemos enviar simplemente un elemento vacío como una nueva tarea. Así que veamos. Y escribimos en el campo de texto de nueva tarea, seleccionamos. ¿De acuerdo? Ahora tenemos dos interceptaciones. Y cada una fue llamada. Y podemos confirmar. Podemos decir, Cywait, nueva tarea. Es la solicitud. Así que obtenemos lo que la aplicación está enviando, ¿verdad? Obtenemos la solicitud. ¿De acuerdo? Y, por ejemplo, tenemos un cuerpo. Así que ¿por qué no decimos que el cuerpo de la solicitud debería incluir profundamente, porque es un objeto grande. Es un objeto. Y podemos decir título. Así que escribimos uno más. Y completado, falso. Así que confirmamos que cuando operamos la aplicación a través de su interfaz de usuario, ¿verdad?, y luego... la aplicación envía los datos esperados. Y aquí podemos tener más afirmaciones. Por ejemplo, podemos decir should y... Esto es el cuerpo. Otra cosa que podemos hacer es tener un should callback. Y aquí es donde podemos hacer múltiples afirmaciones. Por ejemplo, esperamos que el cuerpo incluya profundamente. Y cada vez que lo pasamos aquí, título completado. ¿De acuerdo? Y podemos decir esperamos que el cuerpo tenga la propiedad ID. Muy bien. Porque queremos asegurarnos de que también estemos enviando el ID desde el frontend. Esto también es bueno, porque en realidad me muestra afirmaciones particulares, ¿verdad? Y es falso. Entonces, ¿por qué pensé que era. Muy bien. Así que confirmamos todo sobre esto.

Así que preguntas rápidas del chat. ¿Cómo probarías los estados de error con Cypress, probarías el estado de error con Cypress utilizando datos simulados? Absolutamente. Por ejemplo, ¿cómo maneja mi aplicación la falla al cargar? Muy bien. Una cosa que probablemente ya hayas notado, cada capítulo aquí tiene una especificación con marcadores de posición. ¿Verdad? Si estás aprendiendo Cypress y te gusta hacer ejercicios, en realidad pasarías por las diapositivas e implementarías estas cosas buscando en nuestra documentación. Cada archivo tiene una respuesta, cada capítulo tiene una respuesta. Entonces, para que puedas ejecutar las respuestas, porque ahora mismo no están aquí. Observa que no están en Cypress. Esto es lo que haces. Y responderé todas las preguntas después de esto. Así que podemos ignorar los archivos de prueba en nuestra carpeta de integración. Así que eliminaré la respuesta. Y observa que ahora todos los archivos están ahí. Así que nuestra sección es esta. Por ejemplo, la respuesta, ¿verdad?, la especificación en este caso tiene todos los casos diferentes. Creo que este tiene que ser restablecido. Muy bien. Por ejemplo, ¿cómo carga mi aplicación datos? ¿Qué hace mientras carga los datos? Muy bien, en este archivo de respuesta, hay una prueba que muestra cómo asegurarse, cómo ralentizar una solicitud de red para verificar la carga. Permíteme mostrar esta prueba. Bastante interesante. Antes de mostrar esta, vamos a interceptar cosas. ¿Verdad? Vamos a interceptar la solicitud GET inicial de TO DOs. Vamos a responder con un cuerpo vacío. ¿Verdad? Pero vamos a ralentizar. ¿De acuerdo? Así que ahora esta prueba muestra claramente el indicador de carga. Y ahora esta prueba verifica primero que el elemento de carga sea visible. La llamada de red ocurre. Esperamos por ella. Y luego debería ser invisible. Así que podemos ralentizar nuestra red para asegurarnos de que las cosas sucedan. Y ahora creo que en la ecuación, ¿qué sucede en caso de error? Por ejemplo, si mi servidor por alguna razón responde con un 404. ¿Verdad? Y dice que la prueba no lo permite. Y aquí podemos espiar el error de la consola porque nuestra aplicación, lo único que hace, imprime un mensaje en un error de consola. Así que ejecutemos esta prueba. Muy bien. Nuestra aplicación imprimió el mensaje de error, y nuestra prueba simuló un estado de error y confirmó que está sucediendo. Muy bien. Otra cosa que sucedió, ¿cómo interceptas solo las solicitudes POST, ya sabes, con pruebas específicas? Sí. Una cosa que puedes hacer, y esto también es útil para GraphQL. Puedes crear un alias sobre la marcha. Permíteme empezar con esto. Muy bien. Entonces, vamos a interceptar cosas, y vamos a decir solicitud. Y aquí es donde puedes decir, no sé, si el cuerpo de la solicitud, como incluye, o el cuerpo, digamos, el nombre de la operación, ¿verdad? Imagina que esto fuera código GraphQL. Si alguna condición particular fuera verdadera, podrías decir alias, digamos, a esto. Así que en lugar de asignar todo, lo asignas dinámicamente. Esto funciona exactamente de la misma manera. Así que esperamos a que esto suceda. El alias no está configurado, se configura dinámicamente. Así que puedes inspeccionar la solicitud y luego decir, oh, estoy interesado en esto, le daré un alias, y luego puedo esperar ese alias. Luego puedo obtener el alias más tarde y hacer afirmaciones de red también. Con la función intercept, ¿no tenemos que iniciar CyServer? Solía ser que teníamos este método, CyServer, CyRoute, pero son muy limitados. Los duplicamos y se eliminarán en Cypress 7. ¡Así que adiós! Pero lo más importante, utiliza la función intercept. Asegúrate de configurarla antes de la acción que desencadena las solicitudes de red, para que no haya una condición de carrera. Eso todavía es necesario. Entonces, si necesitas un token JWT, ¿sabes?, para, por ejemplo... Digamos... No sé. Si estás haciendo una solicitud de sitio y necesitas el token, tienes que obtener el token de alguna manera. Tal vez desde la ventana, desde el almacenamiento local, y luego... Así que obtén el token de alguna manera. Y luego llamas a .then token. Mira nuestras recetas porque tenemos muchos ejemplos de cómo usar tokens y configurar cookies, y así sucesivamente. Si tengo muchas solicitudes dependientes por página, ¿cómo debo manejar eso? Solo observa las solicitudes que realmente necesitas para la prueba. He visto a personas configurar 150 interceptaciones para cada prueba utilizando beforeEach, porque... Luego tendrían las interceptaciones en caso de que las necesitaran. Cada prueba necesita un par de ellas. Pero siempre configuran 150. Conoce lo que tu prueba requiere y solo configura lo que necesitas. Faltan cinco minutos para el comienzo. Permíteme asegurarme de que no haya olvidado algo importante. Puedes hacer lo mismo. Tenemos una muy buena guía de solicitudes de red. Es una especie de discusión de si todavía es de extremo a extremo si detienes algunas de las solicitudes de red. Así que mira nuestra guía. Más ejemplos. Esas solicitudes de red, interceptaciones firmadas, puedes simular fácilmente condiciones límite que no se pueden lograr solo pasando por la interfaz de usuario. Porque la interfaz de usuario puede tener verificaciones y validaciones que ni siquiera te permiten crear los datos que necesitas para un caso límite. Eso es prácticamente todo. Y quiero terminar con un par de cosas. Siéntete libre de mirar otras secciones y otras diapositivas. Todo el contenido está ahí. Siéntete libre de mirar ejemplos. Tengo cosas más complicadas mostradas en los archivos de respuesta. Siéntete libre de revisar otras secciones. Puedes contactarme, enviarme un correo electrónico, hacer preguntas al respecto.

Tenemos un canal de chat. Quiero terminar con un par de últimas diapositivas. Daniele, el peso y el elemento pueden estar desconectados. Debes consultar nuestra documentación. He escrito un artículo sobre esto. Esto es más complicado y quiero repasar esto.

Y lo más importante que diría es que esto es simplemente JavaScript. Cualquier cosa que haga que tu prueba sea legible, sigue usándola. Correcto. Eso es prácticamente todo.

Para las pruebas de extremo a extremo en Cypress, realmente intentamos imitar cómo el usuario humano utiliza la página, ¿verdad? Por eso hay todas estas comprobaciones, como que los elementos sean visibles y accionables y no estén desactivados antes de hacer clic en un botón. También sugerimos que configures todo lo que necesitas para una prueba antes de que comience, ¿verdad? Si necesitas datos específicos en una base de datos, configura los datos utilizando solicitudes o tareas del sitio. Si necesitas configurar cookies para poder iniciar sesión de inmediato, obtén las cookies, configúralas, y luego la prueba estará iniciada sesión. Si quieres interceptar una solicitud de red y tener un objeto de usuario con una lista de proyectos y todos los datos, intercéptalo, configúralo y luego tu prueba puede continuar desde allí. Puedes espiar y simular llamadas a la API que tu aplicación está realizando. Esa es una de las formas en que puedes acelerarla. Si tus operaciones complejas y costosas, llamadas de API costosas y de larga duración pueden detenerse, entonces la prueba se ejecuta muy rápidamente. Observa que aconsejé no usar esperas estáticas, donde hay un período de tiempo codificado. Y en su lugar, simplemente espera a que la aplicación actualice el DOM o realice una solicitud de red. Eso significa que tu prueba será tan rápida como tu aplicación. Pero nunca esperará innecesariamente algo solo porque lo deseas. Entonces, la prueba se ejecutará tan rápido como la aplicación se ejecute.

Siempre tengo mis herramientas de desarrollo abiertas. A veces puedo acceder al objeto de la aplicación y tal vez hacer algo como llamarlo desde las herramientas de desarrollo. Entonces, en mi ejemplo aquí, puedo acceder a mi iFrame de la aplicación, eso es para mi aplicación, y puedo decir app. Entonces podría exponer cosas y tal vez llamar métodos en mi aplicación. Tal vez pueda inspeccionar cosas y validar el estado interno de la aplicación después de agregarlo. Todo lo que puedes hacer desde las herramientas de desarrollo, también puedes hacerlo desde la prueba de Cypress. Porque la prueba de Cypress, mira, aquí es donde está tu iFrame, donde se ejecuta tu aplicación. Este es el iFrame donde vive tu prueba. Pueden comunicarse entre sí y acceder a todo. Así es como funciona Cypress internamente.

Quiero agradecerles mucho. Ha sido un placer. Para cualquier otra pregunta, primero consulta la documentación. Siempre puedes darle una estrella a Cypress. Si quieres hablar con nosotros, tenemos un canal de chat donde intento responder las preguntas de las personas, generalmente publicando enlaces de regreso a la documentación. Y si quieres enterarte de nuestras actualizaciones, las publicamos en GitHub y también tuiteamos sobre ellas en nuestra cuenta de Twitter, así que no dudes en hacer preguntas o seguir esa cuenta. Muchas gracias. Lo aprecio mucho, a todos. Felices pruebas. Cuídense.