Testing Web Applications Using Cypress

Eso es todo. Que tengas un buen día. Gracias por asistir a esta masterclass. Me encanta Cypress y me encanta dar esta masterclass. Y si eres un usuario realmente avanzado de Cypress, creo que encontrarás algo que te beneficiará de esta masterclass también.

Un poco de limpieza y reglas. Entonces, esta masterclass será de 3 horas, ¿verdad? Tomaremos un breve descanso de cinco minutos al comienzo de cada hora. Porque es difícil sentarse en un lugar durante 3 horas. Y entonces, porque obviamente estás en tu oficina o en casa o donde sea que 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, ¿verdad? Intentaré volver a conectarme 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é atento al chat de Zoom y al chat de Discord. Entonces, uno de los beneficios de una masterclass es que no dudes en hacer preguntas, ¿verdad? Intentaré responder tantas preguntas como sea posible. Esta masterclass se grabará, por lo que obtendrá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 responderé en vivo o tan pronto como sea el momento adecuado.

Bueno, entonces espero que todos tengan este repositorio clonado y listo para usar. Entonces, si no lo has hecho, por favor clona este repositorio para que lo tengas localmente. Necesitarás el nodo, así que asumo que lo tienes instalado. Y lo primero que querrás hacer es asegurarte de que realizas npm install. Puede que tarde unos 5 minutos si estás empezando desde cero, porque instalará dependencias y cypress y todo. Entonces, este repositorio lo tiene todo, ¿verdad? Tiene la aplicación. Estaremos probando. Ya tiene los archivos de especificaciones. Y tiene las diapositivas.

Entonces, voy a empezar a compartir con diapositivas. Todas las diapositivas son solo archivos de rebajas. Y estoy usando este enlace de get-page para mostrar realmente el rebajas. Es bueno que todavía sea enero, porque tendré que mover las diapositivas a otro lugar el próximo mes. Vale. 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 tengo mucha suerte, puedo simplemente codificar y hacer masterclasses y escribir entradas de blog y hacer cosas que encuentro interesantes. Siempre puedes escribirme un correo electrónico después de la masterclass o durante. Soy Gleb en Chipre. También siempre puedes contactarme en Twitter. Intento ser, ya sabes, reactivo y siempre respondo a quien me escribe. Tengo muchas entradas de blog en el blog de Chipre y en mi blog personal. Encontrarás muchas explicaciones de tipo en profundidad. Y también hago pequeños videos de Chipre en YouTube. He estado usando Chipre durante casi cinco años porque trabajé en Chipre durante cuatro años y lo usé durante un año antes así que estoy realmente contento con Chipre. Así que cubriremos muchas cosas. Quiero decir, según el tiempo lo permita. Publicaré el enlace al repositorio en todos los canales. Cubriremos muchas cosas. Cubriremos la aplicación. Es una simple aplicación de hacer y VC así que no tendremos que pasar mucho tiempo en ella. Cubriremos muertes básicas, ese tipo de página interactiva. Veremos cómo podemos seleccionar elementos usando el selector de juegos 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 datos sobre la imagen datos. Probablemente no llegaré a esta sección. Quizás cubra la integración continua. Quizás mencione algo sobre la capacidad de reintentar y depuración mientras cubrimos la sección anterior, pero esta masterclass, este repositorio tiene todo este contenido. Así que si quieres ver qué hacen las características, ¿verdad?, o cómo hacer plugins, cómo configurar la cobertura de código, el material está ahí, pero simplemente no tendremos tiempo para llegar a él porque esta masterclass puede ser larga. No vamos a almorzar, pero tomaremos descansos cortos. Normalmente esta masterclass la hacemos físicamente, ¿verdad? Y la gente habla y puede ayudar porque es una masterclass virtual. Es más difícil, ¿verdad? Pero simplemente usa los chats con tus opiniones y preguntas.

Descubrí que una mejor masterclass y sacarle el máximo provecho depende de tres pasos. Así que primero pasaré por las diapositivas, explicaré el tema, y luego mostraré cómo hacer una prueba específica, ¿verdad? Así que lo escribiré y mostraré qué pasa dentro de Cypress y así sucesivamente. Y luego, dentro de cada archivo de especificaciones de integración, habrá ejercicios, ¿verdad? Como escribir más pruebas una por una. Y ambas cosas te animo a que las hagas tú mismo y yo las haré más tarde, ¿verdad? Y mostraré la solución, pero lo mejor para la masterclass es ser práctico. Así que realmente te animo a que trabajes en tu máquina, durante esta masterclass, ¿vale? Y si te quedas atascado, de nuevo, haz la pregunta en el discordia o en zoom, ¿verdad? Y trataré de ayudar. Pero lo mejor es escuchar lo que explico y luego codificar juntos mientras yo codifico y luego intentar ir a los siguientes ejercicios. Vale, ya dije que necesitarás clonar el repositorio y hacer NPM install. Larick, ¿puedes ayudar a la gente porque algunas personas no ven el canal de discordia. Vale. Supongo que duplicaremos. Excelente. Así que esto es lo que tenemos en nuestro repositorio. Entonces, si miras todos los archivos, ¿verdad?, tenemos muchas cosas. La aplicación está dentro de hacer MVC, ¿vale? Así que está en la sub carpeta y esto tiene sus propios paquetes. Así que si no PM instalas, en realidad instala con 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, ¿vale?. Y así, para cada sección, ¿verdad? todos están como nombrados, cero, uno, cero, dos, todos son numéricos uno tras otro, mientras que las sub carpetas. Entonces, si voy y miro, digamos la integración de Cypress verás que el primer archivo de especificaciones que abriré está aquí. Y luego para la siguiente sección es tu dos y así sucesivamente. Así que cada sección simplemente trabajaremos en una carpeta diferente y todo es independiente. Así que no tienes que terminar lo que el capítulo anterior para ir al siguiente. Todos son independientes. Y mientras estamos probando la replicación, la replicación simplemente estaría funcionando. Así que lo iniciaremos y simplemente se quedará. ¿Está todo el mundo listo? Vale, supongo que todo el mundo está listo. Así que desde el terminal, escribe uno dentro del repositorio. Puedes ejecutar NPM start. Y deberías ver esto, ¿verdad? Si instalaste todo, si tienes no, eso es lo que verás, ¿verdad? Literalmente acaba de iniciar la aplicación y debería estar funcionando en localhost 3000.

Bien, así que vamos a ejecutar esa aplicación en segundo plano todo el tiempo. Bien, así que es un TodoMVC porque esa 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 la vista. Realmente no importa cómo se implemente la aplicación. Podemos ejecutar el CSS prácticamente contra cualquier implementación porque Cypress no se preocupa por los detalles de la permutación, ¿verdad? Lo hace el navegador, lo hace la interfaz de usuario, ¿verdad? Pero al usuario no le importa cómo está implementado. Entonces, ¿por qué debería importarle a Cypress?

Bien, abramos DevTools. Así que lo primero que queremos saber de inmediato es qué sucede cuando trabajamos con la implementación, como esta aplicación, ¿verdad? Así que lo que suelo tratar de observar son como cuáles son las llamadas de red que ocurren cuando la aplicación se carga, ¿verdad? Así que puedo recargar y ver qué obtenemos en el documento, obtenemos un montón de, ya sabes, scripts, ¿verdad? Y al final, nuestra aplicación está haciendo una llamada AJAX, así que podemos inspeccionarla. Así que nuestra aplicación está haciendo un GET a todos, ¿verdad? Y obtiene una lista vacía, porque no hay todos. Así que dentro de una página, tenemos como un marcado estándar, ¿verdad? Tenemos clases para la sección principal. Tenemos un encabezado, ahí es donde probablemente tendremos el cuadro de entrada, y cuando simplemente jugamos todos en una lista desordenada. Y así para cada todo, simplemente lo mostraremos en la pantalla. Así que ese es nuestro marcado. Puedes echar un vistazo a todo.mvc.app.js, tiene una tienda de vistas, pero son detalles de implementación. Realmente no me importa. Pero tengo una pregunta para ti, ¿verdad? Mi audiencia. Entonces, ¿qué sucede cuando agregas un nuevo elemento todo? Así que puedes hacerlo tú mismo. Escribamos, ya sabes, primero por hacer. Bien, así que cuando presionamos Enter, puedes ver que hay otra llamada que la aplicación está haciendo, y es un POST, ¿verdad? Así que envía algo al endpoint 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 nota que la aplicación envía el título, ¿verdad? Que es primero por hacer completado falso. Así que por defecto, cada elemento está incompleto y el frontend también envía el ID. Así que la aplicación está creando el ID para la aplicación, para el elemento por hacer, 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, bien, otro ID, otro elemento. ¿Y qué sucede cuando recargamos? Bien, podemos ver que los elementos regresaron. Podemos ver que esta llamada original para obtener todos, ¿verdad? recupera los elementos. Así que la aplicación, cuando comienza, recupera los elementos. Bien, así es como funciona. Así que llega al servidor usando llamadas Ajax. Ahora aquí hay otra pregunta, pero deberías mirar localmente. Quieres averiguar dónde se almacenaron los elementos. Así que para esto, cambiaré a mi editor de código. Bien, así que puedes usar cualquier editor de código, ¿verdad? Pero me encanta VS Code hoy en día. Así que es tan simple. Kareem, no, la presentación no es privada. Así que si vas al código, está bien, puedes seguir si te pierdes o si quieres pasar más tiempo, puedes tomar este enlace y simplemente hacer clic en cualquiera de los enlaces. Así que ahora mismo estoy en la introducción. Bien, así que busquemos dónde la aplicación guarda los datos. Bien, así que los envía, los almacena, y luego cuando recargamos, podemos ver los datos nuevamente. Así que tiene que almacenarse en algún lugar. Bien, si tienes problemas para ejecutar la aplicación, asegúrate de tener la versión correcta de Node, al menos 12, está bien, 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. Así que si en mi editor de texto, si miro alrededor, ¿verdad? y voy a todo.nvc, puedo ver este archivo data JSON. Bien, y sí, Martin, tienes razón. No lo estoy ignorando porque generalmente comienza con un archivo simple y vacío. Bien, así que aquí es donde mi servidor está almacenando los datos. Verifiquémoslo. Veamos, ¿es data JSON? Bien, así que sí, ahí es donde está. Sí, sí, Lindsey, intenta instalar las dependencias nuevamente e intenta iniciar en el uno. Bien, Nikolai, si tienes una aplicación Grafana, ese no soy yo, probablemente sea alguna otra aplicación que estás ejecutando localmente. Bien, así que al inicio, ¿verdad? cuando la aplicación está comenzando, está obteniendo esos elementos nuevamente, ¿verdad? así que siempre regresamos, está bien? Bien, esta es una aplicación estructurada y solo la estoy usando, ya sabes, para explicar, pero esta es una aplicación moderna, ¿verdad?

Tiene una capa de interfaz de usuario, este es todo el marcado, la entrada, la lista de elementos, todos están ahí. Bajo el capó, la aplicación está usando Datastore y el Datastore está haciendo llamadas API REST, así que en esta presentación, solo hablaré sobre, como probar llamadas REST. Son un poco más simples de probar que GraphQL, ya sabes, GraphQL es más avanzado y solo mira nuestra documentación si necesitas interceptar y espiar llamadas GraphQL u otros tipos de llamadas. Bien, tengo una explicación más detallada de la aplicación y cómo puedes probarla, pero por ahora, comencemos con Cypress. Así que terminé la introducción y déjame comenzar con la siguiente. Bien, así que lo primero que quiero mostrar es, ya sabes, qué sucede cuando simplemente comienzas con Cypress, ¿verdad? Tuve la pregunta en realidad, pero está como, ya sabes, en el chat de Zoom o en Discord, ya sabes, ¿cuánto tiempo has usado Cypress?

¿Cuánto tiempo has usado Cypress, verdad? Así que, he usado Cypress por más de cuatro años. Me pregunto si la mayoría de la gente seis meses, tres años, aún no un día. Excelente, así que tenemos un rango desde recién comenzando hasta veteranos. Perfecto, perfecto, así que todos son bienvenidos. Bien, así que esta sección es para personas que acaban de comenzar con Cypress, ¿verdad? o quieren probar. Así que, escribiremos la primera prueba, configuraremos, y explicaré la documentación. Así que, para esta prueba, crearemos una nueva carpeta, está bien? Así que, instalaste en, ya sabes, para MVC en el taller de pruebas, ¿verdad? Pero esto es lo que sucede cuando comienzas desde cero. Así que déjame mostrar cómo sucede. Así que iré a mi carpeta temporal, y crearé un directorio como primero. Y crearé un directorio como primer-uso-sitio. Bien, y cambiaré. Así que esto es lo que sucede si simplemente creas un nuevo proyecto. Bien, así que estoy usando NPM aquí para crear rápidamente un paquete JSON. Cuando instalo Cypress y lo guardo como una dependencia de desarrollo, no es una dependencia de producción, ¿verdad? No es algo necesario para que tu aplicación funcione, ¿verdad? No, pero es algo que quieres instalar si estás desarrollando, por eso es una dependencia de desarrollo. Así que estoy instalando Cypress, ¿verdad? Usando NPM install Cypress. Vamos. Bien. Así que, porque ya instalé esa versión de Cypress, ¿verdad? la encontró, así que nunca tengo que volver a descargar ese archivo grande. Bien, ¿qué tenemos aquí? Ahora mismo, solo empaqueta JSON, ¿verdad? y node modules. Ahora queremos abrir Cypress y hay diferentes maneras. La mejor manera, diría yo, la más moderna y portátil después de hacer PM install Cypress es hacer esto, NPX Cypress open, te sugiero que lo hagas conmigo. Bien, NPX Cypress open. Así que, esta es una carpeta donde acabamos de instalar Cypress, lo ejecutamos por primera vez. Bien. Nota que muestra que para ayudarte a comenzar, creó un montón de archivos. Bien. Así que, esto es lo que vemos. Oh, por cierto, a veces no hago NPX Cypress open. Así que, en su lugar, simplemente creo scripts en mi archivo de paquete y luego puedo abrir con un comando.

Bien, entonces el archivo cypress.json, déjame cambiar a esto. Déjame abrir mi editor de código para que podamos ver todo. Así que esta es la carpeta. Cypress.json es un archivo donde tendré todas las configuraciones. Así que, por ejemplo, si quiero establecer la URL base, ¿verdad?, como qué URL mis pruebas o como mi aplicación está ejecutando, puedo hacerlo. Puedo usar Viewport, ¿verdad?

, y así sucesivamente. Así que estas son todas las configuraciones. Pero la integración es lo segundo más importante. Ahí es donde estarán tus archivos de prueba. Así que cuando Cypress se inició por primera vez, generamos esas carpetas, integración. Y puedes tener subcarpetas allí y así sucesivamente. Estas son todas las pruebas que creamos como un 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 tu prueba. Así que no tienes que recodificarlos. Luego hay un comando Cypher fixture que puede cargar esos archivos. Soporte 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 soporte. Y finalmente, el plugin es algo que te permite controlar cómo se ejecuta Cypress, pero se ejecuta en Node antes de que el navegador comience. Por ejemplo, podrás consultar una base de datos, ¿de acuerdo?

O cambiar la configuración antes de que Cypress se ejecute usando el archivo de plugins. Bien. Así que una cosa que sugiero cuando ejecutas Cypress por primera vez, mira esos ejemplos que acabamos de generar. Bien, así que dentro de integración, creamos toda una carpeta que tiene un montón de ejemplos, cómo escribir en un elemento, cómo hacer afirmaciones. Cuando Cypress comienza, muestra esos archivos justo aquí, ¿verdad? Déjame cambiar aquí. Así que, por ejemplo, si quiero ver cómo Cypress escribe y hace clic, puedes hacer clic en el ejemplo de especificación, ¿verdad? Mi máquina es más lenta de lo habitual, creo que por Zoom. Bien, así que ahora muestra cómo escribe, por ejemplo. Establecí el viewport a 200 píxeles en Cypress JSON. Por eso se ve un poco raro, déjame cambiarlo. Cada vez que cambias algo en Cypress JSON, cierra el navegador porque los cambios podrían ser bastante grandes, ¿verdad? Así que 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? Hacer todos los comandos y acciones como un usuario real puede. Perfecto, así que usando ambos ejemplos, ¿verdad? Que generamos. Puedes tener una idea de qué es Cypress y qué puede hacer, ¿de acuerdo? Estos son como ejemplos de diferentes afirmaciones que puede hacer. Lo genial es que puedes abrir cada prueba y puedes ver qué hace, ¿verdad? Como todos los comandos con RAM. Por ejemplo, en mis afirmaciones, ¿verdad? El nombre de una prueba está justo aquí. 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 uno visitamos la página y luego obtenemos algo con la clase assertion table y puedes ver ambos comandos como uno por uno. Así que puedes ver cómo lo que escribes, cómo se ejecuta aquí. Bien. 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í, todos esos ejemplos, nota que se ejecutan contra 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 generaste y viste algo y luego quieres mostrárselo a alguien más, por ejemplo, las mismas afirmaciones, la página está justo aquí. Así que puedes mirar ambos pasos y como revisarlos y ver, ¿cómo obtuve la tabla con clase? Oh, de acuerdo. Así que obtuve la tabla y luego encontré algo e hice una afirmación pero como tiene una clase de éxito.

Bien, así que esto es lo que publicamos y mantenemos en todo momento. Bien. Entonces, ¿por qué no codificamos juntos? Bien, así que tenemos este nuevo proyecto, ¿verdad?, donde no hay nada más. Bien, así que incluso cerraré el navegador. Bien, así que en mi editor de texto, simplemente eliminaré esta carpeta, ejemplos, así que solo tengo Cypress integración y puedo crear un nuevo archivo, spec.js, así que es un archivo JavaScript. Ese será nuestra prueba. Bien. Y esta es la prueba más simple que podemos hacer. Podemos, déjame pegarlo aquí, bien. Entonces, ¿qué hace? Bueno, el nombre de la prueba se llama loads y Cypress usa 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, it loads. Y luego la función de callback tiene todos nuestros comandos. Así que 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. Bien, déjame cambiar. Nota que Cypress está observando la carpeta de integración. Así que realmente nota diferentes extensiones. Bien, nota que como esto es, déjame hacer zoom un poco. Nota las pequeñas líneas chirriantes. Así que porque Cypress, estos son objetos globales. Así que nuestro editor de texto no sabe sobre ellos, como de dónde vienen. Así que si realmente quieres arreglarlos, puedes decir Cypress reference types Cypress. Así que esta cosa, la 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 irá dentro de node modules, encontrará el módulo Cypress, que instalamos con npm install y los cargará y ahora lo entenderá. Ahora, mira, si paso el cursor sobre Cypress, muestra nuestra documentación. Bien. Y muestra documentación para cada comando, por ejemplo. Así que site visit, ¿verdad? Puedo ver cómo usarlo y así sucesivamente. Bien, así que ejecutémoslo. Pero una cosa que notarás, Cypress viene con un navegador electron empaquetado. Bien, este es un navegador que es muy similar a Chrome. Realmente, es Chrome, pero como una o dos versiones detrás de 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 déjame intentar ejecutar la prueba en Chrome Canary.

Así que lo más simple es renombrar esto de nuevo a JavaScript. Ahora, Eric, no te decepciones porque cuando usas estos tipos de referencia, esto funciona igual de bien. Así que nota que todavía entiende todo. Muy bien, así que puedo usar mi IntelliSense simplemente teniendo esto. Bien, déjame ejecutarlo. Muy bien. Bien, así que esta es nuestra prueba. Muy bien, de nuevo, lo que ves a la derecha es el sitio web ejecutándose en 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? Entonces simplemente se vuelve a ejecutar. Bien, un par de preguntas. Documentación para nuestros métodos personalizados que creamos y archivos de soporte, consulta nuestra documentación. Describiré la documentación en un segundo, pero la otra cosa es que, ¿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 plugins. ¿Puedo decirle a VS Code que estoy usando Cypress sobre esta línea? Si usas TypeScript, sí, si no, encuentro que esta es la forma más simple de hacerlo. Pero una cosa que quiero señalar, un secreto más, así que estamos en un proyecto JavaScript. No instalamos nada. Bien. Y todavía entiende el comando. Pero si, por ejemplo, digamos que escribimos mal un comando, ¿verdad? Así que si ejecutamos esto, obviamente falla. Pero realmente queremos saber sobre esto. Ups. Bien, así que nota que esto no es función. Así que estamos escribiendo nuestros archivos de especificación dentro de la carpeta de integración de Cypress. Bien. 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. Así que debido a los tipos de referencia, entiende el global, pero esto no está allí. Agrega otro comentario, TS Chuck. Así que ahora todavía estamos usando JavaScript, ¿verdad? Pero nuestro editor de código resaltará todo lo que no tiene sentido. Mira cómo dice que la propiedad business no existe en el tipo Cy. ¿Quisiste decir visit? Porque sabe dónde está el método muy cercano llamado visit. Así que ahora lo voy a arreglar, y ahora todo está bien. Otra cosa que notas es que cada vez que edito y guardo un archivo, Cypress lo vuelve a ejecutar, ¿de acuerdo? Lo cual es muy conveniente. Usualmente mantengo mi editor en un lado de la pantalla, y luego, ya sabes, codifico, digo, en otro, y sigo reejecutando la prueba, ¿verdad? A medida que la actualizo, ¿de acuerdo? Si tu monitoreo de archivos no está funcionando, mira nuestros problemas, tal vez haya algo sobre tu sistema operativo, o tal vez sobre tu editor, o tal vez tu software antivirus impide el monitoreo de archivos. Así que hablé sobre esto. Así que esta prueba, ¿verdad? Como, parece muy simple. Simplemente estamos visitando una URL, ¿de acuerdo? Ahora, aquí es donde es poderoso. Imagina que, por ejemplo, intenté acceder a una URL incorrecta. Tal vez mi servidor está cerrado, tal vez no está ejecutándose, ¿verdad? Si tu prueba se está ejecutando sin cabeza, asegúrate de estar usando un comando cypress open y no cypress run. Hablaré sobre cypress run en un segundo. Así que mi sitio web no está respondiendo. Mi servidor está caído. Todo está roto, ¿verdad? Nota 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ó. Así que si hago clic en abrir un ID, va inmediatamente a ese lugar en mi archivo. Así que incluso side visit puede considerarse una buena prueba de extremo a extremo porque si el servidor no está respondiendo, si está respondiendo con un código no como 200, si es como 500 o 404, este comando fallará. Si tu página no carga y no dispara, evento de carga de página, este comando fallará. Si tu sitio web es lento, ¿verdad? y por defecto, visit espera, olvidé, creo, 60 segundos para que la página cargue exitosamente, puedes controlarlo. Puedes cambiarlo en tu Cypress JSON o incluso en tus parámetros de visit. Creo que 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 establecer. ¿De acuerdo? Pero incluso una simple visita ya nos está diciendo algo. La respuesta del servidor no se bloquea, ¿verdad? Así que esto es lo que está sucediendo. Aquí hay algo más que quiero mostrar. Como mencioné, cambiar el navegador, explico esto, cómo configurar IntelliSense. Lo genial 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. Dame todos los elementos con clase to do. ¿De acuerdo? Así que ahora encontró tres elementos. Muestra tres elementos coincidentes. Y nota que el Get se ejecutará solo después de que Physit complete exitosamente. ¿De acuerdo? Así que Cypress encadena comandos y los ejecuta uno por uno y el comando anterior tuvo que terminar exitosamente. Así que digamos que quieres confirmar que hay tres to dos. 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. Así que lo que encuentres debería tener longitud tres. ¿De acuerdo? Así que 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 incluido. Como no tienes que instalar nada. Como no instalé nada. Y nota como aquí usamos la afirmación de longitud, debería tener longitud tres y nota cuando usas intellisense realmente te muestra la afirmación correcta. Quiero decir, la documentación correcta para esa afirmación. ¿Verdad? Y los ejemplos correctos, correcto. Debería tener longitud tres y así sucesivamente. Si, por ejemplo, dices debería tener clase y dices to do, cada elemento encontrado tiene esa clase. Si pasas el cursor, te muestra de nuevo, documentación para esa afirmación en particular. TS check, explico, realmente usará tipos para resaltar. Y ahora dónde encontrar documentación. Si nunca has usado Cypress, o si acabas de empezar, o si lo has estado usando durante años, tu mejor opción siempre, cuando tienes preguntas, es ir a docs.cypress.io. Aquí es donde se encuentra toda nuestra documentación, o la mayoría. Así que lo único que podrías encontrar interesante es cómo funciona Cypress. Como, ¿cuáles son las características principales y el concepto central? Como, ¿qué es especial sobre Cypress?

Así que como ingenieros, no estamos trabajando en Cypress y luego diciendo a alguien más 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 mis cosas últimamente han sido solicitudes de extracción de documentación, solicitud de extracción de documentación, documentación. Pasamos mucho tiempo documentando cosas.

Concepto central, Command API. Entonces, ¿dónde encuentras documentación para los comandos? Ve a API, ¿verdad? Y verás que cada comando que he estado usando está aquí mismo. Así que usamos, digamos, visit, ¿de acuerdo? Aquí es cómo se documenta cada comando. Mostramos cómo usarlo, como su sintaxis, explicación de cada parámetro, ¿de acuerdo? De lo contrario, así que el tiempo de espera para el sitio de registro. Mostramos ejemplos, ejemplos con opciones, ¿verdad? Como todos los casos de uso comunes. Discutimos cómo, como lo que 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? Así que dije que tu servidor tiene que responder con algo con contenido HTML, pero tiene que ser 200 y eventualmente. Y la página tiene que enviar mucho, ¿verdad? Luego tenemos ejemplos. Al final, usualmente tenemos una historia, ¿verdad? ¿Cómo cambió este comando si cambias en diferentes versiones? De acuerdo. Y una cosa más que es importante, al final de cada comando están los comandos relacionados. Así que por ejemplo, si acabas de escribir, comenzaste a usar visit, y luego tienes una pregunta, bueno, ¿qué pasa con visitar otra página, pero retroceder en la historia, verdad? Como ir a la página principal, ir a la página de about, y luego hacer clic en el botón de retroceso. ¿Cómo funciona eso? ¿Cómo lo hago? Usualmente ponemos enlaces como ese en ver también. Así que si aprendes visit, ve y lee ver también. Mira nuestros ejemplos. ¿De acuerdo? Así que hay muchos comandos. Buen truco. Un buen truco que puedes recordar es que todo lo que hacemos tiene un pequeño enlace corto. Así que por ejemplo, si quieres saber cómo funciona visit, puedes hacer no docs.cypress.io, sino en cypress.io y luego visit. Y esto te redirigirá automáticamente en todo momento. ¿Verdad? Así que si quieres saber cómo funciona el comando get, tienes que get. Así que este comando on, eso es lo que usamos para asegurarnos de que los enlaces que damos en nuestros documentos y nuestros tipos y todo, no... No se rompan si movemos la documentación. Como un clip, todos van inmediatamente directamente a esta documentación. ¿De acuerdo? Y cuando editamos algo, si pasamos el cursor, realmente te dice, 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. Así que una cosa más, si solo quieres saber y aprender, tenemos bajo ejemplos, tenemos recetas más largas que muestran cosas avanzadas, ¿verdad? Tenemos videos tutoriales y listas de reproducción y ejemplo de construcción de la cosa. También sugiero como esta masterclass está ahí, pero también sugiero que revises esta página, los cursos, ¿verdad? Así que estos son cursos externos donde la gente ha 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. Así que no tienes que pagar dinero para aprender esto, ¿verdad? Puedes encontrar y comenzar viendo cursos gratuitos y luego ver qué más hay en él. De acuerdo, un par de preguntas. ¿Dónde encontrar la lista de cada afirmación, verdad? Así que una cosa que siempre quieres hacer al encontrar algo es usar la búsqueda, ¿verdad? Nota que escribí assertion e inmediatamente fui a la página de afirmaciones donde documentamos cosas. Esto no es exhaustivo porque la forma en que Chai funciona, puedes combinar esas cosas, ¿verdad? Y tener como afirmaciones, como esa, por ejemplo, combinar varias palabras clave modificadoras, ¿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 mientras escribes, si tienes intellisense, te dirá qué está pasando. ¿Puede Cypress controlar múltiples navegadores al mismo tiempo? No. Entonces, ¿puede Cypress controlar múltiples navegadores? Tal vez, ¿es eso correcto? Así que puedes encontrar preguntas o respuestas a preguntas como esa usualmente escribiéndolas en nuestra búsqueda. Así que hablé sobre esto. Cosa importante, FAQ, y mantenemos esto actualizado, preguntas que son demasiado pequeñas para una receta, pero más grandes que, o no relacionadas con la documentación, ¿verdad? Así que por ejemplo, ¿cómo verificas el texto de un elemento? Usualmente dices algo como esto. Pero ¿qué pasa si tiene un espacio no separable, como todos esos pequeños detalles extra, verdad, están aquí. Pero afirmaciones, intento afirmaciones. Personalmente no me importan solo las afirmaciones, ¿verdad? Como, creo que ChaijQuery ya está funcionando, así que no vamos a cambiar. Algunas personas intentan, por ejemplo, agregar a nuestras afirmaciones, solo afirmaciones, encuentro esas como duplicados y no tan poderosas, especialmente si miras Synon, ¿verdad, versus solo mux. Synon es mucho más poderoso, así que no vamos a agregar cosas. Una cosa más. Si quieres saber qué ha cambiado, tenemos un registro de cambios, ¿verdad. Así que cada versión de Cypress está documentada y puedes encontrar como qué cambió con enlaces a cada PR y así sucesivamente. Si quieres saber en qué estamos trabajando, está bajo la hoja de ruta. De acuerdo, así que los elementos de gran importancia tienen su propia hoja de ruta. Pregunta, ¿cómo gana dinero Cypress, tenemos como, no. ¿Es Cypress gratis? Sí, así que todo lo que estoy mostrando hoy es absolutamente nuestro corredor de pruebas de código abierto con licencia MIT. Ganamos dinero del panel de control de Cypress donde las organizaciones cuando tienen muchas pruebas, quieren grabar video con resultados de prueba, 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 de la escritura de pruebas. Así que mi consejo al final de esta sección es asegurarte de configurar IntelliSense. Como he hecho aquí con esta línea. Si usas TypeScript, si configuras TypeScript, entonces ni siquiera tienes que hacer eso. Pero si solo estás comenzando con JavaScript, no quieres complicarte 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 configuras, todo está bien. De acuerdo, así que esta fue la introducción al nuevo proyecto. Vamos al siguiente. Vamos a escribir pruebas para nuestra aplicación. De acuerdo, así que voy a cambiar aquí. De acuerdo, así que veamos el primer tipo de comando contiene y prueba de recuperación, ¿de acuerdo? Así que estoy pidiendo a todos. Así que hacer MVC está ejecutándose, ¿verdad? Todo está bien, todavía está ahí. Y ahora queremos cerrar Cypress como lo estábamos ejecutando, ¿verdad, no necesitamos eso. Así que ese primer proyecto, podemos olvidarlo. Así que en su lugar, voy a volver a mi masterclass de pruebas Cypress, de acuerdo, así que mi aplicación está ejecutándose. Gamels aquí. Y aquí puedo iniciar Cypress usando este comando NPM run site open o puedo hacer NPX Cypress open. De acuerdo, así que ahora estamos de vuelta en nuestro repositorio de masterclass de pruebas Cypress. De acuerdo, cambia de nuevo para que no tenga múltiples navegadores. Así que, quiero abrir este cero uno básico. Así que voy a básicamente por cierto, así que esta pequeña cosa es un filtro. Así que puedes rápidamente limitarte a una subcarpeta o parte del archivo. De acuerdo, y en mi editor de texto, quiero abrir el mismo archivo. Así que voy a abrir, así que no necesito esto, aquí mismo, Cypress. ¿Dónde está? Cypress integration spec. De acuerdo, así que tengo esta prueba y espero que puedas abrir en tu editor de texto y en Cypress también, ¿de acuerdo? Así que veamos. ¿Funciona esta prueba? Si hago clic en ella, esto es lo que sucede. De acuerdo, la prueba falla. De acuerdo, esto es muy común.

Está bien. Estamos escribiendo pruebas. Queremos verlas fallar por la razón correcta, ¿verdad? Y queremos arreglarlas o arreglar la aplicación y queremos verlas pasar. Así que verás muchas pruebas fallidas, te lo garantizo.

Bien, así que una cosa que podrías notar es que estamos usando el comando contains. Bien, así que podemos abrir nuestro editor de texto. Así que cite contains. Entonces, ¿dónde está la documentación para este comando? Bueno, está en on cypressio contains. Bien, contains. Bien, así que puedes adivinar leyendo la documentación lo que hace site contains. Así que en este caso, déjame abrir la documentación. Esto es lo que hace. Estás tratando de encontrar un selector con texto particular, ¿verdad? Así que nuestro selector es el elemento H1, ¿verdad? El elemento de encabezado con texto to do this app. Bien, bien. Pero, ¿por qué está fallando? Bueno, miremos esto, ¿verdad? Así que 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 esto tener éxito, probablemente queramos arreglar la prueba y usar no to do this app, sino solo to do this. Ah, cerca, ¿verdad? Tal vez sea to do this. Bien, es to do this. Aquí hay algo importante, ¿verdad? Así que contains pasó. Ve y pasa el cursor sobre el comando, ¿verdad? Nota que cuando pasas el cursor sobre el comando, resalta el elemento que se encuentra, ¿verdad? Así que el get encontró la caja de entrada. Encontró el pie de página. Bien. Y luego el contains encontró esta cosa, bien? Así que encontró el elemento esperado. Es muy fácil encontrar un elemento incorrecto, ¿verdad? Por ejemplo, si no usas h1, site-contain todavía funciona, entonces solo busca todos los elementos, ¿verdad? Puedes encontrar donde sea, solo por texto. Así que si miramos to dos, lo encontró. Pero, ¿y si usamos to do, bien? Todavía el correcto. ¿Y si usamos to do MVC? En realidad, no, es to-do MVC, ¿verdad? Podríamos asumir que encontró algo en la parte superior. Pero nota que encontró este elemento. Así que cuando escribes una prueba y pasa por primera vez, asegúrate de inspeccionar lo que hace, ¿verdad? ¿Encuentra el elemento correcto? ¿Podría confundirse con otra cosa? Y si encuentra algo incorrecto, entonces actualiza la cosa, ¿verdad? Tal vez agrega el selector o un mejor selector, ¿verdad? Para asegurarte de que la prueba está pasando por la razón correcta.

Así que hubo una pregunta sobre cómo hacemos esto más legible? Tal vez queramos usar algún tipo de sintaxis especial como cucumber y creo que la mayoría de las cosas son excesivas como verás más adelante en esta masterclass, pero las pruebas ya son bastante legibles. Personalmente encuentro la sintaxis extra de cucumber. No agrega mucho, pero en realidad hace que escribir JavaScript sea mucho más difícil. Así que, y agregan sobrecarga en tu configuración. Así que no creo que agregar específicamente algo tenga sentido. Hablaré sobre selectores en un segundo usando objetos de página. Llegaremos a esos.

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

Algo más. Bien. Antes de llegar a los selectores, quiero mostrar algo más. Así que digamos, estoy usando un selector incorrecto. Nota este spinner azul. ¿Verdad? Y nota que la prueba no falla inmediatamente. Es muy importante en Cypress, ¿verdad? Cypress no sabe nada sobre tu aplicación y cómo 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. Así que Cypress tiene estas afirmaciones que son como casi como direcciones de usuario. Oye, cuando la aplicación carga, entonces debería haber este texto en ese selector. Si estás levantando la mano, ¿puedes hacer preguntas en el chat, verdad? Así que aquí está la cosa. Cypress asume que cada comando pasará después de un tiempo de espera, por defecto cuatro segundos, ¿verdad? Así que como puedes ver, esto toma cuatro segundos antes de que falle. Así que Cypress reintenta ese comando, literalmente va y busca de nuevo para este selector o esta prueba. Si no, intenta de nuevo, si no intenta de nuevo. Así que todos los comandos que pueden reintentarse de manera segura, se reintentan automáticamente. Y con el spinner azul, es lo que ves el comando, reintentando, reintentando. Tal vez tu aplicación se actualizará. Por defecto, son cuatro segundos, puedes cambiarlo globalmente o por comando. Así que déjame mirar, establecer muy largo, y ahora reintentará, reintentará, reintentará, porque nunca sabemos cuándo tu aplicación realmente terminará de actualizar la UI, bien? Y como esto puede suceder por múltiples razones. Así que si puedo ir aquí en esta aplicación, ¿verdad? Y ahora mismo es app title. Pero si lo cambio, y agrego a, sí, ¿viste que la prueba acaba de pasar? porque de repente encontró el elemento, bien? Así que comandos con los comandos de consulta como find-me-element, debería haber cinco, ¿verdad? El comando más la afirmación, siguen reintentando y ese spinner azul y barra de progreso te muestran cuánto tiempo tarda en funcionar. La otra cosa que es importante aquí es que estamos usando Cypress Open, ¿verdad? Aquí está la diferencia. Así que voy a hacer que esta prueba falle ¿Verdad? Así que esto falla después de cuatro segundos. Genial. Voy a cerrar Cypress solo por ahora. Bien. Y ahora está ejecutando esta prueba. Así que cuando trabajas con Cypress y trabajas en la aplicación, usas Cypress Open. Eso es lo que trae el navegador, ahí es donde puedes ver los archivos, todo. También hay un comando Cypress run. Y así que ahora mismo tengo mi aplicación ejecutándose. Haré en lugar de Cypress Open, Cypress Run. Ahora, porque tenemos muchos archivos de especificaciones diferentes, quiero ejecutar solo el que estábamos editando. Así que diré spec cypress-integrations 01 basic spec. Así que este es el nombre de un archivo que acabamos de ejecutar.

Así que esta prueba falla, ¿verdad? Esto es lo que sucede cuando ejecutas Cypress en modo sin cabeza. Y esto es lo que harías en un servicio de integración continua. ¿Verdad? Dirías Cypress Run. Y entonces dice, está bien, esta es mi versión. Estos son los archivos que ejecutaré. Y entonces pasa por este archivo, ¿verdad? Y solo tiene, ya sabes, una interfaz de usuario de terminal no gráfica. ¿De acuerdo? Pero esto falla, tal como sabemos que debería, ¿verdad? Y nos da 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 bajo Cypress screenshots y nombradas después del nombre del archivo de especificación y la prueba fallida. Así es como se veía mi aplicación cuando falló. ¿Verdad? Así que este es el modo sin cabeza, ¿verdad? Nunca vimos aparecer Cypress o no. También puedes ejecutar lo mismo en modo con cabeza. Así que, y puedes ejecutar ahora mismo tendencias de electron pero puedes decir navegador Firefox o navegador, ¿verdad? Y al usar sin cabeza o con cabeza, puedes cambiar cómo se ejecuta. Así que ahora mismo estamos ejecutando en modo no interactivo pero en con cabeza. No hace diferencia. Es todo lo mismo. De acuerdo. Simplemente fallará y terminará. ¿Verdad y la captura de pantalla se guarda. Mi máquina es más lenta, ¿verdad? Debido a Zoom. Aquí hay otra cosa. Así que toma capturas de pantalla. Así que puedes desactivar las capturas de pantalla. Puedes desactivar el video pero se toma automáticamente. Déjame mostrar un video muy rápido. Nuevamente nombrado después del archivo de especificación. De acuerdo. Así que en tu CI, en cada sistema operativo, no tienes que instalar nada, ¿verdad? Funciona de inmediato. Toma un video de la ejecución de la prueba. Ahora nota cómo el video es un poco entrecortado. No es tan fluido como podría ser porque mi máquina está ahora ocupada con Zoom y grabando, ¿verdad? Así que cuando ves como estos pequeños saltos en el video o cuadros caídos o como pausas y tartamudeos, eso significa que tu CI no tiene suficiente CPU, ¿de acuerdo? Para realmente ejecutar Cypress porque tu aplicación podría ser grande, ¿verdad? Podrías estar haciendo mucho. Cypress agrega su propia sobrecarga, ¿verdad? Como todos estos registros de comandos y ¿verdad? Y también estamos capturando con video. Así que necesitas una máquina más potente si ves tartamudeos dentro del video. La velocidad realmente no importa, ambos sin cabeza creo que se ejecutarán aproximadamente igual. Cypress no es bueno para scraping pero es bueno para ejecutar pruebas. De acuerdo. Así que esta fue la ejecución de Cypress, ¿verdad? Grabación. Entonces, ¿cómo seleccionas un elemento? Así que tenemos nuestra opinión. Tenemos mejores prácticas, ¿verdad? Y así tomaremos un descanso después de que termine esta pequeña sección. De acuerdo, antes de irnos. Así que aquí está nuestra opinión, ¿verdad? Y podrías estar de acuerdo o no. Así que digamos que tenemos un botón y tiene ID, ¿verdad? Algunas clases y así sucesivamente, ¿verdad? Tenemos rol y también podemos agregar atributos personalizados y también tenemos la etiqueta en el botón, ¿verdad? Enviar. De acuerdo. Así que, ya sabes, si solo decimos, consígueme un botón, bueno, eso es un poco raro, ¿verdad? Porque podría haber un montón de botones. Así que definitivamente no lo recomendamos. Tampoco recomendamos usar clases que se usan para el estilo, ¿verdad? Como, ya sabes, bootstrap button y button large, o tailwind. Todo esto puede cambiar. Así que probablemente no deberías. Podrías querer usar IDs. Quiero decir, los IDs son bastante estables, pero aún pueden cambiar, ¿verdad? Y pueden chocar o lo que sea. Usar roles, ¿verdad? O usar algo que uses para, para el formulario. Quiero decir, puedes usarlo, pero ahora se convierte en una cuestión de juicio, y como, depende, ¿verdad? Tal vez te alejes de un formulario y luego tengas que escribir con eso. Cosas como texto, ¿verdad? Algo que sea visible para el usuario. Creo que mucho mejor, porque son como lo obvio, si un sitio contiene enviar no está allí, como falla al encontrar el elemento, solo miras las capturas de pantalla. Es como, oh, espera, lo renombramos a como ordenar. Y así es fácil de arreglar. Y también preferimos mucho usar atributos de datos específicos. De acuerdo, como al agregar datos, como test ID o data side. De acuerdo, de acuerdo. Así que digamos, ¿por qué es mejor? Bueno, porque el texto podría ser traducido, ¿verdad? Tu aplicación podría mostrar texto diferente. Así que por ahora, ya sabes, contiene, pero al usar ideas, ¿verdad? Puedes hacer esto fácilmente, de acuerdo. Y cualquiera que mire este marcado y diga, de acuerdo, ¿cómo encuentro el botón? Timur, ¿puedes hacer una pregunta en el chat o, sí, en Zoom o en discord, por favor? Cualquiera que mire este marcado dirá, de acuerdo, data side es para mis necesidades de prueba. Perfecto, no hay duda. XPath, no lo recomiendo. Tenemos un plugin de XPath, XPath son tan difíciles de entender y ver. Así que no lo recomendaría. De acuerdo, ¿qué más? Así que la biblioteca de pruebas le gustan los roles. Bien, obtener por etiqueta. Siéntete libre de usarlo. Puedes simplemente importar y agrega comandos personalizados. Así que, agrega solo un poco, pero es tu decisión. ¿Qué pasa si quieres usar objetos de página? Así que 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 solo 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 algún lugar, ¿verdad. Y reutiliza el código. Es solo JavaScript normal. Puedes crear tu propia abstracción para que no codifiques el selector, de acuerdo. ¿Qué seleccionas para el elemento de etiqueta con elemento en la lista, ¿verdad? Así que llegaremos a eso en un segundo una vez que comencemos a escribir esas pruebas. Así que en esta sección, justo antes de tomar un breve descanso de cinco minutos, mostré cómo los comandos reintentan, ¿verdad. Así que no sucede instantáneamente. Solo dices, encuentra algo y afirmación y sigue reintentando, reintentando si es seguro reintentar y puedes controlar la afirmación.

Y luego mostré lo que puedes ejecutar Cypress en modo no interactivo o sin cabeza en CI usando Cypress Run y toma videos y captura capturas de pantalla. Bien, voy a tomar un descanso de cinco minutos. Así que ahora mi hora es 1110. Así que continuemos a las 1115, ¿de acuerdo? En cinco minutos, estira tus piernas y vamos a comenzar a escribir pruebas y lo mejor es que usaremos selectores y veremos cómo podemos seleccionar el elemento para confirmar. Sí, varios complementos de Cucumber para Cypress así que podrás ejecutar, escribir pruebas usando Cucumber.

Bien, una pregunta rápida. Si usas Datasite, ¿verdad? ¿Quieres eliminarlo en producción? No, no vale la pena. Ambos atributos añaden muy poco, tu página está comprimida y comprimida con gif. Así que ambas cosas añaden una sobrecarga mínima. Probablemente tienes como una sola imagen que es más grande por 10 veces y todas esas cosas. Y si eliminas los atributos de Datasite de tu código de producción, bueno, no podrás probar el código de la aplicación, ¿verdad? En producción. Así que digo, mantenlos. Por cierto, sí, Cynthia, recientemente publicamos una entrada de blog sobre cómo ejecutar Cypress en M1, ahora un blog de Cypress si alguien está teniendo problemas. Personalmente no tengo M1, mi portátil es de hace tiempo. Pero parece funcionar bastante bien. Y tengo todos los puertos, así que no voy a cambiar pronto. Bien, así que continuemos. Como que escribimos la primera prueba, ¿verdad? Pero ahora, ejercitemos nuestra aplicación y cómo podemos organizar nuestra prueba usando Mocha Hooks.

Bien, así que 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. ¿Es lo más importante poder verificar o completar un elemento? ¿Es lo más importante eliminar o es lo más importante agregar? Quiero decir, si no puedes agregar un elemento, bueno, ninguna de nuestras características funcionaría. Digo, agrega un elemento. Así que comencemos a agregar elementos. Trabajaremos en Cypress integration 02. Esa es nuestra sección actual. Así que abriré ese archivo aquí mismo en mi editor de texto. Así que Cypress integration 02 agregando elementos, SPAC. Bien, ya tenemos un par de marcadores de posición allí. No hacemos nada. Y podemos iniciar Cypress y BX Cypress. Abrir, en modo interactivo. 02 SPAC. Ahora mismo, creo que la mayoría de nosotros no hace nada. Así que fallaremos o no haremos nada. Bien, o ajustamos pruebas de marcador de posición. Así que no hay comandos para emitir. Bien, lo único que noto aquí es que esas pruebas probablemente fallarán porque no estamos eliminando ningún elemento. Así que 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 tarde. Así que escribamos nuestra primera prueba. Es de extremo a extremo, pero significa que queremos abrir la aplicación. Queremos encontrar el campo de entrada. Queremos escribir algo, hacer clic en enter. Escribir algo más, hacer clic en enter. Y queremos confirmar que hay dos elementos. Así que lo haré para mostrar cómo funciona. Y te animo a seguir adelante. Déjame cerrar esto para que esté. Así que esta es la prueba. Para que podamos concentrarnos solo en esta prueba en particular, diré it dot only. Así que este es un modificador para Mocha, que dice que solo quiero ejecutar esta prueba. Así que si lo guardo, nota cómo Cypress ahora solo 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. Bien, genial. Bueno, entonces tengo que encontrar este campo de entrada. Así que lo que puedo hacer ahora mismo, puedo abrir mis herramientas de desarrollo y bajo elementos, pasar el cursor sobre ese elemento, ¿verdad? Tal vez inspeccionarlo, ver qué tipo de clases que tiene atributos de datos. Nota cuando pasamos el cursor, las herramientas de desarrollo en sí me dicen que es un input con clase new to do, ¿verdad? Como justo ahí. Así que puedo decir, así que obtengo, a veces no se interpone cuando es tan grande. Input, new to do. Bien, ¿encuentra la cosa correcta? Encuentra la cosa correcta, genial. Así que ahora que encontré esa entrada, te animo a escribir junto, ¿verdad? Así que obtienes una idea. Escribiré como un usuario, ¿verdad? Así que digamos primero por hacer. Y cuando queremos escribir enter con la tecla especial enter, simplemente diremos enter pero en llaves, ¿de acuerdo? Así que piensa en esto. Así que encontramos la entrada, escribimos y nota el registro de comandos, ¿verdad, muestra algo interesante. Así que voy a hacer clic en un comando para pausarlo. Y ahora muestra primero que todo, el elemento de entrada por esta cosa en. Así que este punto rojo es el elemento central en el que estamos escribiendo. Y también porque Cypress mira tu aplicación y nota cambios antes y después del comando, en realidad tiene dos instantáneas, ¿verdad? Así que nota como justo aquí cuando pasamos el cursor sobre visitar, muestra una aplicación no como está ahora, sino cómo estaba durante el comando de visita. Así que Cypress toma automáticamente instantáneas de volcado. Y cuando pasas el cursor, en realidad restaura esas, ¿verdad? Así que puedes ver cómo se veía la aplicación en cada paso particular. Así que lo llamamos depuración de viaje en el tiempo. Y así cuando escribió, Cypress notó antes y después, se veía diferente, ¿verdad? Así que antes de escribir, no había nada después de que se agregó un nuevo elemento, ¿de acuerdo? Si quiero seguir escribiendo, es como encadenar. Si todavía tienes un elemento, puedes escribir más. Así que segundo por hacer, enter. Así que escribió el primero, luego el segundo. Y ahora tenemos tres elementos en total. Bien, la pregunta era, bueno, tengo esta prueba y luego tengo esta prueba, ¿verdad? ¿Tengo que usar visitar? Bien, así que ejecutemos dos pruebas juntas, ¿de acuerdo? Así que diré solo y solo. Así que ahora tenemos dos pruebas. Quieres hacer que tu prueba sea lo más independiente de cada una posible. Así que si asumes que la prueba anterior tiene que ejecutarse antes de que esta prueba pueda comenzar, eso trae dependencias, ¿verdad? Así que se vuelve difícil concentrarse solo en una prueba porque tienes que ejecutar la prueba anterior una vez, ¿verdad? ¿Qué pasa si quieres seguir trabajando solo en la segunda? Bueno, todavía tienes que ejecutar ambas. Así que la forma en que aconsejamos es hacer que cada prueba sea independiente. Si quieres que se haga algo antes de la prueba, muévelo a beforeEach hook. Así que beforeEach es una sintaxis de Mocha que dice antes de cada prueba ejecuta este callback. Así que en nuestro caso, queremos visitar la página antes de cada prueba, así que lo moveré aquí y lo eliminaré aquí, ¿de acuerdo? Así que ahora, cada prueba se ejecutará en esto. Así es como refactorizas un código común en beforeEach. Pero también es antes, que se ejecuta solo una vez. No soy gran fan de un solo antes, ¿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, ¿verdad? Así que antes de continuar. Así que esta prueba añadió un par de elementos. Pero nunca confirmamos que la aplicación realmente funciona, ¿verdad? Nunca confirmamos que hay un par de elementos. Así que digamos que tienes un elemento. Quieres confirmar que hay el número esperado de elementos. Así que de nuevo, déjame abrir las DevTools. Inspecciona el elemento. Correcto. Y luego tengo una opción. Bueno, tengo clase de elemento de lista todo. Bien, así que nada especial, pero ¿por qué no? Así que diré, sci get, así que consígueme todos los elementos, elementos de lista con clase todo. Debería tener 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 un buen selector, ¿verdad? En aplicaciones de demostración, generalmente no es tan importante. Otra cosa es que debido a que esta aplicación es parte de la especie de estándar TodoMVC, trabajamos con lo que nos dan, ¿verdad? Como no reimplementamos esta aplicación. Lo bueno es que estas pruebas funcionan contra si vas a TodoMVC, ¿verdad? La cosa real, prácticamente todas esas implementaciones, puedes ejecutar nuestras pruebas contra esos TodoMVCs y luego las pruebas funcionan. Así que en una situación donde no controlas los selectores, tienes que trabajar con lo que se te da, ¿de acuerdo? Bien, así que ahora nuestra prueba falla porque nunca restablecimos los datos, lo cual haremos más tarde, ¿de acuerdo? Pero lo más importante aquí es que funciona ahora. Así que ahora continuemos.

Así que ahora que tenemos un par de tareas, queremos marcar un elemento como completado. Entonces, ¿cómo podemos hacerlo? Bueno, comencemos con esta prueba. Déjame hacerla un poco más pequeña para que tenga mucho sentido. Así que puedo hacer lo siguiente. Puedo tomar este código, bien, añadirlo aquí. Bien. Añadirlo aquí. Y de nuevo, ¿por qué, sabes, ingreso un par de estos? Si la prueba anterior ya creó, porque no quiero que una prueba dependa del estado en los datos dejados por otra prueba. Quiero que cada prueba cree todo lo que necesita para que pueda hacer todo. Bien. Vamos a refactorizarlo en un segundo. Así que la repetición es muy pequeña. Bien. Así que tenemos dos elementos, ¿verdad? Ahora queremos asegurarnos, y te animo a escribir junto, ¿verdad? Así que ahora queremos encontrar y marcar un elemento como completado. Entonces, ¿qué hacemos aquí? Bueno, encontramos los elementos de tareas. Confirmamos que hay dos de ellos. Luego tomaremos el primero. Así que primero es un comando que dice, si tienes una lista previa de elementos DOM, solo toma el primero, y tenemos que de alguna manera alternarlo, ¿verdad? O marcarlo como completado. Así que veamos cómo funciona. Así que tenemos un elemento. Si abrimos las DevTools, pero espera, si las DevTools no se abren por alguna razón, tenemos un problema con el bio-protocolo o algo, ciérralo y ejecútalo de nuevo. Entonces, ¿qué voy a hacer? Así que digamos, digamos, iré a la clase y especificaré el componente COM team. Usemos group para esto para que pueda ir al div y ahora puedo ejecutarlo. Mantengamos esto, debería abrir todas mis listas. Déjame eliminarlo. Bien, así que encontró dos elementos, tomó el primer elemento, elemento de lista, y luego encontró el elemento. Así que la diferencia entre find y get. Get comienza desde la parte superior, desde todo el documento y luego encuentra todos los elementos que coinciden con el selector. Find comienza con un elemento anterior. Así que no puedes simplemente decir un sided find porque no hay un elemento padre. Pero si tienes un elemento anterior, en este caso, lo tienes. Cuando te devuelve solo un elemento encontrado con el selector. Correcto, así que en nuestro caso, tomamos este gran elemento de lista y dentro, encontramos un elemento con clase toggle. Bien. Y diré clic. Bien, así que encontró el primero, encontró el toggle y luego hizo clic. Ahora una pequeña cosa es que el elemento ya no es visible. Correcto, a veces especialmente casillas de verificación y bibliotecas de UI, tienen que ocultar elementos bajo otro o se vuelve visible solo al pasar el ratón, ¿verdad? Así que podrías ver estas cosas o si había un elemento y luego fue eliminado, se volverá no visible, ¿de acuerdo? Así que añadimos un par de elementos, confirmamos un número, completamos el primer elemento, fue un comando. Así que ahora tenemos que confirmar que realmente se muestra como completado. De nuevo, ¿cómo lo hace nuestra aplicación? Si miramos este elemento, podemos ver que la aplicación añade esta clase, completado. Así que después de hacer clic, queremos confirmar que este elemento ahora tiene la clase completado. Así que voy a copiar y pegar esto, así que vamos a encontrar nuestros elementos de nuevo, vamos a tomar el primero y escribiremos una afirmación. Así que debería tener clase completado. Y voy a copiar, así que de nuevo, este es nuestro chequeo al final, encontramos los dos elementos, encontramos el primero, y luego. Entonces, ¿podrías cambiar el debería después del clic mientras, así que piensa en esto, cuando encontramos el botón de alternancia, correcto, y si hacemos clic en él y luego debería tener clase completado, pero no es el botón de alternancia. Correcto, así que veamos qué pasa. Sabes, a menudo solo codifico, como si solo quisiera ver qué pasa. Bien. Así que falló, correcto. Y te muestra dónde elemento, correcto. Y te muestra tener clase completado y luego te muestra que era toggle, correcto. Así que no era, se añadió en un elemento padre. Así que podríamos potencialmente hacer clic y luego decir padre, correcto, como volver atrás. No sé si va a funcionar o no, pero es debut. Así que queremos decir padre al, bien, así que todavía no. Así que podemos inspeccionar y ver qué elemento particular encontró cuando dice padre. Dice que no pudo encontrar el padre con clase, correcto? Así que en este punto, la prueba ya es un poco extraña. Déjame cerrar esto. Así que diría, no. Comienza de nuevo, como lo hicimos aquí. Donde fuimos de nuevo a la parte superior. Bien, así que 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, está bien. Marqué el primero como completado, pero en realidad marcó todos como completados. Olvidamos como la cosa del filtro. Así que queremos añadir una segunda cosa. Queremos decir que el segundo elemento no debería tener clase completado, ¿de acuerdo? Y la pregunta es, ¿cómo seleccionamos el segundo, verdad? Bueno, tenemos un comando especial primero, solo para claridad.

Hay otro comando equals, ¿de acuerdo? Donde puedes seleccionar, ya sabes, el primer elemento o el segundo, o puedes seleccionar desde el final con cosas negativas. Así que si queremos seleccionar el segundo elemento, usamos equals index equals uno, así que moveré esto. Bien, así que encontramos el primer elemento, ¿verdad? Y tiene la clase completed, 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 complicar demasiado esto.

Bien, así que respondí a esto. Ahora, ¿qué más hacemos? Así que así es como hicimos esto. Así que vamos a refactorizar el código. Ya estamos visitando la cosa antes de cada prueba, ¿verdad? Así que todas las cosas comunes que hacemos antes de la prueba están separadas. Otra cosa, estamos codificando la URL, lo cual definitivamente no recomendaría. Así que lo que podemos hacer en su lugar, y por cierto, al codificar la URL, nota lo que sucede aquí. No en este archivo. Si fuera... si fuera como una página HTTPS, verías que la página se recarga completamente porque Cypress no sabe qué dominio quieres visitar. Así que si es HTTPS, ¿verdad? Quieres poner esa URL en el archivo Cypress URL, Cypress JSON, ¿de acuerdo? Así que aquí es donde la URL, pero todas nuestras pruebas funcionan con, ¿de acuerdo? Así que ahora en mi archivo spec, puedo simplemente decir, visita como la raíz de base URL. Bien, esto es mejor por múltiples razones. Una, evitarás como con recarga en la visita al sitio que ocurre con sitios HTTPS. Segundo, podrás sobrescribir esta URL, la base URL en el vuelo. Así que lo más fácil, si, por ejemplo, estás ejecutando en CIS, ¿verdad? Y quieres probar tu sitio de staging, 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 base URL. Otra cosa que puedes hacer es usar variables de entorno en este caso. Así que puedes decir, Cypress base URL, ya sabes, HTTPS, QA, Cypress, o como cualquier empresa que seas. Así que esto nuevamente, cambia la base URL para que no la codifiques, ¿de acuerdo?

Nuevamente, ¿recomendaste no usar clases para la pregunta de selectores? Absolutamente, ¿verdad? Pero to do es más semántico. Pero nuevamente, es útil para el estilo también 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? Así que necesito crear elementos to do en cada prueba. Así que, bien, diré add item y texto y diré size, ¿qué es? Así que prácticamente copio lo que tenía en esta prueba. Y solo tendré que cambiarlo para decir texto, ¿verdad? Así que lo que sea que pase aquí, lo escribiré en el cuadro de entrada. Y ahora puedo decir first to do, second to do, y puedo eliminar estas cosas. Bien, funciona exactamente de la misma manera. Correcto. Y estas cosas son muy ligeras. Pero funciones individuales ahora, nota que dice texto cualquiera, puedo simplemente describirlas usando solo doc, add new to-do item. Y puedo decir param string text, ¿de acuerdo? Así que ahora IntelliSense está funcionando. Sabe que espera texto. Bien. Y porque typePress ya viene con todo, ¿verdad, necesario, puedes simplemente tomar esa función. Y estamos aquí mismo en el archivo spec, y luego podemos crear, ya sabes, utils. Puedes copiar eso, exportar. Y luego dentro de tu spec, puedes decir, import add item from utils. Perfecto. Funciona exactamente de la misma manera. ¿Verdad? Pero no necesito abstracciones complejas para todo. Tan pronto como veo, como, oh estoy usando la misma interacción con mi página, puedo crear pequeñas utilidades. Y nota incluso dentro de esta tarea, ¿verdad, que marca completado. Realmente solo abstraigo lo que es necesario. Como, no quiero abstraer esta cosa. No quiero crear cosas complejas encima de mi UI de página, pero decir, oh dónde está la clase toggle dentro de la vista, ¿verdad? Porque este es el único lugar donde probablemente alternaré ese botón. Así que no necesitaré esto en ningún otro lugar. Así que no abstraigas toda la página solo para poder probarla usando PageObject. Refactoriza tu código según sea necesario. Y recuerda, solo JavaScript. Bien. Codifiquemos juntos, eliminando un elemento, ¿verdad? Así que respondí la pregunta sobre recomendar PageObjects. No, recomiendo las pequeñas funciones como esta. Creo que son mucho más fáciles de razonar 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. Bien. Así que escribamos la segunda, o la tercera prueba, ¿verdad? Podemos eliminar un elemento. Bien. Añade un par de elementos, y confirmaré que hay dos de ellos. Nuevamente, tengo que eliminar todo antes de que pase. Así que Lindsay, estoy limpiando los elementos manualmente, ¿de acuerdo? Antes de volver a ejecutar las pruebas. Así que si quiero volver a ejecutar, aprenderemos cómo limpiar el estado de la aplicación en unos 15 minutos. Bien, así que 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. Nota que este botón, se vuelve visible solo cuando pasamos el ratón. Desafortunadamente, no hay hover en Cypress a menos que uses un plugin, porque es un evento nativo, lo cual está bien. No lo necesitamos. Así que, inspeccionaré mi marcado. Puedo ver que el botón tiene una clase Destroy. Bien. Así que, lo que puedo hacer, puedo decir, una vez que encuentres el primer elemento, encuentra el botón con clase Destroy y haz clic. Y después de realizar una acción, queremos agregar una afirmación para asegurarnos de que solo queda un elemento. Bien. Aún mejor, queremos confirmar que el primer elemento. Así que, 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 tendremos eventos nativos pronto y ya hay un plugin para hacerlo. Así que, confirmamos que el número de elementos es el mismo, pero tal vez eliminamos un elemento incorrecto. Así que, lo que podemos hacer es decir contains to do con clase first todo, second. Y, digamos que el primer todo no debería existir. ¿De acuerdo? Ahora, Vistas falla. Mira cómo no, se niega a hacer clic en un botón que es invisible. Así que, recuerda el comando side visit. Tiene todas estas afirmaciones integradas. Correcto, el servidor tiene que responder, tiene que responder con, como HTML 200.

En el evento de carga de la página tiene que dispararse. Entonces, Cypress, en cada comando tiene afirmaciones integradas. Por ejemplo, si quieres hacer clic en un botón, dice Cyclic falló porque el elemento no es visible. Entonces, imagina 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 a un puerto de vista, se asegura de que el elemento no esté cubierto por otra cosa, es visible, no está deshabilitado. Así que todas estas verificaciones están integradas. Y están tratando 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, como, simplemente usa force true. Bien, usaré force true.

Entonces, en onClick diré force true. Bien, ¿qué pasó aquí? Nuevamente, podemos usar el depurador de viaje en el tiempo. Entonces, encontramos dos elementos de lista. Bien, encontramos el primero. Encontramos el destroy. 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á haciendo, correcto, al backend. Vemos Li, to do, correcto, ahora tiene una longitud de uno. No vemos el primer to do, texto. Pero aún vemos el segundo to do. Todavía existe. Así que estamos confirmando que estamos eliminando el elemento correcto. Y nuevamente, Olga, entonces el hover es un evento nativo y Cypress no viene con eventos nativos integrados todavía, pero hay un plugin que simplemente agregas y puedes simular, como, clics reales. No simular. Usas el protocolo de depuración de Chrome para enviar el evento real a nuestra página, tal como un usuario real, así que donde hay un hover también. Bien, podemos extender esta prueba. ¿La aplicación devuelve el segundo to do, si recargamos, correcto? Si recargamos la página, como debería, entonces podemos decir, Cy reload. Perfecto, podemos ver lo que hay allí. Solo tenemos que confirmar, así que diremos que todavía debería haber un solo elemento. Así que lo interesante ahora es que puedes ver cuáles son todas las posibles cosas que podrían salir mal. No tienes que necesariamente escribir tareas exhaustivas para todo lo que podría salir mal. Haré, pasaré 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 que hay algún tipo de error y algo falla, entonces puedes agregar las pruebas según sea necesario. ¿Correcto? Y esta será tu prueba de regresión. Nuevamente, no, el mouse over no realmente reemplaza el hover nativo porque no desencadena los cambios de clase CSS. Como todas las clases CSS activas y enfocadas, y pseudo clases de hover, diría. ¿De acuerdo? Bien. Una prueba más solo 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é esta cosa. Y diré to do, y solo usaré esta variable que está aquí, K más uno. Y ahora solo confirmaré que para donde está el número esperado de elementos. Así que lo limpiaré. Así que aquí está lo que está bien. Agregaré cinco elementos. Cada elemento se llamará to do uno, dos, tres, cuatro, cinco. Y cuando confirme para nuestros cinco elementos, entonces la prueba debería pasar. Ahora, K no está definido. No es K, es N. Bien. Entonces, creo que Eric hizo esta pregunta, ¿dónde están todos los awaits? Nota que con nuestras pruebas no escribimos JavaScript asincrónico por así decirlo. Escribimos comandos y afirmaciones pero se ven como código sincrónico. No hay, digamos, como 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? Entonces, si declaras una función, sabes, como async, o si usas, digamos await aquí, es exactamente lo mismo que usas promesas. Así que si usas como await aquí, y sería exactamente lo mismo que agregar un elemento aquí y luego, y luego continuar, es más difícil de escribir, ¿verdad? Así que este sería el código equivalente. Aún peor sería... Esto está bien, ¿verdad? Esto está bien, pero ¿qué pasa aquí? Así que tengo esta afirmación. Primero, es un comando y luego ejecutamos la afirmación. Queremos asegurarnos de que hay 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. Esto es más explícito, menos confusión. Pero luego diríamos, está bien, digamos, espera que li tenga longitud, digamos n. Así que haríamos algo como esto. Así que estas son promesas, ¿verdad? Así que esto es exactamente lo mismo que decir, ¿a dónde fue esto? Como decir, consígueme, y luego obtendrás li y harás algo como esto. Así que estos son dos equivalentes. Aquí hay un problema. Si hiciéramos esta sintaxis await, ¿verdad? Estas son promesas. Para promesas en JavaScript, se ejecutan solo una vez. ¿De acuerdo? Solo una vez. Es un intento de un solo disparo. Así que si ejecutamos esto una vez, y obtenemos los elementos de la lista, bueno, adivina qué. Ninguno de estos, como si los elementos de la lista tuvieran un nombre diferente, ¿verdad, si tenemos que reintentar, no podemos volver a esta promesa y ejecutarla de nuevo. ¿De acuerdo? Así que si haces esto, usando async await, una vez que tienes esta lista de elementos, eso es todo. Si es la longitud incorrecta, si el elemento aún no está allí, si no tiene una clase, ¿verdad, como escribimos todas estas afirmaciones. Bueno, no puedes reintentarlo. Como todos esos spinners serían imposibles. Es por eso que cada ejecutor de pruebas tiene esta sintaxis extraña donde dicen como espera, sabes, o como await, como, así que tengo que tener como una sintaxis extraña para hacer la operación y también luego verificar las afirmaciones inmediatamente. Solo para evitar la cosa que await solo se ejecuta una vez. Así que los comandos de Cypress son bits completamente diferentes. Cuando se ejecutan, bien, así que digamos esta sintaxis, correcto, eso es como realmente simple. Escribes instrucciones a un humano, como agregar elemento, agregar elemento, agregar elemento. Lo que hacemos en su lugar, los encolamos, ¿verdad? Así que encolamos un comando, como, Cy get input to do, type. 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 se abre el navegador, y se ejecutan los primeros comandos que visito. Tenemos toda la lista completa de comandos antes incluso de abrir el navegador, lo que significa que si este comando, por ejemplo, falla, después de que se ejecute, podemos volver atrás, re-ejecutar de nuevo, como cosas mucho más inteligentes que Promises. Promises, ejecución única, somos un flujo reactivo de eventos donde podemos volver atrás y rehacer cosas porque sabemos que tenemos que reintentar esos pasos. Ahora mismo, si esta afirmación falla, volvemos al comando anterior y lo reintentamos. Probablemente deberíamos hacerlo para reintentar todo y así sucesivamente. Pero por eso no son promesas, ¿verdad? Y middle-news async away, porque entonces sería realmente, realmente limitado y esta sintaxis, como la escritura de pruebas declarativas, sería imposible. Lo cual también es la razón por la que es imposible asignar el retorno de un elemento. Entonces, digamos que hacemos esto. Y en lugar de esto, hacemos como Cy constant ele equals. ¿De acuerdo? Para cuando esto se ejecute, ¿verdad? En realidad no obtiene elementos. Solo programa el comando para ser ejecutado. Lo que significa que, aquí, li sigue sin definirse. ¿De acuerdo? Así que si realmente quieres el número de elementos, ¿verdad? Dirías eso. Esto es algo especial que hacemos, que se parece un poco a promesas, pero no lo es. Así que esto se ejecuta tantas veces como sea necesario, y luego pasa los resultados a ese comando. Por eso puedes simplemente decir, constant text equals get title. Correcto, porque cuando esto se ejecuta y hace la asignación, nada de eso está allí. De acuerdo. Así que son las 11:54. Veamos si tengo algo aquí. Oh, hay este comando llamado viewport, que es bastante genial. Déjame, puedes probarlo. Así que ahora mismo mi prueba, correcto, pasa. Como puedes ver, estoy ejecutando mi aplicación a 600 por 800. ¿Cómo se ve cuando el viewport es más pequeño? Puedes cambiarlo y decir viewport, y decir, no sé. Puedes dar dimensiones o puedes decir iPhone, o puedes decir cuatro. Y ahora así es como funcionaría tu aplicación. Así que en este caso, todo está bien. Hecho, hecho.

Entonces pregunta, ¿puedo hacer algo si el elemento está presente o no, verdad? ¿Puedo hacer algo como si obtengo, digamos, botón, verdad, de lo contrario, para eso lo llamamos pruebas condicionales. Así que si vas a los documentos y dices condicional y tenemos toda una discusión sobre por qué no deberías hacer eso. Nunca querrás no saber qué esperar en la página. Si tienes que hacerlo, te damos soluciones, ¿verdad? Pero siempre querrás ir desde los datos, ¿verdad? Y siempre saber qué esperar en la página, ¿de acuerdo?

Puedes ir desde lo que es una discusión sobre antes de que tomemos un descanso. Así que estas son pruebas unitarias, ¿verdad? Si alguna vez usas solo un MockA, también solo que obtienes tu función o código bajo la prueba, realizas una sola acción y luego tienes una sola afirmación. Y esto es importante porque si una prueba falla solo tienes realmente el nombre de una prueba. Así que si tienes múltiples afirmaciones y una de ellas falla bueno, es difícil entender usualmente qué parte falló y por qué porque no hay un depurador de viaje en el tiempo. Para pruebas de extremo a extremo como las que estoy mostrando puedes escribir pruebas más largas. Jennifer, intenta buscar en nuestros documentos este enlace. Bien, probablemente tengamos que hacerlo. Así que nota que esta es una prueba típica. Va por donde usas la historia, paso a paso y tiene múltiples afirmaciones porque cada comando usualmente tiene una afirmación incorporada. Si algo falla tienes video, tienes captura de pantalla puedes detener la prueba y comenzar a ejecutarla tú mismo y ver qué hace. Así que es mucho más fácil depurar una prueba larga y una prueba larga realmente corresponde a toda la historia. Otra cosa para pruebas más largas es hacer lo siguiente que es bastante genial y como mi cosa favorita para hacer después de que aprendí sobre ello. 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. Así que ahora mismo solo hizo la visita al sitio, ¿verdad? Y ahora puedo avanzar por cada comando uno por uno y puedo ver qué hace. Puedo abrir DevTools, ¿verdad? Puedo investigar qué hace mi aplicación versus. Así que la pausa del sitio es realmente buena porque te permitirá escribir tareas más largas, entenderlas, ¿verdad? Y luego usar el depurador de viaje en el tiempo para entender tal vez qué ha pasado también. Así que mi regla personal es si estás describiendo como 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 organizarlas por carpetas. Cypress puede ejecutarse en las subcarpetas. Y luego estábamos escribiendo como 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 característica en particular. Y puedes tener comunes antes de cada gancho, para que puedas configurar los datos para esa cosa en particular.

Así que Lindsay, si entiendo correctamente, la pausa del lado es un comando que puedes agregar a tu prueba para pausar en un lugar específico y luego avanzar por la prueba, ¿de acuerdo? Así que he mostrado cómo escribir una prueba que va por la interfaz de usuario de tu aplicación y ejecuta lo mismo que haría el usuario para agregar un elemento, eliminar un elemento, alternar, ¿verdad? Y luego asegúrate de que cuando agregues esos comandos, no solo agregues comando, comando, como verificar, obtener, escribir, hacer clic. También quieres asegurarte de agregar afirmaciones. 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 una clase o eliminarse una clase. No solo hagas acciones, varía acciones y afirmaciones.

Así que Eric, definitivamente recomiendo KitPitch, ¿verdad? Es, nota lo que, esto es lo que se necesita para realmente escribir una presentación de diapositivas de KitPitch. Solo escribes markdown como se muestra aquí. Correcto, solo separas diapositivas y luego incluyes imágenes en todo en VectorRepo. Y luego si usas su URL, el mismo archivo se muestra como una presentación de diapositivas. La cosa más simple. Ahora se están alejando, así que tendré que encontrar algo más. Así que yo, para mis necesidades y para la empresa, en realidad usamos Slides.com porque son increíbles, ¿verdad? Saben lo que están haciendo. Saben como la UI, la experiencia es simplemente increíble. Usan Cypress para probarlos, los usamos para mostrar. También pueden importar markdown. Así que probablemente solo, son las mismas personas detrás de reveal.js. Así que probablemente los cambiaremos porque git pitch se está alejando, pero fue bueno mientras duró. Así que creo que está bastante cerca. Probablemente podrás simplemente tomar el markdown y generar diapositivas un par. Eso, pero no sé, no lo he hecho todavía. ¿Las pruebas de extremo a extremo de Cypress reducen la importancia de la prueba de integración y viceversa? Así que la prueba de integración es una prueba donde tomas, digamos, un par de componentes e intentas ver su trabajo juntos, ¿verdad? Tal vez con algunas otras partes de las cosas. Así que, sí y no, ¿verdad? Pero comenzaría con pruebas de extremo a extremo porque esa es la única prueba que importa a 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 y demás. 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. Bien, continuemos.

Así que una sección realmente corta, selecciona un playground y Cypress Studio. Así que tengo esto como un capítulo muy corto, así que ni siquiera importa. No es importante intentar hacerlo tú mismo. Pero aquí está la cosa. Así que, estábamos discutiendo selectores. Uso elementos de DevTools, ¿verdad?, para encontrar el selector. Así que, por ejemplo, este input, incluso Chrome sugiere input con una clase nueva para hacer. Bien. Pero donde se abre, podemos abrir seleccionar un playground. Así que aquí está cómo funciona. Digamos, tengo esta prueba y necesito agregar, ¿verdad?, un elemento. Bien, entonces, ¿qué es este cuadro? Así que voy a hacer clic en este abrir selector playground. Y ahora, puedo simplemente pasar el ratón sobre los elementos y sugerirá. Así que, por ejemplo, mira cómo si uso data side, el ID de prueba, hablará de nuevo. Si no, elegirá, ya sabes, una clase. Así que aquí, una vez que elijo eso, incluso me dice el comando, puedo copiarlo y veamos, pegarlo aquí. Y puedo decir tipo, texto más enter. Así que así es como elegiría, ya sabes, un elemento. El problema con ese selector, ¿verdad? Así que, si, por ejemplo, intento seleccionar este elemento, no creo que tenga mucho sentido. Correcto, como este selector. Así que todavía es imperfecto, diría. Pero aquí hay algo más que muchas personas nos preguntan, como por mucho, mucho tiempo. Digamos que no tengo nada aquí. ¿De acuerdo? ¿Puedes simplemente hacer clic alrededor de la aplicación y ver si puedes grabar la prueba desde las acciones del usuario. ¿De acuerdo? Así que en Cypress 6.3.0, básicamente, como la semana pasada, lanzamos una característica experimental. Así que para que puedas ver esto, tienes que ir a un Cypress JSON y decir experimental studio true. Así es como controlamos los experimentos, ¿verdad? No los cargamos por defecto. Pero si lo habilitas en tu proyecto, entonces una vez que la prueba haya terminado, verás esto justo cuando pases el ratón sobre el nombre de la prueba. Así que agrega comando a una prueba. Así que haces clic en eso. Así que ahora esto se llama modo Studio, ¿verdad? Así que interactúa con tu sitio para agregar comandos de prueba. Así que quiero decir primero para hacer, enter, segundo para hacer, enter. Así que nota que en realidad interpreta correctamente los comandos y no permite todo, como solo unos pocos comandos son observados.

De nuevo. Nota que la prueba se ejecuta, está bien. Y esos comandos están justo aquí. Y nota que lo hace combinando primero para hacer y segundo para hacer porque tienen lo mismo, ¿verdad? Es el mismo elemento que seguí escribiendo. Así que puedes intentar eso, ¿verdad? Y puedes darnos tu opinión. Como, ya sabes, dónde está el enlace, todo. Pero lo único que diría, nota que cuando grabamos acciones, no había forma de grabar afirmaciones porque lo ves, ¿verdad? Y no tenemos idea si tú como humano, ¿verdad?, qué haces. Qué haces. Así que cuando grabes tus pruebas, asegúrate después de terminar de entrar y decir agregar afirmaciones. Debería tener longitud dos, 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é pasa, ¿de acuerdo? Estoy de acuerdo en que otras herramientas tienen extensiones de Chrome y complementos. Creo que es genial, ¿verdad? No estoy seguro si podremos satisfacer los requisitos de todos, ¿verdad? Para tener buenas pruebas, pero lo resolveremos.

Así que 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é lo más importante, 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 de integración en lugar de extremo a extremo? Solo razones históricas por ahora, ¿verdad? Probablemente deberíamos renombrarlo a extremo a extremo y dejar el nombre integración. Bien. Así que la próxima sesión, nuestro próximo capítulo es restablecer datos, ¿de acuerdo? Así que hicimos todo manualmente. Eliminamos todos los todos para que podamos escribir nuevos todos y confirmar para los dos de ellos.

Pero es un poco molesto. Bien, así que echemos un vistazo a la prueba número cuatro. Así que volvamos. Bien, así que nota, ¿verdad? pero todas las pruebas fallan porque ninguna de ellas restablece los datos. Entonces, ¿qué hacemos aquí? Bien. Así que los todos, los todos se obtienen del servidor, ¿verdad? Ahí es donde se almacenan. Así que visitamos el sitio. Ahí es donde los obtienen y así sucesivamente. Así que sabemos que los todos 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? Así que mira esto. Así que puedo ejecutar el POST usando curl o algo, ¿verdad? Así que ahora mismo, tengo todos los elementos. Así que desde la línea de comandos, puedo decir, Restablecer, y boom, están hechos. Así que hice una solicitud HTTP a un endpoint especial, que introduje solo con el propósito de restablecer los datos. Puedo hacer lo mismo antes de mi prueba. ¿De acuerdo? Tenemos un comando especial. Así que usualmente 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 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 la aplicación se abre, ¿verdad? Comienza, hace una solicitud get. Así que si no queremos elevar la condición donde restablezco demasiado tarde después de que la aplicación realmente lo pidió, lo que tenemos que hacer es, antes de visitar el sitio, hacemos una solicitud lateral. Así que la 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 los todos solo se establecen cuando quieras. Bien, así que veamos cómo es. Bien, así que ahora, nota 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, todo es lo mismo porque restablecemos los datos, ¿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 los datos JSON de to do MVC. Podríamos hacer eso, ¿verdad? Solo asegúrate de que estás escribiendo el archivo correcto. Puedes ver la ruta a 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 lo restablezcas, pero tienes una base de datos en el mismo host donde la aplicación está ejecutándose, ¿de acuerdo? Si quieres conectarte a una base de datos y tal vez truncar una tabla, ¿verdad? O verificar la tabla, tal vez durante la prueba con el registro es genial, puedes usar scitask. Eso es un fragmento de código JavaScript. Se ejecuta en Node. Eso significa que tiene acceso a tu sistema operativo, sistema de archivos, conectarse a una base de datos, ¿verdad? Y puedes usar scitask, llamarlo desde tu archivo de especificación y va al archivo de plugins, se conecta a una base de datos, consulta, 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 todos vacíos. Pero, ¿y si no quieres hacer eso, verdad? Tal vez quieras establecer los datos, ¿verdad? Y ellos inmediatamente inicializaron una situación más compleja. Bien, así que tengo este ejemplo aquí mismo. Así que voy a eliminar esto y voy a ejecutar esta prueba. Bien. Así que aquí está en esta prueba. Tengo un archivo de fixture, así que dos elementos. Bien, así que puedo cargar ese fixture, side fixture, puedo decir dos elementos. Ahora mismo nada interesante. Luego tengo que hacer esto. Puedo incluso llevarlos a una consola para asegurarme de que se carguen correctamente. Bien, así que estamos cargando el archivo JSON. Tenemos los elementos. Ahora puedo copiar este código y decir restablecerlo. Y solo enviar, pero los todos para cargarlo. Y ahora mira qué genial es. Si ejecuto la prueba siempre comenzará y ya inmediatamente 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 particular, antes de cada prueba. Y la prueba en sí será muy simple. Porque no tiene que, por ejemplo, agregar elementos, marcarlos como completados. Así que, por ejemplo, si quiero eliminar elementos, podría también restablecer la base de datos desde esta prueba, e inmediatamente ir a eliminar el elemento. Porque mis otras pruebas probarán si agregar los elementos funciona. Así que mis pruebas estarán separadas por características en lugar de combinar todo en una. 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 inmediatamente nunca tendrá que ser modificada porque no modificamos cómo eliminamos un elemento.

Si modificamos agregar elementos. Bien, así que cada prueba tendrá su propósito y no se superpondrán tanto. Respondiendo rápidamente un par de preguntas. Solicitud XHR y marcación de websockets? No, Cypress no puede hacerlo para websockets todavía. Así que, en el futuro tal vez. ¿Por qué restablecerías en un before-each en lugar de after-each? Veamos si tengo esto. Aquí está por qué lo harías usando before-each. Así que, déjame solo eliminarlo y solo ir aquí. Así que sugiero restablecer los datos usando before-each. También podríamos decir, cuando la prueba termina, se limpiará después de sí misma. Así que 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 limpiarse 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?

Y eso significa que introduces dependencias. Ahora, aquí hay otra cosa. ¿Qué pasa si la prueba se bloquea completamente? Como si el navegador se cayera, se bloquea completamente. 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 usando before-each, y nunca usar after-each. After-each está bien para algunas cosas extrañas. Cuando tal vez quieras cerrar la base de datos o enviar un mensaje, ¿verdad? Pero no asumas que funcionará, porque tu ejecutor de pruebas puede simplemente bloquearse y nunca hacer eso. Y así no quieres afectar otras pruebas. Por eso recomendamos usar before-each en nuestras mejores prácticas.

Así que responde esto... ¿Cómo puedo usar el restablecimiento dentro de before-each? Tal como mostré, simplemente ejecutas la solicitud dentro, antes de que realmente se necesiten los datos. Muy rápidamente, Karim, así que todas las diapositivas que estoy mostrando, ya están ahí. Son solo documentos markdown, así que están presentes, así que nunca tienes que descargar nada. Si miras todos los capítulos, todo lo que he mostrado, estos enlaces, son solo mostrando estos documentos markdown ya en este repositorio. Así que esto se quedará ahí para siempre. Una pregunta rápida de Dmitry, si quiero verificar la diferencia entre el valor antiguo y el nuevo valor, ¿cómo haría eso? Voy a hacerlo 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 enviaré esto. Este es un ejemplo de una prueba que agrega un elemento y luego verifica que la lista tiene un gran elemento. Puedes ver debido al modelo de canal de Cypress, si quieres obtener el número de elementos, haces un comando, usas then callback. 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 justo aquí. No es tan directo. Lo importante aquí es que este tipo de prueba donde no sabes qué esperar es anti-patrón. Deberías saber — especialmente si puedes restablecer los datos o como veremos en la simulación de red sabemos cómo detener la red — deberías preparar todo para que sepas exactamente qué mostrará la aplicación. Porque entonces puedes confirmar todo y no tener pruebas que tal vez no haya elementos y en ese caso hacer 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 la hemos mejorado enormemente. Así que, te gustará. Nuestra aplicación está haciendo llamadas de red para obtener los elementos, está haciendo llamadas de red para eliminar elementos, agregar nuevos elementos, etc. Así que queremos asegurarnos de que esas llamadas estén sucediendo y sucediendo correctamente. Entonces, ¿qué podemos hacer? Sugiero que todos abramos 05-xhr-spec. Así que, esto tiene un montón de tareas que ahora mismo están bastante vacías y no hacen nada. Y aquí, cerraré todo. Y iré a 05-xhr-spec. Así que, estoy preparado.

Bien, así que vamos a empezar con un problema. Y el problema es molesto. Así que, tengo esta prueba. Comienza con cero elementos, ¿verdad? Porque pensamos, sí, cuando la replicación se carga, 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 justo aquí. Entonces, ¿qué ha pasado? Bueno, aquí está el problema, ¿verdad? Y aquí es donde entender el ejecutor de pruebas y el comportamiento de la aplicación es importante. Piensa en la secuencia de eventos durante la prueba. Entonces, la aplicación se carga, hace una llamada al servidor, ¿verdad? Entonces, va y obtiene los elementos. ¿Qué hace mientras está obteniendo? Podría mostrar un indicador de carga, tal vez, pero básicamente no muestra elementos, ¿verdad? Así que nuestra prueba, inmediatamente, porque no tiene idea de qué tiene que esperar, muestra obtenerme todos los elementos. No debería haber ninguno, ¿verdad? Así que, no se encontraron elementos, ¡boom! La afirmación pasa, y la prueba se completa, porque no hay otros comandos aquí. Así que tan pronto como esa afirmación pasa, ¿verdad? , la prueba se completa. Así que la aplicación devuelve algunos elementos. Los muestra, genial, pero la prueba ya está hecha, así que nunca fallará. Puedes ver lo que pasa, ¿verdad? , si añadimos una espera incorporada. Por cierto, esto es realmente anti-patrón, pero si tenemos que hacerlo, tenemos que hacerlo. En Cypress, debido al retrace 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. Bien, así que lo haces usando CyGet y Afirmación, no usando espera. Espera puede esperar otras cosas. Así que ahora la prueba está fallando correctamente. Pero el problema es, no sabes cuánto tiempo deberías esperar. ¿Debería esperar 10 milisegundos? Eso parece funcionar, ¿verdad? ¿Debería esperar un milisegundo? Eso debería funcionar, ¿verdad? Pero la cosa es, 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. Así que 50, 150? Bien, eso es bueno. Tal vez solo 50. De hecho, ¿por qué no miramos cuánto tiempo toma esto? Podemos mirar esta solicitud de red. Tomó 25 milisegundos. Así que localmente, si nuestra prueba termina dentro de 25 milisegundos termina incorrectamente. Y si son 30, entonces realmente lo atrapa. Bien, la prueba fallida es correcta. Eso es lo que debería pasar. Cualquier cosa que pase es incorrecta. Pasa por la razón equivocada. Así que, al ejecutarse 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 ejecutarse en CI, a veces pasa a veces no. Porque está justo en el borde de ese umbral. Entonces, ¿qué hacemos? Bueno, seguimos aumentando el umbral y muy pronto cada prueba tiene incorporados 30 segundos solo por si acaso para evitar pruebas inestables. Así que, en este caso, primero que todo, puedes decir en Cypress si una prueba falla, puedes decir reintentos y digamos que se reintenta hasta tres intentos adicionales. Bien, así que diré, fallaré después de 100 milisegundos. Así que si falla, se reintentará una vez más. Así que si hay un poco de inestabilidad y no puedes resolverlo, hay reintentos de prueba incorporados que puedes intentar. Puedes intentar en Cypress open o solo en modo Cypress run. Eso está bien.

Queremos esperar a que la aplicación haga algo. Así que usualmente, nuestra aplicación se actualiza con dum UI. Así que lo que queremos decir, por ejemplo, obtén los elementos de la lista con la clase to do debería existir, y tener longitud uno. Así que realmente puedes escribir múltiples afirmaciones todas adjuntas al mismo comando usando ya sea should, múltiples shoulds o es un sinónimo y es lo mismo que should. Simplemente se lee bien obtén los elementos de la lista. Debería existir y tener longitud cero. Así que nota en este caso, hace las cosas correctamente porque primero, dice que debería existir en un DOM. Así que esto se encargará de esperar a que la aplicación realmente regrese. No puede ser indefinido, y luego decimos longitud cero. Así que puedes agregar más afirmaciones para esperar a que el DOM haga algo. Déjame eliminar donde intenta. Y la cosa es que nota cuando adjuntamos múltiples afirmaciones, todas tienen que pasar con el mismo elemento a la vez. Así que esto pasó, pero este siempre falló porque siempre hay dos en lugar de cero.

Está bien, lo responderé más tarde. Está bien, entonces podemos esperar a que el DOM se actualice. Pero en este caso, también sabemos que nuestra aplicación está haciendo esta solicitud. Así que lo primero que queremos hacer es asegurarnos de que esa solicitud haya terminado. Ahí es donde podemos empezar a trabajar con la aplicación. Así que no solo el DOM, no solo con el documento y el navegador y los elementos es observable. Eso es lo que podemos, desde Cypress consultar y así sucesivamente. La red es algo más que navegará el sentido que podemos observar desde Cypress, y esperar. Entonces, lo que queremos hacer cuando visitamos la página, queremos espiar las llamadas de red. Y tenemos un comando llamado Sciintercept donde puede espiar o detener. Lo más importante es asegurarse de que hagamos el espionaje o detención antes de que suceda. Lo que significa, si quieres espiar algo, correcto, entonces, no puedo simplemente interceptar. A esos. De hecho, lo eliminaré. Entonces, este es mi intercepto. Si hago esto cuando es demasiado tarde, ¿de acuerdo? Podría ser, ya sabes, atrapado, pero es una condición de carrera. ¿De acuerdo? Quieres interceptar. Quieres crearlo antes de visitar una página, antes de que suceda con seguridad, ¿verdad? Entonces, esta es la forma correcta. Puedes darle, ya sabes, a este intercepto un alias, para que puedas guardarlo como, digamos, cargando. Puedes darle un nombre. Y luego, puedes ver que realmente aparece en el registro de comandos. Entonces, puedes ver cómo sucede. ¿De acuerdo? Cuando creas esos interceptos, puedes ver esta nueva tabla. Entonces, estamos mirando todas las URLs, pero ve a la URL, todos. No estamos deteniendo, solo estamos espiando. Solo queremos saber cuándo sucede, ¿verdad? Y le dimos un alias, y sucedió una vez. Podemos ser más específicos y podemos decir, obtener. Porque agregar un elemento también irá a la misma URL, pero usando post, ¿verdad? Así que ahora, somos más específicos. Está bien. Y en lugar de esperar un segundo, una vez que tenemos un alias, podemos decir, espera lateral. Está bien, ahora falla correctamente. Porque esperamos a la aplicación, nota ahora cómo solía ser antes. Nota aquí, obtuvimos los elementos antes de que sucediera la red, pero al agregar espera, tenemos que visitar primero, esperar a que suceda 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 sobre cero elementos, elementos no sucedidos. Así que así es como puedes espiar una solicitud de red y asegurarte de que suceda, ¿verdad? Antes de asumir incorrectamente que puedes empezar a trabajar con la aplicación. Está bien, esto es bueno, ¿verdad? ¿Puedes también especificar parámetros de una solicitud de red en el intercepto? Puedes hacer lo que quieras, ¿verdad? Así que una buena cosa sobre esos interceptos de red, ¿verdad? No solo... Quiero decir, déjame solo mostrarlo, ¿verdad? Así que esto es correcto, ¿verdad? Asegurémonos de que inicialmente, ¿verdad? Y vamos a restablecer la cosa. Así que la solicitud primero restablece. Entonces, antes de ejecutar, nos aseguramos de que no haya datos. Así que cargamos los datos, ¿verdad? Y ahora la aplicación cargó los datos. Asegurémonos de que realmente, como devuelve la cosa correcta. Así que si haces clic en esta solicitud, puedes ver lo que Cypress ha hecho, ¿verdad? Como dice, esta es la URL que te interesa. ¿Verdad? Así que esta es esta cosa. Si haces clic en la espera, realmente imprime todo el intercepto. ¿Verdad? En una unidad de comando. Así que aquí 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... Así que mira esto. Estamos y lo llamamos ceder. Así que una vez que obtienes este comando, te da un gran objeto. Dentro del gran objeto, tienes la propiedad de respuesta y tiene cuerpo. Así que podemos decir que su cuerpo de respuesta debería ser igual a vacío. Así que esto es estamos espiando en el intercepto. Supongo que tal vez no lo es. Así que podemos profundizar con solicitudes de red y hacer afirmaciones contra cosas que estamos enviando o cosas que estamos recibiendo. La solicitud es un comando 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, está bien. Así que, por ejemplo, puedes tener puedes escribir tu propia lógica donde puedes inspeccionar la cosa que tu aplicación está enviando y agregar afirmación puedes modificar lo que tu aplicación está enviando. Así que 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 algo miras eso, haces una afirmación y luego respondes inmediatamente, así que detienes la red para que no vaya a la cosa. También puedes, una vez que la replicación responde, aquí déjame ver. Una vez que la aplicación responde, quiero decir, la aplicación envía la solicitud, la interceptas, permites que continúe va a la respuesta del servidor y ahora puedes modificar la respuesta o agregar afirmaciones. Así que, por ejemplo, si quieres asegurarte de que tu aplicación envía como mi texto de proyecto, puedes hacer eso, puedes modificarlo, ¿de acuerdo? Así que tienes control programático completo de lo que sea que envíe la aplicación al servidor y lo que sea que la aplicación reciba de vuelta. Así que es bastante poderoso. Así que si se envían múltiples solicitudes una tras otra, ¿verdad? Ya olvidé esta sintaxis, para ser honesto. Creo que es algo así, puedo hacer algo como esto. Como el segundo, no, no, no es esto. Olvidé, tenemos que buscar cómo obtener para separar la solicitud de una llamada separada. Así que si la inserción falla en tu intercepto, también debería fallar la prueba, ¿verdad? Así que, por ejemplo, aquí, si agregamos algo como esto, ¿verdad? y dices como esperar que el cuerpo de rec incluya, ¿verdad? Así que debería fallar, si no, entonces es nuestro error, ¿de acuerdo? Y si hay una manera de combinar múltiples esperas como promesa todo, creo que sí, pero tienes que mirar nuestros documentos. Así que puedes hacer algo como esto? E imagina dónde es como, no sé, post-it, como múltiples alias. Así que intercepto del sitio, como se supone que debe hacer, ¿verdad? Creo que sí, pero tienes que mirar la documentación. Está bien, ¿para qué más es útil el intercepto? Así que estábamos restableciendo los datos, ¿verdad? Cada vez antes de que se cargara la aplicación, lo solicitábamos. Quiero decir, solicitud, 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í que aquí es cómo funciona, está bien, un segundo. Así que algo está sucediendo aquí, tal vez así esto respondió con cuerpo, está bien. De hecho, no, esto es correcto, ¿por qué no carga? Así que si no hago esto, Veamos, Un segundo. Así que esto es raro, porque realmente 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 está haciendo solicitudes, queremos responder con una lista vacía. Así que veamos, podemos esperar. Veamos. Está bien, así que esta vez nuestra tabla de rutas dice que hay una llamada de la aplicación a un servidor. Eso coincide. Y lo simulamos.

Aquí hay algo más que podemos hacer. Está 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. Está bien. Así que la aplicación está intentando cargar to-dos al inicio. Interceptamos la llamada. Y en lugar de ir a un servidor, decimos, aquí está el archivo JSON. Aquí tienes. ¿Verdad? Muy conveniente. Ahora, en este caso, no estamos permitiendo que ocurra una prueba completa de extremo a extremo. ¿Verdad? Porque estamos interceptando la carga inicial de datos. Nuestras otras llamadas, ¿verdad?, van al servidor real, porque en realidad no estamos interceptando el boss. Podríamos, ¿verdad?, por ejemplo, podríamos decir, typefirst o como uno más, enter. ¿Verdad? Antes de hacer eso, podemos interceptar boss. Así que cada vez que hay un boss a slash to dos, podemos simplemente enviar un elemento vacío como nuevo todo. Así que veamos. Y tipo input nuevo todo, seleccionar. ¿De acuerdo? Así que ahora realmente tenemos dos interceptos. Y cada uno fue llamado. Y podemos confirmar. Podemos decir, Cywait, nuevo todo. Es la solicitud. Así que estamos obteniendo de lo que la aplicación está enviando, ¿verdad? Estamos obteniendo solicitud. ¿De acuerdo? Y, por ejemplo, tenemos un cuerpo. Entonces, ¿por qué no decimos, su cuerpo de solicitud debería incluir profundamente, porque es un gran objeto. Es un objeto. Y podemos decir título. Así que escribimos uno más. Y completado, falso. Así que estamos confirmando que cuando operamos la aplicación a través de su UI, ¿verdad?, y luego... la aplicación envía los datos esperados. Y podemos tener más afirmaciones aquí. Por ejemplo, podemos decir debería y... Así que esto es cuerpo. Otra cosa que podemos hacer es tener un debería llamar de vuelta. Y aquí es donde podemos hacer múltiples afirmaciones. Por ejemplo, esperar que el cuerpo incluya profundamente. Y siempre que lo pasamos aquí, título completado. De acuerdo. Y podemos decir esperar que el cuerpo tenga la propiedad ID. Está bien. Porque queremos asegurarnos de que estamos enviando ID desde el front end también. Esto también es agradable, porque realmente me muestra afirmaciones particulares, ¿verdad? Y es falso.

Así que preguntas rápidas del chat. ¿Cómo probarías tus estados de error con Cypress, probarías tu estado de error con Cypress con datos simulados? Absolutamente. Por ejemplo, si como mi aplicación maneja fallar al cargar, para hacerlo. Bien. Así que una cosa que probablemente ya hayas notado, cada capítulo aquí tiene una especificación con marcadores de posición. Correcto. Si estás aprendiendo Cypress y te gusta hacer ejercicios, realmente pasarías por las diapositivas e implementarías estas cosas consultando nuestra documentación. Cada archivo tiene una respuesta, cada capítulo tiene una respuesta. Así que para que puedas ejecutar las respuestas, porque ahora mismo no están aquí. Nota 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 nota que ahora todos los archivos están ahí. Así que nuestra sección es esta. Así que por ejemplo, la respuesta, ¿verdad? , especificación en este caso tiene todos los casos diferentes. Creo que este tiene que ser restablecido. Bien. Por ejemplo, ¿cómo carga mi aplicación los datos? ¿Qué hace mientras está cargando los datos? Bien, así que en este archivo de respuesta, hay una prueba que muestra cómo te aseguras, cómo ralentizas una solicitud de red para que puedas verificar la cosa de carga. Así que déjame mostrar esta prueba. Algo interesante. Antes de mostrar esta. Así que vamos a interceptar cosas. ¿Correcto? Vamos a interceptar GET TO DOs iniciales. Vamos a responder con cuerpo vacío. ¿Correcto? Pero vamos a ralentizar. ¿De acuerdo? Así que ahora esta prueba muestra claramente el indicador de carga. Y ahora esta prueba primero verifica 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 en la ecuación, ¿qué pasa en caso de error? Por ejemplo, si mi servidor por alguna razón responde con 404. ¿Correcto? Y dice que la prueba no lo permite. Y aquí podemos espiar el error de consola porque nuestra aplicación, lo único que hace, imprime un mensaje en un error de consola. Así que ejecutemos esta prueba. Bien. Así que nuestra aplicación imprimió el mensaje de error, y nuestra prueba simuló un estado de error y confirmó que está sucediendo. Bien. Otra cosa que sucedió, ¿cómo interceptas solo POS, sabes, con pruebas específicas? Sí. Una cosa que puedes hacer, y esto es útil para GraphQL también. Así que puedes crear un alias sobre la marcha. Así que déjame empezar con este. Bien. Así que este, 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 cuerpo, digamos nombre de operación, ¿verdad? Así que imagina si 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 asignaste dinámicamente. Así que esto funciona exactamente de la misma manera. Así que podemos esperar 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 por ese alias. Puedo obtener el alias más tarde y hacer afirmaciones de red sobre eso también. Con la función de interceptación, ¿no tenemos que iniciar CyServer? Así que solía ser que teníamos este método, CyServer, CyRoute, pero esos son súper limitados. Los duplicamos y serán eliminados en Cypress 7. Por eso en realidad se muestra en VS Code como duplicado, porque ya no los necesitamos. Así que, ¡adiós! Pero lo más importante, usa una sola interceptación. Por favor asegúrate de configurarla antes de la acción que desencadena solicitudes de red, para que no haya condición de carrera. Eso todavía es necesario. Así que, si necesitas un token JW, 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. then token. Mira nuestras recetas porque tenemos muchos ejemplos de uso de tokens y configuración de cookies y así sucesivamente. Si tengo muchas solicitudes dependientes por página, ¿cómo debería gestionarlas? Solo observa las solicitudes que realmente necesitas para la prueba. He visto a personas configurando 150 interceptaciones para cada prueba usando before each, porque... Luego tendrían las interceptaciones en caso de que las necesitaran. Cada prueba necesita un par de ellas. Pero siempre configuraban 150. Conoce lo que tu prueba requiere y solo configura lo que necesitas. Estamos a cinco minutos del inicio. Déjame asegurarme de que no he olvidado nada importante. Puedes hacer lo mismo. Tienes 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 puedes lograr solo pasando por la UI. Porque la UI podría tener verificaciones y validaciones que ni siquiera te permiten crear los datos que necesitas para el caso límite. Así que eso es prácticamente todo. Y quiero terminar con un par de cosas. Así que siéntete libre de mirar otras secciones, y otras diapositivas. Todo el contenido está ahí. Siéntete libre de mirar a través de ejemplos. Así que tengo cosas más complicadas mostradas en los archivos de respuesta. Siéntete libre de pasar por 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 podrían estar separados. Tienes que mirar nuestra documentación. Escribí un blog sobre esto. Esto es más complicado y quiero repasar esto.

Y lo más importante que diría es que esto es solo JavaScript. Lo que sea que haga que tu prueba sea legible, sigue usándolo. Correcto. Eso es prácticamente todo.

Para las pruebas de extremo a extremo en Cypress, realmente tratamos de imitar cómo el usuario humano usa la página, correcto. Por eso hay todas estas verificaciones, como para que los elementos sean visibles y accionables y no estén deshabilitados antes de hacer clic en un botón. También sugerimos que configures todo lo que necesitas para una prueba antes de que comience, correcto. Si necesitas datos específicos en una base de datos, configura los datos usando solicitudes o tareas del sitio. Si necesitas configurar cookies para que puedas iniciar sesión inmediatamente, obtén las cookies, configúralas, y luego la prueba estará iniciada. Si quieres interceptar una solicitud de red y tener un objeto de usuario con lista de proyectos de usuario y todos los datos, intercepítalo, configúralo, y luego tu prueba puede continuar desde allí. Puedes espiar y simular llamadas API que tu aplicación está haciendo. Esa es una de las formas en que puedes acelerarlo. Si tus operaciones complejas, costosas, llamadas costosas y duraderas a la API pueden ser detenidas, y luego la prueba va realmente rápido. Nota que aconsejé en contra de usar silo-wait, donde hay un período de tiempo codificado. Y en su lugar solo di, espera a que la aplicación actualice el DOM o haga una solicitud de red. Eso significa que tu prueba será tan rápida como tu aplicación. Pero nunca será lenta, o nunca esperará innecesariamente por algo solo porque lo quieras. Así que 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. Así que en mi ejemplo aquí, puedo acceder a mi app iFrame, eso es para mi aplicación, y puedo decir app. Así que 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. Cualquier cosa que puedas hacer desde las herramientas de desarrollo, puedes hacer desde la prueba de Cypress también. Porque la prueba de Cypress, mira, aquí es donde tu iFrame, donde tu aplicación se ejecuta. Este es el iFrame donde vive tu prueba. Pueden hablar directamente entre sí y pueden acceder a todo. Así es como funciona Cypress internamente.

Quiero agradecerte mucho. Fue 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 trato de responder las preguntas de las personas, generalmente publicando enlaces de vuelta a la documentación. Y si quieres saber sobre nuestros lanzamientos, los publicamos en GitHub y también tuiteamos sobre ellos en nuestra cuenta de Twitter, así que siéntete libre de hacer preguntas o seguir esa cuenta. Muchas gracias. Realmente lo aprecio, todos. Feliz prueba.