Mejores Prácticas para Escribir y Depurar Pruebas de Cypress

Rate this content
Bookmark

Probablemente conozcas la historia. Has creado un par de pruebas y, como estás utilizando Cypress, lo has hecho bastante rápido. Parece que nada te detiene, pero luego - prueba fallida. No fue la aplicación, no fue un error, la prueba fue... ¿inestable? Bueno sí. El diseño de la prueba es importante sin importar la herramienta que utilices, incluyendo Cypress. La buena noticia es que Cypress tiene un par de herramientas bajo su cinturón que pueden ayudarte. Únete a mí en mi masterclass, donde te guiaré lejos del valle de los anti-patrones hacia los campos de pruebas estables y siempre verdes. Hablaremos sobre los errores comunes al escribir tu prueba, así como depurar y revelar problemas subyacentes. Todo con el objetivo de evitar la inestabilidad y diseñar pruebas estables.

148 min
13 Dec, 2023

AI Generated Video Summary

La masterclass cubrió las mejores prácticas y depuración de las pruebas de Cypress, incluyendo errores comunes y cómo dirigirse a los elementos correctos. Se destacó el uso del comando 'contains' para asegurar pruebas estables. Se discutió la depuración y estabilidad en las pruebas de Cypress, junto con estrategias para evitar pruebas inestables y esperar las llamadas de API. Se enfatizó la importancia de la legibilidad de las pruebas y el uso de herramientas como Cypress Plugin Steps y Replay para la depuración. Se recomendó el comando de sesión en Cypress para optimizar las secuencias de inicio de sesión, y se exploraron las diferencias entre Cypress y Playwright.

1. Introducción a la Masterclass y Herramientas

Short description:

Bienvenidos a la masterclass. Soy Filip Hrits, un desarrollador de relaciones con desarrolladores en Replay.IO. Hoy, cubriremos las mejores prácticas y la depuración de las pruebas de Cypress. Proporcionaré información valiosa y responderé a sus preguntas. También tendremos desafíos prácticos para mejorar su aprendizaje. Utilizaremos VSCode y Cypress, y probaremos una aplicación de Trello. La instalación es sencilla: clonar el repositorio, npm install y npm start.

Bienvenidos a todos a esta masterclass. Gracias por elegir esta. Espero que sea realmente valiosa para ustedes. Acabo de compartir el enlace una vez más. Algunos de ustedes probablemente lo han visto. Este es el repositorio que estaré utilizando durante esta masterclass.

En primer lugar, mi nombre es Filip Hrits. Soy de Eslovaquia. Actualmente, estoy trabajando como desarrollador de relaciones con desarrolladores en Replay.IO. Replay.IO es un proyecto realmente genial, un producto realmente genial. Voy a hablar de él en la segunda mitad o en la parte final de la masterclass. Creo que encaja muy bien en el tema, que son las best practices y la depuración de las pruebas de Cypress , especialmente la parte de depuración. Pueden encontrar las cosas que hago en FilipHrits.com. Aquí es donde escribo mis tips de Cypress más a menudo. Soy un embajador de Cypress. Hago masterclasses, presentaciones, webinars, cursos y mucho más, principalmente sobre testing y sobre Cypress.io y ahora también sobre Replay.IO.

El formato de la masterclass. Oh, ignoren este hashtag. Lo siento, olvidé quitarlo. La masterclass se divide en capítulos, así que tendremos una visión general de los capítulos. Aprenderán lo que están a punto de aprender. Haremos una demostración. Durante la demostración, normalmente estoy programando, programando en vivo y explicando las cosas que hago. Durante ese tiempo, realmente no les aconsejo que intenten programar a la vez. Normalmente no ajusto la velocidad de explicación para que las personas puedan seguir programando, así que durante la demostración, pueden simplemente ver lo que estoy haciendo. Tenemos un desafío práctico. He preparado algunos desafíos para que los prueben. Veremos cómo va. Podemos decidir sobre la marcha si queremos dedicar algunos minutos al desafío práctico o si vamos a pasar al siguiente tema. Como mencioné, las preguntas y respuestas las estamos haciendo de forma continua. Pueden usar la ventana de chat si lo necesitan. Me aseguraré de responder a su pregunta lo antes posible y de la mejor manera que pueda. Muy bien.

En cuanto a las demostraciones, normalmente, esto es algo así. Pueden ver en la parte inferior, hay un enlace a un repositorio. También lo he enviado al chat. En el repositorio, encontrarán un proyecto de Cypress. Eso está en la carpeta de Cypress. Dentro hay una carpeta E2E. Allí, hay algunos capítulos. Creo que hay cuatro de ellos. Dentro, encontrarán un inicio de demostración. Este es el archivo que normalmente abro durante mi demostración. Luego, voy al estado final en el final de la demostración. Como expliqué, encontrarán el estado final en el final de la demostración. Todo lo que planeo decir está en las notas. Tiendo a improvisar, así que no todo está ahí. Encontrarán información valiosa así como algunos enlaces. En cuanto a los desafíos prácticos, normalmente la forma en que funcionan los desafíos es que abren el archivo challenge.js, lo ejecutan en Cypress, y miran la solución en challenge solutions. Si no están seguros sobre la solución, pueden echar un vistazo. De hecho, animo a la gente a hacer eso. No tienen que intentar descubrir todo por su cuenta. De hecho, si miran la solución y quizás la cambian un poco para hacerla suya, creo que esa es la mejor forma de aprender. Al menos lo ha sido para mí. De nuevo, lo que funcione para ustedes es probablemente la mejor manera. Muy bien.

Ahora echemos un vistazo a las herramientas que vamos a usar o más bien que voy a usar, pero que también vamos a usar durante esta masterclass. En primer lugar, VSCode. Ese es el editor de texto de mi elección, pero realmente no importa cuál usen, solo para que sepan cuál estoy usando. Luego, por supuesto, Cypress. Como esta es una masterclass de testing, voy a usar una aplicación que voy a testing, y esa es esta aplicación de Trello o un clon de una aplicación de Trello. La forma de instalarla y usarla es bastante sencilla. Me di cuenta como cinco minutos antes de la masterclass que en el enlace del repositorio, no había incluido el readme, así que lo siento por eso. Pero la instalación es bastante sencilla. Van al enlace. Clonan el repositorio con git, y luego hacen npm install y luego npm start. Eso es prácticamente todo. Cuando hacen el npm install, tendrán la aplicación disponible para ustedes. Si hacen npm start, esto va a ejecutar la aplicación. Ahora está funcionando localmente en localhost 3000.

2. Interfaz de la Aplicación y Errores Comunes

Short description:

Al abrir la aplicación, verás una interfaz vacía donde puedes crear tableros, listas y tarjetas. La aplicación también incluye una función de inicio de sesión. El código fuente y la base de datos de la aplicación se pueden encontrar en la carpeta de la aplicación Trello. Durante la masterclass, la base de datos se llenará automáticamente con datos de demostración. Ahora pasaremos al primer capítulo, que cubre errores comunes al escribir pruebas. Nos centraremos en dirigirnos correctamente a los elementos en la página y en entender las cadenas de comandos. Comencemos la demostración abriendo la interfaz de Cypress y ejecutando la primera prueba.

Cuando la abro, déjame encontrar una ventana de navegador. Aquí hay una, genial. Cuando la abro en localhost 3000, deberías ver algo como esto. Así es como se ve la aplicación cuando está completamente vacía, sin ningún data. Luego funciona más o menos como esperarías. Puedes crear tu primer tablero. Dentro de esos tableros, puedes crear listas de tareas. Así que tengo la lista uno, lista dos. En esas puedo crear tarjetas, que son como elementos de tareas pendientes, pero la forma en que las llamo es que la cosa azul es un tablero. La cosa gris de aquí es una lista. Esto es una lista. Y luego tenemos las tarjetas que son como elementos de tareas pendientes. Puedo hacer clic en esas, mirar en detalle esas tarjetas, puedo eliminar eso, copiar atributos, cosas así. Puedo marcar esto como completado. Cambiar la fecha. Funcionalidad básica. Creo que es bastante sencillo, pero a veces lleva un poco de tiempo familiarizarse con lo que está pasando en esta aplicación. También hay un inicio de sesión. Así que puedes registrarte e iniciar sesión. Vamos a estar testing eso. Y eso es prácticamente todo. Todo el código fuente de esta aplicación se puede encontrar en esta carpeta de la aplicación Trello. Ahí es donde vive la aplicación. Así que si quieres echar un vistazo, puedes hacerlo. Te lo recomiendo. También hay una carpeta backend que es responsable del backend de esta aplicación. Y hay esta subcarpeta data y un archivo JSON de database. Así que esto es, es exactamente lo que esperas. Es la database de nuestra aplicación. Así que la aplicación es súper, súper simple. Es básicamente solo un archivo JSON con algunos elementos en él. Así que tenemos nuestros tableros y tarjetas y listas. Y cada vez que creas algo en la aplicación, este archivo JSON se actualizará y así sucesivamente. Así que si quieres echar un vistazo a qué tipo de data está realmente dentro, aquí es donde encontrarás ese archivo JSON de database es el nombre del archivo. Muy bien. Una cosa más que hago en esta masterclass es que podrías ver un mensaje como este aparecer. Database fue barrida y sembrada antes de todas las pruebas. Así que esto es algo que hago en esta aplicación para hacer tu vida un poco más fácil y para hacer mi vida un poco más fácil, básicamente eliminando el problema de la gestión de data. Así que automáticamente siembro la database con los data que necesito para esa demostración. Podrías ver eso en los archivos de desafío también. Básicamente, cada vez que veas esto, podrías descubrir que lo que creaste momentos antes puede haber sido eliminado y luego cambiado por los data. Puedes hacer clic en este mensaje dentro de Cypress y mirar en la consola y verás lo que realmente fue sembrado. Así que te animo a hacer eso también. Sí, eso es prácticamente todo. Muy bien. Así que ahora que hemos sacado las instrucciones del camino, mantendré este enlace del repositorio en la parte inferior. Así que en cualquier momento que quieras, si quieres instalarlo, asegúrate de hacerlo. Ahora pasemos al siguiente capítulo al primer capítulo de hoy, y eso son errores comunes al escribir pruebas. Muy bien, vamos a aprender sobre los errores más comunes que he visto ocurrir al escribir pruebas o depurar pruebas o ayudar a otras personas con sus pruebas. Veremos cómo dirigirnos correctamente a los elementos en la página y cómo entender las cadenas de comandos. Muy bien, hagamos la demostración. Ahora, ya tengo mi aplicación en funcionamiento, así que lo que haré aquí es abrir otra terminal y hacer npx cypress open. Y estoy ejecutando la versión 12.7 en esto. Así que está un poco desactualizado, pero no demasiado. De hecho, creo que la última versión es 13.7, 13.8, algo así. Pero no hay tantas diferencias entre estas dos versiones, la versión 12 y la versión 13, así que creo que estaremos bien. Así que abramos eso. Organizaré un poco mis ventanas para que podamos ver cosas. Muy bien. Y abriré el inicio de la demostración aquí también. Muy bien. Déjame organizar esto un poco para que podamos ver todo. Muy bien. Así que en mi prueba aquí, en mi archivo spec, en realidad tengo dos pruebas. Así que ahora nos centraremos en la primera. Haré it.only. Guardaré esto. Y muy bien. Vale. Así que, en esta primera prueba, quiero hablar un poco sobre cómo dirigirse correctamente a los elementos.

3. Errores Comunes: Apuntando al Elemento Equivocado

Short description:

En esta sección, discutimos un error común de no apuntar al elemento correcto en una aplicación complicada. Demostramos este error utilizando una aplicación de botón simple con un atributo deshabilitado que se elimina después de dos segundos. Cypress realiza comprobaciones de accionabilidad antes de hacer clic en un elemento, asegurándose de que sea interactivo. Para eludir estas comprobaciones, se puede utilizar la opción force true, aunque no se recomienda. Podemos usar la consola para inspeccionar elementos y verificar los oyentes de eventos, lo que ayuda a apuntar al elemento correcto. Hacer clic en el elemento span antes de que esté habilitado se puede evitar utilizando el comando contains. Este comando ejecuta el clic solo después de que el elemento esté habilitado.

Entonces, este es un error que a menudo veo suceder cuando siempre hay una aplicación que es algo complicada y es difícil obtener el selector correcto. Lo que podría suceder es que podríamos no estar apuntando al elemento correcto. Y mientras el clic podría ir bien, podría haber otro problema, que me gustaría demostrar ahora.

Entonces, aquí, tenemos una aplicación que tiene un botón simple que dice, haz clic en mí. Y luego diremos que el botón fue clicado después de hacer clic en el botón. Entonces, prácticamente como una aplicación muy simple. De hecho, puedo mostrarte esa aplicación. ¿Cómo se llama? El botón. Bien. Botón HTML. Bien. Entonces, este es el, solo como el archivo HTML, esta es la aplicación que vemos aquí. Entonces tiene una etiqueta de estilo. Hay un cuerpo aquí. Y podemos ver que el botón tiene la propiedad deshabilitada. Y hay un span que contiene este texto de haz clic en mí. Y también hay un párrafo. Y ese párrafo es donde aparecerá el texto del botón fue clicado. Texto aparecerá. Entonces, la forma en que funciona es que tenemos un script aquí que agrega un oyente de eventos, y cuando hacemos clic en nuestro botón, el párrafo P se actualizará con el texto. Eso es todo. La parte importante es este set time out aquí. Entonces, básicamente tenemos este atributo deshabilitado en el botón. Eso básicamente va a desaparecer después de dos segundos. Entonces, eliminaremos ese atributo después de dos segundos. Entonces, de nuevo, esto es como una cosa muy, muy simple que está sucediendo aquí.

Entonces, veamos ahora qué podemos hacer con esto. Así que he comentado aquí. Este cy get button click. Y cuando guardo mi prueba así, puedes ver que el clic en realidad no va a ejecutarse de inmediato. Pero vamos a esperar un poco. Entonces, cuando vuelvo a ejecutar mi prueba, verás que se tarda dos segundos en que el botón sea realmente clicado. Porque lo que Cypress está haciendo es que está comprobando si este botón es realmente interactivo, ¿verdad? Entonces, si está deshabilitado, entonces no va a hacer clic en él. Y tan pronto como se habilite, Cypress hará clic en ese botón. Cypress tiene estas comprobaciones de accionabilidad en segundo plano. Probablemente ya has visto esto. Si estás escribiendo pruebas de Cypress, obtienes un mensaje de error que el elemento no era visible o estaba cubierto por otro elemento. La comprobación de accionabilidad sobre si una entrada o un botón no está deshabilitado es una de esas comprobaciones. Entonces, antes de que Cypress haga clic en cualquier elemento, va a comprobar si un usuario real podría hacer clic en él. Para eludir esas comprobaciones, podríamos ir a force true. Probablemente ya has visto eso. Tal vez lo has usado. Entonces podemos hacer un clic forzado, que está bien. Está permitido. Pero en realidad somos nosotros eludiendo esas comprobaciones. Entonces, estamos haciendo clic en algo en lo que un usuario real podría no poder hacer clic.

Una muy buena forma de comprobar si un usuario podría hacer clic en algo es usar la consola. Entonces podemos inspeccionar elementos ya que estamos dentro del navegador siempre que estamos testing con Cypress, y podemos apuntar a un elemento. Tal vez lo has usado, tal vez no. Ciertamente estaba bastante contento de encontrar esto. Hay esta pestaña de oyentes de eventos, ¿verdad? Entonces, cuando hago clic en ella, en realidad puedo ver qué tipo de eventos escucha este elemento, ¿verdad? Entonces podemos ver que tenemos un oyente de eventos de clic, por lo que este botón puede ser clicado. Y hay tantos eventos. Probablemente si estás trabajando con una aplicación más compleja, encontrarás que hay mouse sobre, mouse fuera, y qué no. Hay solo tantos, ¿verdad? Es una aplicación muy simplificada. Solo tenemos uno. Pero una buena forma de decir si estás apuntando al elemento correcto es ver este oyente de eventos en el elemento. Entonces, puedes ver si vamos, si apuntamos al párrafo, no vemos oyentes en absoluto, ¿verdad? Podemos ver que no hay ningún oyente de eventos en el elemento span también, lo que me lleva al punto de este. Veamos qué sucede cuando hacemos clic en el span. Si apuntamos no al botón, sino al texto que está dentro. Entonces, cuando hago eso, puedes ver que vemos que el botón fue clicado, pero fue clicado antes de que estuviera habilitado, ¿verdad? Entonces, cuando lo vuelvo a ejecutar, puedes ver eso de nuevo. Ups. Pasé el mouse por encima. Intentemos eso de nuevo. Puedes ver que vemos el mensaje de que el botón fue clicado incluso cuando el elemento estaba, cuando el botón estaba deshabilitado, lo cual en realidad no es realmente una buena cosa, ¿verdad? Entonces, estamos, de nuevo, es como el force true. Estamos haciendo clic en un elemento que no está activo aquí. El truco realmente agradable que podemos aplicar es que usamos un comando que realmente me gusta, y eso es, y eso es un comando que llama. Que dice contains, ¿verdad? Contiene un comando. Si usamos eso y apuntamos al elemento haz clic en mí. Entonces, no estamos apuntando por el atributo CSS, sino por el texto, lo que esto tiene es que tiene esta lógica adicional dentro de él. Entonces, cuando hago clic en, cuando guardo esto, verás que ejecutamos el clic solo después de que el elemento esté habilitado.

4. Uso del Comando Contains

Short description:

Al usar el comando contains, Cypress selecciona automáticamente el elemento interactivo que contiene el texto especificado. Esto asegura pruebas estables al evitar clics en el elemento equivocado, lo que puede causar inestabilidad en las pruebas. Procedamos a la siguiente prueba.

Y lo que esto hará es que cuando usemos contains y digamos que queremos seleccionar el interactuar con un elemento que contiene este texto de concurso, el comando determinará automáticamente en qué elemento hacer clic. Por lo tanto, no terminará haciendo clic en el span que está dentro del botón, sino que elegirá hacer clic en el botón en su lugar, que es el elemento interactivo allí. Puede parecer que estoy divagando sobre algo que realmente no es importante, pero hace una gran diferencia si quieres hacer tu prueba estable, porque hacer clic en el elemento equivocado podría, uh, podría causar inestabilidad en la prueba y puede causarlo porque, um, porque cuando no apuntamos al elemento correcto, podríamos desencadenar un clic en un elemento que, que no está listo. He visto que esto sucede muchas, muchas veces donde, uh, donde las pruebas serían, serían haciendo clic en elementos que, que no eran los que estaban escuchando esos, uh, esos eventos de clic y la prueba se volvería inestable porque el clic se activaría, pero, uh, no haría, uh, no haría nada. Um, bien, entonces pasemos a la, a la siguiente prueba.

5. Errores Comunes: Legibilidad y Cadenas de Comandos

Short description:

En la segunda prueba, estoy abriendo el tablero de Trello y mi prueba está fallando. El comando get está iniciando una cadena completamente nueva y encontrando cinco elementos en lugar de uno. Para evitar estos problemas, acostúmbrate a usar una consola para ver lo que el comando está devolviendo realmente. Podemos solucionar esto reiterando el filtro o utilizando find en lugar de get. Find solo busca dentro del contexto del comando anterior. CY contains es un comando dual que puede ser parte de una cadena para seleccionar elementos específicos.

Y este parece ser un problema de legibilidad, ¿verdad? Entonces, en la segunda prueba, estoy abriendo el tablero de Trello y mi prueba está fallando. Llegaré a por qué está fallando en un momento, pero básicamente en esta prueba, estoy visitando un tablero. Así que tengo algunos detalles del tablero aquí y estoy seleccionando una tarjeta. Así que el elemento blanco que estoy llenando, estoy filtrando el tercero. Entonces EQ dos es igual a dos, como si estuviéramos contando desde cero. Entonces uno, dos, tres, ¿verdad? Uh, o cero, uno, dos, más bien, estamos afirmando que debería ser visible.

Y luego queremos afirmar el texto de la tarjeta, ¿verdad? Y queremos asegurarnos de que el texto es judíos. Y como primera clase, esta prueba podría tener sentido, ¿verdad? Porque lo tenemos aquí y tenemos el texto de la tarjeta aquí, pero como puedes ver, nuestra prueba está fallando. Uh, y aquellos de ustedes que han estado usando Cypress ya lo descubrieron solo con mirar esta prueba, uh, por qué está fallando y tal vez mirando el error. El problema es que cuando hacemos este get aquí y estamos seleccionando un texto, en realidad no estamos seleccionando el texto de la tercera tarjeta que estamos filtrando aquí, pero el get comando está iniciando una cadena completamente nueva. Um, y va a ser, uh, y va a encontrar cinco elementos en lugar de uno. Así que podemos ver eso indicado aquí en la línea de tiempo también. Entonces, cuando obtenemos nuestro elemento, eso va a devolver cinco elementos. Uh, una buena manera de evitar estos problemas es acostumbrarse a usar una consola, ¿verdad? Así que cada vez que seleccionamos algo en Cypress, cuando hago clic en este elemento get, puedo abrir mi consola y ver en qué está devolviendo realmente este comando. Uh, esta es una muy buena práctica para hacer, como acostumbrarse a mirar en la consola. He visto a muchos probadores que, uh, que han escrito muchas pruebas en Cypress y no han estado usando esta consola, lo cual, uh, casi no tiene sentido para mí porque aquí es donde la información sobre lo que está haciendo el comando realmente vive. Uh, así que aquí puedo ver que esto ha producido, uh, cinco elementos que este comando get ha, uh, ha encontrado cinco elementos. Y la razón de eso es porque así es como funciona el comando get, ¿verdad? Siempre comenzará buscando dentro de toda la aplicación. Entonces, aunque esto es solo una cadena, de hecho, son dos cadenas, ¿verdad? Entonces podemos escribirlo así. Tendría más sentido para nuestros ojos, ¿verdad? Entonces, esto ahora se lee un poco diferente, ¿verdad? Estamos obteniendo todos los textos y queremos hacer una afirmación sobre eso. Entonces, la forma en que podemos solucionar eso, podemos reiterar de nuevo, ¿verdad? Entonces obtenemos los textos del coche y luego filtramos el tercero de nuevo, y luego afirmamos al texto, lo cual va a funcionar. Pero lo que también podemos hacer si queremos mantener la cadena larga o queremos mantener testing este elemento filtrado es usar find en lugar de cat. Ahora la diferencia entre un get y find es que probablemente ya sabes que el, que el find es de alcance, ¿verdad? Uh, find solo va a buscar dentro del contexto del comando anterior. Uh, la forma en que funcionan los comandos de Cypress, uh, puede que hayas oído hablar de esto, uh, es que tenemos tres categorías de comandos. Tenemos comandos de padres, comandos de hijos y tenemos comandos duales. Uh, si alguna vez has creado un comando personalizado, tal vez sepas sobre estas categorías, pero no se menciona, uh, tan ampliamente en la documentación de Cypress, lo cual encontré, uh, lo cual descubrí, uh, hace poco tiempo. Um, pero es sorprendente que no se mencione, uh, uh, no se mencione más. Básicamente, uh, un comando de padre es el comando que siempre comenzará con CY get. ¿Verdad? Entonces, uh, comenzamos una nueva cadena. Debería comenzar con CY get. Como ves, no siempre sucede de esa manera, pero la forma en que funcionan los comandos de los padres, uh, es que siempre comenzará una nueva cadena de comandos. Uh, entonces CY get o CY visit, serían buenos ejemplos de un comando de padre. Uh, luego tenemos comandos de hijos. Entonces esos comandos solo van a funcionar si están encadenados a otros comandos. Entonces, por ejemplo, este EQ, cuando queremos filtrar un elemento, entonces, por supuesto, necesitamos tener algo de lo que filtrar. Entonces CY get o algún otro comando necesita ir antes. Um, CY click, CY type. Esos son ejemplos de comandos de hijos, ¿verdad? Siempre los vemos en pareja con algún otro comando. Entonces, si obtenemos un elemento y luego hacemos clic en él, obtenemos un elemento, escribimos en él, uh, y luego también todas nuestras afirmaciones, ¿verdad? Debería, uh, uh, debería ser visible, debería estar marcado, lo que sea. Uh, estos son todos comandos de hijos. Uh, la tercera categoría es la, es la, um, lo siento, es la, es la comandos duales. Y un gran ejemplo de un comando dual es CY contains. En realidad puedo demostrar cómo funciona eso. ¿Verdad? Entonces, aquí, no estoy seguro de cuánto puedes ver eso, pero tenemos un par de tarjetas y tenemos un Marzo 0, 2022 aquí. Y luego tenemos Marzo 0, 2022 aquí. Entonces, ¿qué pasa si escribimos esto, así que hagamos Marzo 0, 1, 2022. Si guardo esta prueba y paso el ratón sobre estos contains, es un poco difícil de ver, pero está seleccionando esta primera tarjeta aquí. Uh, la razón de eso es que CY contains siempre devolverá un solo elemento. Um, pero, uh, ¿eso significa que no podemos seleccionar este otro elemento que está aquí? Uh, bueno, podemos hacerlo, si hacemos CY contains parte de una, uh, de una cadena, ¿verdad? Entonces, si yo, oops. Lo siento por eso. Entonces, si yo, uh, espera, ¿qué estoy haciendo? Quería, quería copiar este comando. Uh, no importa. Entonces, si hago que este contains sea parte de la cadena, entonces hagamos CY get, haz data, oops, uh, data CY list. Luego filtro el segundo. Entonces hagamos EQ uno y luego a contains, guardo mi prueba. Verás que el primer contains sigue haciendo lo mismo. Y el segundo está seleccionando el segundo. Probablemente no veas eso muy bien, uh, pero es verdad. En realidad, puedo hacerlo más visible. Si paso dos argumentos en este contains. Entonces, otro consejo para ti, contains en realidad puede tomar dos, um, argumentos y ese primero básicamente delimitará qué elemento estamos buscando que se supone que contiene un cierto texto. Entonces, si hago data CY card. Uh, sí. Vale. Entonces, digamos que quiero seleccionar un elemento data CY card que contiene este, uh, texto. Entonces mi contains va a devolver como toda la tarjeta. Entonces, en realidad no estamos reduciendo el alcance al hijo, solo al texto, sino que estamos seleccionando el elemento padre, el data CY card y contiene este texto. Por eso podemos ver eso. Uh, y luego el segundo contains seleccionará la segunda tarjeta.

QnA

Desafío Práctico y Uso de Índices

Short description:

Se dio a los participantes la opción de intentar un desafío práctico o pasar al siguiente tema. Se puso a disposición el repositorio para el desafío para su clonación. Se alentaron y respondieron preguntas, incluyendo una sobre cómo hacer clic en varios botones. Se discutió el uso de índices en las pruebas, con la recomendación de evitar depender de ellos a menos que se tenga control sobre los datos o elementos. También se destacó la posible inestabilidad de usar índices con selectores.

Um, está bien. Así que eso es, uh, eso es todo. Bueno, ahora me gustaría preguntarles, tengo algunos, uh, tengo algunos desafíos. Así que para ustedes, si quieren intentar, uh, si quieren intentar tener como 10 minutos para probar un desafío práctico que está conectado a este tema, uh, por favor denme un pulgar arriba, uh, con un emoji.

Y bien, tenemos como un pulgar arriba, dos, tres. Está bien. Bueno. Uh, está bien. Si prefieren seguir adelante, ¿pueden dar un pulgar arriba ahora? ¿O escribir un mensaje? Uno, dos, tres. Está bien. Cuatro. Está bien. Parece que tenemos un voto más para, para pasar al siguiente tema que hacer el desafío práctico. Uh, la buena noticia es que si copian esto, um, si intentan, uh, clonar este repositorio, ustedes pueden hacer el desafío por su cuenta. Así que este repositorio todavía está ahí. No voy a borrarlo. Uh, así que pueden probarlo. Lo siento, Vanessa. Uh, no vas a, no vas a perder la oportunidad de probarlo. Los desafíos todavía están ahí. Uh, así que si quieres hacerlo, entonces puedes, puedes, uh, puedes probarlo. Si tienen alguna pregunta, no duden en contactarme. Tengo un servidor de discord, uh. Si quieren unirse. Y pueden encontrarlo en mi página de inicio. Si tienen alguna pregunta, siempre estoy dispuesto a ayudar.

Uh, está bien. Así que vamos, uh, vamos a pasar al siguiente, uh, siguiente capítulo. Antes de pasar a esto, me gustaría, uh, me gustaría ver si hay alguna pregunta. Está bien. Si hay más de un botón, ¿cuál botón será presionado? Pregunta de Maxim. ¿Podrías quizás, uh, desactivar el silencio y hacer la pregunta? Porque no estoy seguro, a qué te refieres cuando solo obtienes botón. Está bien. Uh, cuando solo obtienes botón, así que cuando haces C Y vamos a hacer eso. Ver por qué obtienes y haces botón, entonces ver por qué obtener siempre va a, uh, encontrar todos los elementos que tienen la etiqueta HTML de botón. ¿Correcto? Así que si hay muchos de esos va a devolver muchos de esos, ¿verdad? Así que si hay dos va a devolver dos, así que si hay dos botones y vas a hacer clic, entonces Cypress va a fallar la prueba. La razón de eso, uh, en realidad se verá en el, en el mensaje. Y esa razón será bueno, Cypress no puede hacer clic en dos elementos a la vez. Así que puedes hacer, hay una opción para hacer, uh, múltiple verdadero, que básicamente haría, uh, uh, haría como un clic en serie en todos los elementos. Así que si tienes dos elementos, simplemente hará clic, clic en ambos. Uh, o simplemente puedes seguir adelante y seleccionar el primero o el último, o el que, uh, el que necesites, pero el comportamiento predeterminado sería que fallaría, uh, que fallaría. He aprendido que, um, usar, ya sabes, índices en tus pruebas. No es ideal. Así que por ejemplo, en lugar de decir, oh, debería esperar cinco tarjetas y hay cinco, ¿verdad? Um, tal vez dirían, ya sabes, o, o de las cinco tarjetas, la tercera tarjeta, quiero asegurarme de que la tercera tarjeta tiene esto en lugar de simplemente decir, quiero obtener esta tercera tarjeta, pero sin usar los índices. ¿Es eso a lo que también tiendes a inclinarte? O no sé cómo se cambiaría ese segundo en la línea 14 si fuéramos a seguir ese camino, en lugar de recoger ese índice.

Sí. Creo que este es un gran punto a plantear, el, uh, creo que el uso de índices va a ser dependiendo de cuánto control realmente tienes sobre los data o los elementos que están, que están en la página. Correcto. Así que por ejemplo, en esta aplicación, la aplicación Trello, tengo algunas tarjetas y las sembré antes de ejecutar la prueba. Así que sé que habrá cinco de ellas. Así que puedo, uh, uh, confiar en el índice. Si el design de la prueba realmente es, uh, uh, deseando tener esos cinco elementos, ¿verdad? Uh, si estás trabajando, digamos que estás testing un CRM, ¿verdad? Y quizás no tengas todo el control sobre la, sobre la aplicación. Entonces el uso de índices puede volverse más inestable. Uh, especialmente, he visto que eso sucede bastante es que, uh, las pruebas, uh, fueron diseñadas de una manera que, oh, simplemente obtengamos un elemento aleatorio de, de la pila. Y eso es, eso es, eso es simplemente abrir la puerta a la inestabilidad y a la flakiness de las pruebas porque es simplemente, puedes crear el clic, el elemento correcto, o puedes hacer clic en un elemento totalmente incorrecto. Y entonces el resto de tu prueba va a fallar. Así que en general, uh, alejarse de eso es una buena práctica, pero si tienes como un buen control sobre los, sobre los data, entonces podemos, puedes usar, uh, índices también. Otra forma de cómo se utilizan los índices es cuando tenemos un, um, cuando estamos tratando de encontrar un selector, ¿verdad? Así que en realidad puedo mostrarte vamos a encontrar un selector e incluso como el selector playground, que es una herramienta de aquí, cuando copio esto, te va a dar algo como esto, como, y niño y niño, lo que sea. ¿Correcto? Así que siempre que, uh, los índices son usados con selectores y están de alguna manera dependiendo de la estructura de la aplicación que de nuevo es, es abrir la puerta a la inestabilidad porque si por ejemplo, este niño en el medio cambiaría de alguna manera porque la estructura de la aplicación ha cambiado. Este selector, esta prueba básicamente fallaría en ese selector, uh, lo cual es, uh, lo cual no es bueno. Um, uh, así que sí, espero que esto fuera una especie de respuesta compleja a la, a la pregunta, pero, uh, uh, déjame saber si respondí eso, uh, a tu gusto, o quieres hablar de ello un poco más.

No, eso está bien. Entiendo lo que estás, estás diciendo. Lo aprecio. Gracias.

Mejores Prácticas: Selectores y Acceso al Repositorio

Short description:

Prefiero usar CY contains como selector. Confiar en el texto puede hacer que las pruebas sean más legibles. En situaciones sin mutaciones de lenguaje, el uso de selectores de texto es excelente. Para otras situaciones, se recomienda agregar atributos de datos personalizados. Tener acceso al código que se está probando es importante. Hacer que las pruebas sean parte del repositorio soluciona problemas de versionado y anima a los desarrolladores a mantener las pruebas actualizadas. Agregar atributos personalizados a los elementos interactuados permite ver fácilmente los cambios. El uso de la biblioteca de pruebas de Cypress o la biblioteca de pruebas proporciona selectores legibles y garantiza la presencia de atributos de accesibilidad.

No hay problema. No hay problema. Uh, está bien. Tenemos una pregunta más de Dania. Uh, espero estar pronunciando bien tu nombre. ¿Cuál es la mejor práctica a usar? Uh, ¿por qué obtener como selector en lugar de por qué contiene es la regla general? Está bien. En realidad, prefiero usar CY contains, y he visto, uh, a gente decir que, oh, no deberías confiar en los textos porque los textos son frágiles. ¿Verdad? Y no estoy de acuerdo con eso, o no estoy de acuerdo con eso, uh, uh, hasta cierto nivel. ¿Verdad? Entonces, por ejemplo, uh, echemos un vistazo a, a nuestra aplicación aquí. Este añadir otra tarjeta. Este será un elemento de añadir otra tarjeta para siempre. No vamos a cambiar el texto de esto. ¿Verdad? Así que podría seleccionarlo por texto, el botón de inicio de sesión será un botón de inicio de sesión para siempre. No vamos a cambiar eso. Si tienes un botón de enviar, ese texto tampoco va a cambiar. Así que confiar en un texto puede ser en realidad una mejor manera porque ahora cuando confío en el texto, la prueba es más legible. Realmente puedo decir lo que la prueba está tratando de hacer solo leyendo los comandos y leyendo qué, qué textos estoy seleccionando. Por supuesto, las cosas pueden complicarse más si estás usando una aplicación que tiene como varias mutaciones de lenguaje, uh, de esa manera usar texto probablemente no sea lo mejor. Pero si solo tienes un lenguaje o no planeas añadir más, entonces estás añadiendo legibilidad a tus pruebas al usar selectores de texto, uh. Así que creo que en general, eso es, eso es genial. Uh, en todas las demás formas, o en todas las demás situaciones, estoy animando a añadir atributos de data personalizados. Así que puede ser data, CY, data, test, data ID, cualquier atributo, uh, que añadas a tu aplicación. Creo que esa es la mejor manera. Tener acceso, uh, a tu código, creo que es realmente importante tener acceso a, al código que estás testing. Bueno, para los probadores, he visto, uh, muchos tipos de constelaciones de equipos donde, uh, los probadores ni siquiera tendrían permiso para mirar el repositorio. No creo que eso sea bueno. Si esa es la situación en la que te encuentras, creo que deberías luchar contra ella y realmente obtener acceso al código de la aplicación que estás testing. Esa es mi opinión. Uh, la razón de eso es que si haces que las pruebas sean parte de tu repositorio, en realidad vas a, uh, solucionar un problema de versionado, que es como cuando, uh, los desarrolladores actualizan la aplicación y tus pruebas ya no funcionan. Si los acoplas juntos y los haces correr en CI, en realidad vas a conseguir, uh, conseguir, uh, que los desarrolladores se involucren más porque ahora sus pruebas están fallando. Así que necesitan arreglar eso. Si no hay incentivo para, para que los desarrolladores, uh, mantengan las pruebas actualizadas, eso va a ser algo así como, ya sabes, los probadores siempre van a jugar a la captura con, con los desarrolladores, ¿verdad? Así que cada vez que, uh, actualizan algo, las pruebas van a fallar, oh, ahora necesitamos actualizar muchas pruebas, actualizarlas. Uh, pero en realidad estamos esperando, con este lanzamiento, así que no las actualices todavía. Es, es una pesadilla. He estado lidiando con este tipo de situación y realmente, realmente no es bueno. Así que cuando tienes acceso al repositorio, en realidad puedes añadir tus atributos personalizados a los elementos de, uh, con los que necesitas interactuar. Y creo que eso es bueno porque cada vez que esos elementos van a ser cambiados, cada vez que los desarrolladores se meten en el código y en realidad van a cambiar algunos de los, algunos de los elementos, algunos de esos elementos, ese cambio va a aparecer en la diferencia, ¿verdad? Así que, oh, en realidad estoy cambiando un elemento en el que, en el que las pruebas están confiando y los desarrolladores pueden ver eso, ¿verdad? Uh, si estás confiando en como un, uh, como una clase o ID o algo que, que sirve otro propósito, no solo el propósito de testing, creo que eso, eso va a ser más, uh, frágil. Así que recomendaría fuertemente añadir data, uh, atributos directamente en el código y hacer el código en sí mismo más probable. Gracias a eso. Uh, otro, uh, otro enfoque, uh, que hay, y yo, y yo estoy empezando a ser un gran fan de esto es usar, uh, Cypress testing library o testing library en general, que tiene estos comandos personalizados que, uh, pueden seleccionar elementos basados en ya sea como texto antiguo o el ARIA label y cosas así. Así que ahora cuando estás, cuando estás haciendo eso, en realidad estás comprobando dos cosas a la vez. Estás seleccionando un elemento basado en algo que es legible. Y la segunda cosa que estás logrando, te estás asegurando de que tu aplicación es, uh, tiene algunos atributos de accessibility, uh, presentes, lo cual creo que es, uh, uh, es bueno. Así que, uh, así que sí, de nuevo, respuesta muy larga a la pregunta corta. Espero que, uh, espero que te haya dado una respuesta satisfactoria.

Depuración y Estabilidad en las Pruebas de Cypress

Short description:

En esta sección, discutiremos la depuración y estabilidad en las pruebas de Cypress. Cubriremos la repetición de pruebas, el uso de la consola del navegador para depuración y la ejecución de pruebas múltiples veces. También abordaremos el problema de las pruebas inestables y cómo lidiar con ellas. La principal causa de inestabilidad en la prueba que estamos examinando es la carga aleatoria de tarjetas. Al pausar la prueba y observar el comportamiento de carga de la tarjeta, podemos obtener información sobre el problema y hacer que la prueba sea más estable.

Así que ahora, oh, genial. Así que ahora pasemos a la depuración y estabilidad. Uh, entonces, uh, hablaremos un poco sobre la repetición de una prueba, cómo debug una prueba usando la consola del navegador, y también cómo, uh, cómo pausar, uh, o ejecutar la prueba varias veces. Ahora saltamos. Uh, a la demostración. Empecemos la demostración aquí. Muy bien. Así que aquí tengo un par de pruebas, así que voy a ejecutar la primera. Y si recuerdo correctamente, si ejecuto esto un par de veces, esta prueba va a ser inestable. Sí. Vale. Así que ahora está fallando. Si lo ejecuto de nuevo, vuelve a fallar. Si lo ejecuto de nuevo, bien, ahora está fallando de nuevo. Así que intentemos ver si podemos hacer que pase. Muy bien, ahora está pasando.

Pruebas Inestables y Carga de Datos

Short description:

La prueba es inestable, causando fallos intermitentes. El proceso de carga de datos determina qué tarjeta se selecciona, lo que lleva a resultados inconsistentes. Pausar la prueba y usar la consola puede ayudar a identificar los problemas. Los comandos de Cypress se optimizan para la velocidad, pasando inmediatamente al siguiente comando una vez que se completa el anterior.

Y estaba pasando de nuevo. Uh, y ahora está fallando. Muy bien. Mi punto es que al ejecutar esta prueba un par de veces es que, sí, la prueba es inestable. Eso es una pesadilla. No nos gusta eso. ¿Verdad? Entonces, ¿por qué es inestable? ¿Qué está pasando aquí? Así que primero miremos las pruebas. Y tengo una función personalizada aquí que dice que los carros se cargan aleatoriamente, lo que probablemente te dirá un poco sobre lo que eso significa. Lo que probablemente te dirá un poco sobre por qué esto está fallando. Pero ignoremos eso por un momento. Y echemos un vistazo a nuestra prueba.

Así que estamos abriendo la aplicación. Estamos seleccionando un elemento del carro, luego filtramos el primero y hacemos clic en él. Correcto. Y luego dentro del detalle que tenemos aquí, ¿verdad? Así que ese es el detalle del carro. Estamos seleccionando el título del detalle del carro. Así que esto es, eso es este texto aquí. Que dice champú en nuestra prueba. Y queremos que tenga un valor de, de leche. ¿Verdad? Pero esto está fallando porque el texto es champú. Así que si lo ejecuto un par de veces, entonces probablemente podré encontrar un caso en el que esté pasando. Vale. Tal vez no. Hey, finalmente. Muy bien. Así que ahora está pasando. Así que ahora parece que, bien, esta vez funcionó. A veces funciona, a veces no. ¿Cuál es la razón de eso? Normalmente cuando ejecutamos nuestras pruebas en CI, lo único que podemos ver es el resultado. Podemos ver las capturas de pantalla, ¿verdad? A veces podemos ver el video, pero incluso con el video, puedes ver que esta prueba se está moviendo bastante rápido. Tal vez intentaste mirar la prueba e intentar ver cuándo está pasando, cuándo está fallando. Es realmente difícil de decir. Y este tipo de situaciones ocurren todo el tiempo.

Así que un comando muy poco utilizado en Cypress es un comando llamado, pausa. Así que puedes pausar tu prueba y ver qué está haciendo la prueba en un cierto momento. Así que lo que voy a hacer es después de seleccionar una tarjeta, antes de hacer clic, voy a pausar mi prueba para ver qué está pasando realmente. ¿Verdad? Así que guardemos mi prueba. Ahora se va a volver a ejecutar. Y ahora he pausado mi prueba y puedo ver, quiero decir, puedo ver prácticamente nada, ¿verdad? Puedo ver todas mis tarjetas cargando, así que tal vez intentemos eso de nuevo. Pero ahora puede que lo hayas visto, la cosa que pasa. Ejecutémoslo un par de veces. Es la cosa de cargar el carro, el carro se carga aleatoriamente. ¿Verdad? Así que si miras estas dos listas, verás que no aparecen al mismo momento, pero aparecen de alguna manera. Una lista aparece primero, y la segunda aparece después. Así que si lo ejecuto un par de veces, podrás ver que no es muy determinista. Se carga de forma aleatoria, como dice la función. ¿Verdad? Este es un código malvado, un script malvado que he añadido a mi prueba, que está causando eso. Está haciendo que mis tarjetas se carguen de forma aleatoria. Así que el problema aquí es que, dependiendo de si la primera o la segunda lista se carga primero, dependiendo de eso, voy a hacer clic en un elemento diferente. Así que mira lo que estamos haciendo aquí. ¿Verdad? Así que estamos seleccionando una tarjeta, luego seleccionamos la primera, y luego hacemos clic en ella. ¿Verdad? Entonces, ¿cuál es esta primera? ¿Cuál va a ser? Así que si todas las tarjetas no se cargan al mismo tiempo, lo que va a pasar es que si esta se carga primero, entonces vamos a seleccionar esta tarjeta. ¿Verdad? Pero si esta lista se carga primero, entonces vamos a seleccionar esta tarjeta. Así que nuestra prueba es inestable debido a cómo se está cargando la data. Pausar una prueba puede ayudarnos a averiguar qué está pasando y tal vez a examinar la prueba. Otra cosa que puede ayudarnos bastante es la consola. ¿Verdad? Así que echemos un vistazo. Esta es una prueba que pasa. Veamos la prueba que falla. Tenemos que ejecutarla un par de veces. Muy bien. Ahora estamos bien. ¿Verdad? Así que una de las cosas, bueno, antes de saltar a la consola, si solo uso la línea de tiempo y paso el ratón por encima y veo las instantáneas del DOM y veo lo que realmente está pasando en mi prueba, si paso el ratón por encima del primer comando que está aquí, puedo ver que estoy apuntando al elemento que está aquí, la tarjeta. ¿Verdad? Mientras la lista de comestibles todavía se está cargando. Así que Cypress, los comandos de Cypress están optimizados para la velocidad. ¿Verdad? La forma en que funcionan los comandos de Cypress es que tan pronto como el comando anterior termina de hacer su cosa, inmediatamente va a pasar al siguiente comando. ¿Verdad? Así que tan pronto como get encuentre el siguiente comando, va a encontrar el siguiente comando. Y eso va a encontrar al menos un elemento Cypress considera eso. Muy bien, hemos terminado. Encontramos los elementos.

Estabilidad de las Pruebas y Pruebas de API

Short description:

Agreguemos una afirmación para ralentizar nuestra prueba y prevenir la inestabilidad. También podemos usar el comando shoot para proteger la ejecución. Los comandos de Cypress tienen una relación interesante entre las afirmaciones y las consultas. En otra prueba, estoy reiniciando la aplicación, creando un nuevo tablero y probando el cuerpo de la respuesta de la API.

Pasemos al siguiente comando. Y eso es lo que realmente juega en nuestra contra en esta situación, porque estamos tratando de seleccionar un elemento diferente, tal vez llamándolo blaze en contra de eso es place en contra de nosotros. No es la mejor formulación porque de hecho, es simplemente cómo diseñamos la prueba. Si tenemos eso en cuenta, entonces podemos rediseñar nuestra prueba de una manera que va a ser estable. Así que una forma de hacer eso podría ser agregar una afirmación que realmente ralentice nuestra prueba. ¿Correcto? Tal vez podríamos decir que queremos tener cinco tarjetas y sólo entonces pasar al siguiente comando. Y esto, esto va a prevenir que nuestra prueba sea inestable. Así que no estoy seguro de cuánto ves eso, pero incluso si la prueba parpadea por un momento con la segunda lista cargada como primera, todavía vamos a obtener un resultado estable. Así que no importa cuántas veces ejecute esta prueba, va a pasar. Otra forma de resolver esto es añadir un comando shoot aquí. Así que tan pronto como seleccionemos el primer elemento, vamos a asegurarnos de que contenga texto. ¿Cuál es el texto que queremos leche, verdad? ¿Cuál es la leche? Así que cuando digo eso de nuevo, estamos protegiendo la ejecución. Nos estamos asegurando de que sólo pasamos al siguiente comando cuando realmente estamos listos. ¿Correcto? Así que estamos seleccionando el primer elemento y luego nos aseguramos de que el elemento tiene el texto, leche, ¿verdad? Así que aunque, incluso si la segunda lista se carga primero, en realidad vamos a vamos a pasar. Y la razón de eso es por cómo funcionan los comandos de Cypress. Así que mencioné tres categorías de comandos, padre, hijo y comandos duales. En realidad hay otra categoría, que o otra forma de dividir los comandos de Cypress, que es que es por lo que hacen esos comandos. Puedes encontrar eso en la documentation, de hecho. Así que echemos un vistazo. Aquí vamos. Aquí está. En el oops demasiado en la documentation, puedes encontrar que hay consultas, afirmaciones y acciones. Las consultas son todos los comandos que son responsables de encontrar elementos en la página. Así que hay, quiero decir, hay tantos, ¿verdad? Así que acabamos de usar get y contains y tal vez find. Pero todos los elementos de filtrado como los comandos de filtrado como EQ, first y last find y todos estos, son responsables de consultar un elemento. Uh, luego tenemos afirmaciones. Sólo tenemos dos aquí, shoot y end, que es sólo un LES para should. Y luego tenemos acciones. Así que hacer clic, hacer clic con el botón derecho, hacer doble clic y así sucesivamente. Así que la razón por la que estoy hablando de estos es que estamos usando dos consultas en nuestro, en nuestra prueba aquí, ¿verdad? Así que esto es una consulta. Esto es una consulta. Esta es una afirmación. Y esta es una acción. Y hay una relación interesante entre las afirmaciones y las consultas.

Depuración de Pruebas de API y UI

Short description:

Cypress repite consultas y afirmaciones hasta que la prueba pasa o falla dentro del límite de tiempo. Los comandos de acción no se repiten. La consola se puede utilizar para depurar e identificar errores en el cuerpo de la respuesta. En una prueba, reinicié la aplicación, creé un nuevo tablero y probé el cuerpo de la respuesta de la API. La prueba de UI también comprobó el cuerpo de la respuesta. El error no fue referenciar un elemento en el array, sino simplemente el cuerpo de la respuesta en sí. Después de hacer la corrección, la prueba pasará.

Uh, es posible que hayas visto que cuando, siempre que usamos el comando shoot y algo no pasa inmediatamente, pero hay como esta pequeña barra de progreso que se está moviendo a lo largo. La razón por la que hay una barra de progreso en, uh, las afirmaciones es que Cypress está de alguna manera repitiendo y tratando de asegurarse de que la prueba finalmente pasará. Correcto. Uh, y si nuestro, si los comandos que, uh, si el elemento que estamos testing, el texto no pasa, uh, la afirmación, correcto. La afirmación, correcto. Así que si el texto es algo más que leche, entonces lo que Cypress va a hacer con esas consultas es que las va a ejecutar de nuevo. Así que vamos, vamos, vamos tal vez como con un video muy lento, ¿verdad? Así que lo que sucede en milisegundos divididos es que encontramos tarjetas, ¿verdad? Cypress va a encontrar algunas en la aplicación y va a seleccionar la primera, ¿verdad? Y luego va a afirmar que contiene ciertos textos. Ahora en una situación en la que hemos cargado, donde la segunda lista se ha cargado como la primera. Así que el texto no es leche, sino champú en su lugar, ¿verdad? Entonces lo que Cypress va a hacer es decir, está bien, así que esto no está pasando. ¿Qué tal si ejecutas esto de nuevo? Así que vamos a la primera, consíguelos primero. Y luego vamos a ejecutar esto de nuevo y va a seguir haciendo ese bucle. Hasta que la prueba finalmente pase. Si no pasa dentro del límite de tiempo, entonces va a fallar. Así que sí. Así que esta es la relación entre las consultas y las afirmaciones.

Depuración y Retraza

Short description:

La depuración mediante la pausa y la observación de la consola puede ayudar a identificar errores. Uso de las solicitudes CY e interceptar para probar la API y la interfaz de usuario. Los registros de la consola revelan diferencias en los formatos del cuerpo de la respuesta. Corrigiendo las referencias de índice en la prueba de la interfaz de usuario hace que la prueba pase. El registro de la consola en la consola del navegador proporciona información valiosa. Retrace demuestra una prueba difícil de replicar. Ejecutar pruebas en un bucle puede ayudar a replicar fallos intermitentes.

Y creo que eso es algo importante que saber. También hay acción, la acción no se va a repetir nunca, ¿verdad? No queremos estar haciendo clic como locos en un elemento para ver que algo sucede. Pero la forma en que puedes trabajar con esas consultas y afirmaciones es que puedes hacer que trabajen a tu favor. Así que si no obtengo mi elemento en el primer intento, puedo intentar volver a intentarlo y solo pasar a la acción una vez que la afirmación está pasando. Bien. Así es como puedes debug pausando y mirando la consola.

Aquí tengo otra prueba y espero poder recordar qué, qué estoy intentando, intentando hacer aquí. Bien. Tengo un par de, un par de cosas pasando. Bien. Así que aquí tenemos una solicitud CY. Estoy reiniciando la aplicación para limpiar el estado. Luego estoy creando un nuevo tablero y le estoy dando un alias para una solicitud de tablero. Y luego, más adelante en la prueba, lo que estoy haciendo es visitar la aplicación y esperar a que se produzca esa llamada a la API. Y luego estoy testing el cuerpo y el atributo de nombre para que sea, para que sea igual a nuevo tablero, ¿verdad? Y luego también estoy haciendo una prueba de API aquí en medio, donde estoy tomando la solicitud del tablero. Así que eso es, eso es el tablero de aquí y estoy haciendo la misma afirmación, estoy haciendo que el nombre del cuerpo de la respuesta sea igual a nuevo tablero. Así que tengo dos pruebas aquí. Tengo la prueba de la API y tengo la prueba de la interfaz de usuario. Con la prueba de la API, estoy enviando la solicitud y testing el nombre del cuerpo de la respuesta. Y en la prueba de la interfaz de usuario, estoy observando la aplicación hacer la solicitud. Y luego estoy testing un nombre de cuerpo de respuesta también.

Así que no estoy seguro de cuán familiarizados están todos ustedes con la solicitud e interceptar, o más bien aquí, solicitud e interceptar. Básicamente, la diferencia entre estos dos, a veces esto, esto confunde a la gente, es que con las solicitudes CY, estamos actuando como postman o soap UI o lo que sea. Somos nosotros los que enviamos la solicitud a la database, ¿verdad? Con interceptar, somos más bien ojos. Abrimos la aplicación y observamos qué sucede, qué está haciendo nuestra aplicación. Ahora, lo que estoy haciendo en esta prueba es que estoy usando ambos para primero probar la API y luego probar la API de nuevo, pero esta vez solo estoy mirando la aplicación y ver qué está pasando. Así que estoy usando las mismas afirmaciones para ambos, y puedo ver que, bueno, está fallando. Algo no está, no está bien. Y debería estar bien porque básicamente estoy testing lo mismo, ¿verdad? Estoy tratando de afirmar el nombre del cuerpo. He enviado una solicitud, he creado el tablero usando solicitudes. ¿Por qué es, por qué no está pasando? La forma de cómo podemos, cómo podemos sortear eso es que podemos utilizar una consola como el nombre de la prueba dice, ¿verdad? Así que echemos un vistazo al cuerpo de la respuesta y veamos qué está pasando realmente aquí. Así que si hago un registro de consola y registro el cuerpo de la respuesta aquí y hagamos eso también aquí. Puedo ver qué está pasando. Así que hagamos un registro de consola del cuerpo de la respuesta y voy a abrir la consola en el navegador. Así que una cosa realmente importante sobre side press es que se ejecuta directamente dentro de los navegadores. Así que cuando hago un registro de consola, en realidad necesito abrir la consola del navegador en lugar de tal vez algunas otras herramientas de testing. Si haces el registro de la consola, imprimirán la información en el terminal. Así que voy a hacer un registro de consola. Imprimir la información en el terminal. Así que eso no es donde estamos testing. Estamos testing dentro del navegador. Déjame correr esto de nuevo. Bien. Vale. Así que ahora puedo ver que hay un par de registros de consola aquí. Puedo ver el primero que está en la línea 34. Así que 34, este es el primero. Esta es la prueba de la API y luego tenemos la segunda en la línea 43. Así que los números están invertidos y aquí podemos ver que el cuerpo, no parece ser demasiado diferente, pero hay una diferencia fundamental entre estos dos. Y eso es que el primero es un objeto y el segundo es un array de objetos. Así que de nuevo, imprimir en la consola puede revelar donde estamos cometiendo un error. Y este error es en realidad bastante pequeño y sería realmente difícil de encontrar, pero nos está diciendo donde está ese error. Así que lo que necesito hacer en esta prueba de la interfaz de usuario es que necesito poner un número de índice en los corchetes aquí. Necesito asegurarme de que estoy haciendo referencia a un elemento en el array y no solo al cuerpo de la respuesta en sí mismo. Así que cuando guardo eso, esto va a hacer que mi prueba pase. Ahora, la prueba tal vez fue un poco desordenada, pero el punto que estaba tratando de hacer es que imprimir información de registro en la consola del navegador puede ayudarte bastante. Así que sí, vamos a pasar ahora a la última cosa y eso es retrace. Vale. Así que esta es una prueba divertida. Déjame correrla. Básicamente, lo que estoy haciendo, ni siquiera estoy haciendo una prueba de interfaz de usuario. No estoy visitando. No estoy abriendo nada. Lo que estoy haciendo es generar un número aleatorio, y luego estoy esperando que ese número sea mayor que uno, que es una buena afirmación, ¿verdad? Pero básicamente, estoy adivinando. Así que si corro esta prueba suficientes veces, en realidad, la segunda vez fue suficiente, entonces mi prueba va a fallar. Ahora, la razón por la que hice esto es para demostrar una prueba difícil de replicar, ¿verdad? Así que si tenemos una prueba que está fallando una vez de cada 10 ejecuciones, y tal vez ya has tenido una situación así donde intentarías replicar un problema, pero casi nunca sucedería. Así que tal vez esto no es una vez en 10, sino una vez en 100 veces, entonces es un poco difícil encontrar un problema, ¿verdad? Y una forma de asegurarnos de que podemos replicar ese problema es que podemos ejecutarlo en un bucle. Así que puedo crear un bucle for, eso está totalmente bien, pero Cypress viene con un montón de herramientas realmente útiles. Y una de ellas es lodash. Esto es en realidad el cypress.

Evitando Pruebas Inestables y Esperas en las Pruebas

Short description:

Para evitar pruebas inestables, use la función times de lodash para ejecutar la prueba varias veces. Use el gancho after each para detener la ejecución de la prueba en el punto de fallo. La espera en las pruebas se puede evitar utilizando intercept para esperar a que finalicen las llamadas a la API. Es mejor dejar un pequeño tiempo de espera en la prueba en lugar de gastar tiempo y recursos excesivos tratando de eliminarlo.

Y lodash representa el paquete lodash que viene incluido en Cypress. Entonces, lo que puedo hacer, y me gusta bastante esta forma de hacerlo, es ejecutar la función de lodash que se llama times. Y esto tomará un argumento de cuántas veces quiero ejecutar algo y luego una llamada de lo que quiero ejecutar. Entonces, lo que voy a hacer es que voy a envolver toda esta prueba it only dentro de esta función de lodash para ejecutarla 10 veces, ¿verdad? Entonces, si guardo eso, puedes ver que ahora he ejecutado mi prueba 10 veces. Ahora, si la ejecuto 10 veces y falla, puedo volver atrás y averiguar dónde está, dónde está fallando. Ahora, esto es, por supuesto, como una prueba muy, muy simple y en un escenario del mundo real cuando tendré una prueba de extremo a extremo que está haciendo clic por todas partes, yendo de izquierda a derecha, de arriba a abajo. Lo que va a pasar si la ejecuto 10 veces es que en algún momento va a fallar, pero tan pronto como falla, simplemente va a seguir intentándolo, seguir ejecutando esa prueba una y otra vez. Y en ese punto, si intento detener la prueba e intento tal vez ir a la línea de tiempo y ver qué estaba sucediendo en un punto de interés donde eso empezó a fallar, podría ser demasiado tarde. Podríamos tener un problema. Y hay un truco realmente bueno que puedes usar. Y eso es este gancho after each. Lo tienes en las notas, lo tienes en el repositorio, pero este es un truco muy útil. Entonces, lo que esto hará es que si una prueba falla, entonces este es un gancho after each, ¿verdad? Entonces, esto echará un vistazo a la prueba que acaba de ejecutarse y si la prueba falló, va a hacer esta función eval. Esencialmente, lo que esto está haciendo es que va a tomar esta cadena que está adentro y tratar de ejecutarla como un código. Aparentemente, esta no es una forma muy segura de hacer las cosas, pero en este caso, no estamos haciendo ningún daño aquí. Entonces, lo que estamos haciendo aquí con esta ventana top document body query selector, blah, blah, blah, es esencialmente estamos haciendo clic en el botón de detener que va a aparecer aquí cuando ejecuto la prueba. Entonces, si la prueba falla, vamos a presionar inmediatamente el botón de detener. Entonces detenemos la ejecución de la prueba y eso significa que estamos deteniendo nuestra prueba en el punto donde estaba fallando. Este es un buen truco de depuración si estás lidiando con una situación de una prueba inestable de una en 50 o una en 20. Entonces, si ejecuto esto de nuevo, puedes ver que ninguna de las pruebas se ejecutó después de llegar a la prueba fallida. Entonces, normalmente lo que sucedería es que tendríamos nuestra aplicación abierta aquí y podríamos seguir examinándola. Veo a Tavi mostrando un emoji de corazón aquí. Sí, si alguna vez has lidiado con pruebas inestables, probablemente ya has lidiado con pruebas inestables y conoces el dolor. Asegúrate de quedarte hasta el final porque tengo algunos otros consejos para ti también. Bien. Esto es prácticamente todo para el capítulo. ¿Tenemos alguna pregunta?

Ahora pasemos al siguiente capítulo. Algo de lo que me gustaría hablarles que se inclina más hacia la parte de mejores prácticas y eso es esperar en las pruebas y cómo evitarlo. Entonces, si eres como yo y has estado escribiendo pruebas en Cypress, probablemente quieras evitar esperar y quieres, sí, simplemente no quieres tener CY wait en tu Cypress. Entonces, vamos a aprender sobre eso, cómo esperar las llamadas a la API, cómo esperar a que la interfaz de usuario llegue a un cierto estado, y también cómo cambiar un tiempo de espera y evitar usar CY wait. Entonces, vamos a saltar a la demostración y tengo un par de ejemplos que me gustaría mostrarles. Oops, inicio de la demostración en realidad. Bien, comencemos con la primera prueba. Ahora, esta es interesante porque tenemos cy-visit-port, estamos abriendo el puerto detalle, y aquí estamos tratando de afirmar que no hay tarjetas, ¿verdad? Entonces, data cy-card no debería existir. Lo que estamos obteniendo aquí en realidad es un falso positivo. Nuestra prueba está pasando, pero no debería. Realmente no debería porque estamos tratando de asegurarnos de que no hay tarjetas aquí, ¿verdad? Entonces, si me muevo a la línea de tiempo, obtendré la respuesta de por qué esta prueba está pasando. Puedes ver cuando paso el cursor sobre este comando get que en realidad estamos pasando esta prueba mientras los datos todavía se están cargando, ¿verdad? Entonces, esto no está bien, ¿verdad? Esto no es lo que queremos. Tenemos un falso positivo, esta prueba debería estar fallando porque tenemos tarjetas aquí y sin embargo, hemos escrito una prueba que debería estar afirmando que no hay tarjetas. Entonces, ¿qué hacemos? Probablemente deberíamos esperar a que se carguen esas tarjetas, ¿verdad? ¿Crees que dos segundos serán suficientes? Supongo que sí, pero ¿qué pasa si nuestra prueba es más lenta, ¿verdad? ¿Qué pasa si agrego aquí que las tarjetas se cargan lentamente? Este es el código malvado y las vamos a cargar en tres segundos. Bueno, ahora no es suficiente. Ahora estamos pasando la prueba de nuevo. Entonces, ¿qué deberíamos hacer? ¿Deberíamos agregar cuatro segundos aquí? ¿Será suficiente? Bueno, sí, lo será hasta que esto se convierta en cinco segundos y ves a dónde voy con esto, ¿verdad? Y esta no es la forma en que deberíamos abordar las cosas, ¿verdad? Entonces, ¿cómo nos deshacemos de esta espera, de esta acción, que no es una acción sino nuestra prueba simplemente no haciendo nada, simplemente sentada allí desperdiciando recursos. Bueno, esto puede sonar controvertido pero el consejo número uno es no evitarlo, simplemente déjalo allí. Y la razón por la que lo sugiero es que podrías caer en una trampa al tratar de eliminar la espera de tu prueba y la trampa es quemar todos tus recursos, todo tu día o tu toda la semana tratando de eliminar esto en lugar de pasar tiempo en algo que es más útil. Entonces, por ejemplo, si esperamos cuatro segundos en nuestra prueba, en una sola prueba, ahora estamos, ¿qué está sucediendo es que cuando esta prueba se ejecuta en CI durante cuatro segundos, no va a estar haciendo nada. Entonces, cuatro segundos en GitHub actions representan 0.0032 centavos. Sí, creo que sí. No recuerdo si eso era 0.0032 dólares o 0.0032 centavos. Creo que podrían ser dólares. Sin embargo, no es extremadamente, es extremadamente caro. Oh, espera, en realidad, eso es para un minuto. Entonces, eso ni siquiera es eso. Entonces, un minuto en GitHub actions es 0.0008 dólares, ¿verdad? Entonces, eso es un minuto. Entonces, está bien, pongamos esto en perspectiva. Estamos esperando durante cuatro segundos. Entonces, si ejecutamos esta prueba, no sé cuántas veces. 60 dividido por cuatro segundos. No sé qué es eso. No soy bueno en matemáticas. Básicamente, eso nos va a costar esa cantidad de dinero por, no sé cuántas ejecuciones. Básicamente, lo que estoy tratando de decir, no es tan problemático. Si, por otro lado, intentas eliminar esta espera y pasas un par de horas, tal vez un par de días, tal vez una semana, tal vez un mes tratando de eliminar esto, eso te va a costar a ti y a tu empresa mucho más dinero, ¿verdad? Entonces, si esta es la mejor solución que puedes encontrar ahora mismo, simplemente déjala allí. Está bien. No voy a decirle a nadie. Siéntete libre de dejarlo allí. Está bien. Bien. Pero ahora pasemos a la, cómo evitamos esta parte, ¿verdad? Entonces, en esta situación, cuando estamos obteniendo un falso positivo y necesitamos esperar a que finalicen las llamadas a la API antes de hacer nuestra afirmación, podemos usar intercept.

Intercept de Cypress y Espera de Llamadas a la API

Short description:

Intercept de Cypress permite capturar llamadas a la API y esperarlas. Se pueden utilizar expresiones regulares para coincidir con llamadas a la API específicas, y se pueden crear alias para esperarlas. Esperar varias llamadas a la API se puede lograr utilizando un array y coincidiendo con el número deseado de llamadas. Intercept también se puede utilizar para coincidir con todas las llamadas a la API o solicitudes específicas de GraphQL. La función intercept puede manejar las llamadas a la API definiendo cómo manejarlas, como proporcionar diferentes respuestas o retrasar la llamada. Al coincidir con las solicitudes de GraphQL, se puede inspeccionar el cuerpo de la solicitud para determinar la coincidencia deseada. Se pueden crear alias para solicitudes específicas de GraphQL para esperarlas en la prueba. Coincidir con las solicitudes de GraphQL puede ser más complejo debido a la estructura de la URL y la necesidad de inspeccionar el cuerpo de la solicitud. Se pueden encontrar ejemplos e información adicional en la documentación.

Si estás utilizando Cypress, probablemente hayas oído hablar de intercept. Es una forma de capturar una llamada a la API y luego esperar a que ocurra. Así que si quiero obtener todas las tarjetas, ¿verdad?, entonces puedo usar una expresión regular. Y cada llamada a la API que tenga el método get y tenga la palabra cards en ella será interceptada. Así que voy a hacer un alias, lo llamaré cards. Y ahora, en lugar de esperar cuatro segundos, voy a esperar a que ocurran esas tarjetas. ¿Verdad? Así que si hago eso, voy a esperar una sola llamada a la API. Y ahora mi prueba está fallando, lo cual es bueno. Recuerda, en esta situación, estamos afirmando que no hay tarjetas y las hay. Así que esta prueba debería estar fallando. Además, si quieres esperar ambas llamadas a la API, puedes hacer un array y esperar dos llamadas a la API que coincidan con este matcher. ¿Verdad? Así que esperamos ambas y sólo entonces pasamos al siguiente comando. De nuevo, esto está fallando. Esto es bueno. Eso es lo que queremos en esta prueba. Hay otra forma de hacer coincidir esto. Acabo de recordar que si queremos esperar todas las llamadas a la API de las tarjetas, podemos hacer get cards, all. Y hacer una afirmación de que debería tener todas las llamadas a la API de las tarjetas. La afirmación debería tener una longitud de dos. Y de esta manera esperamos todas las tarjetas y luego afirmamos que hay dos de ellas. Así que cuando hago eso, creo que funciona, ¿verdad? Sí. Vale. Lo tenemos aquí. Así que obtenemos todas las tarjetas, esperamos que ocurran dos llamadas a la API. Y finalmente, pasamos al siguiente comando. Este es un pequeño consejo para ti. Si tienes varios de esos, entonces puedes hacer eso. Por supuesto, si quieres ser muy vago, tal vez quieras esperar todas las llamadas intercept, ¿verdad? Así que hagamos todas ellas. Entonces puedes esperar todas ellas y hacer la afirmación de que hay al menos dos. Ten en cuenta que cuando hago esto, cuando hago las tarjetas todas y hago una afirmación en la longitud dos, lo que va a hacer es que va a pasar al siguiente comando tan pronto como se cumpla esta afirmación, ¿verdad? Así que si hacemos una afirmación de que debería tener una longitud de dos, pero en realidad van a ser tres o cuatro de ellas, simplemente va a esperar a las dos primeras y luego pasará al siguiente comando. Así que si necesitas eso, entonces si necesitas hacer algo así, entonces tienes que ser consciente del número.

Otra forma de cómo puedes abordar eso si quieres esperar a que se hagan todas las llamadas a la API, puedes, creo que hay una longitud superior a. Sí, así que si la longitud es superior a dos, no me importa el resto, pero si es superior a dos, entonces eso es suficientemente bueno para mí y pasaré al siguiente comando. Ahora, cuando hice este intercept y la estrella básicamente coincidiendo con todas las llamadas a la API, esto no sólo está coincidiendo con todas las llamadas a la API, sino que está coincidiendo incluso con cosas estáticas. Así que podemos ver el documento. Vemos el script probablemente algunos archivos CSS, imágenes, todo eso. Esto está coincidiendo con todos los recursos. ¿Tienes una demo de esperar un GraphQL? Creo que es más o menos lo mismo porque GraphQL, si recuerdo bien, todas las GraphQL son solicitudes post, ¿verdad? Y luego la URL es graph.ql, ¿verdad? Pero luego necesitas coincidir con lo que el contenido de eso es, ¿verdad? Así que la forma de cómo puedes abordar eso es escribirlo un poco diferente. Voy a pasar un objeto y decir que el método es post. Oops, no reemplazar. La URL es slash GraphQL. Y luego, vale. Vale. Y luego no sé cuán familiarizado estás con lo que puede hacer intercept, pero puede hacer bastante. Básicamente, puedes pasar dos objetos. El primero está definiendo lo que queremos coincidir. Y luego el segundo está definiendo cómo queremos manejar esa llamada a la API. Así que tal vez podemos detener una respuesta diferente, podemos retrasar eso, podemos cancelar esa llamada a la API o lo que sea. Hay como una cosa de burla y manejo entero que está pasando en el segundo objeto. Pero también podemos pasar una función. Y esa función básicamente tomará toda la solicitud y puede cambiar cosas sobre la solicitud, ¿verdad? Así que la forma en que te acercarías a GraphQL, echarías un vistazo al cuerpo de la solicitud. Así que cuando una aplicación está haciendo una solicitud GraphQL, normalmente tendrás una solicitud post a la URL de GraphQL, y luego dentro de la carga útil, tendrás la información y qué debería, qué tipo de información estamos tratando de obtener de la API. Así que puedes escribir una lógica aquí, y digamos que quieres coincidir sólo con un GraphQL que está obteniendo recursos llamados boards, ¿verdad? Así que si el cuerpo de la solicitud, no sé, simplemente lo escribimos muy simplemente. Si eso incluye boards, entonces vamos a darle un alias, el alias de la solicitud va a ser board GraphQL, ¿verdad? Y podemos eliminar este alias. Y ahora podemos más tarde en nuestra prueba, podemos ver por qué esperar el board GraphQL, ¿verdad? Algo así. No tengo una demostración, pero esta es básicamente la idea general. La coincidencia de GraphQL es un poco más difícil porque todas las URL se ven así, ¿verdad? Es una solicitud post a GraphQL. Creo que incluso puedes hacer get, ¿verdad? No lo sé. En su mayoría con lo que trabajo es el post y luego el cuerpo de la solicitud define lo que queremos obtener. Así que esto significa que necesitamos trabajar un poco más para obtener el alias correcto. Y cuando tienes como 10 solicitudes de GraphQL, 10, probablemente tienes que averiguar cómo ¿Coincido? ¿Cómo encuentro la cosa que me interesa? Y básicamente escribirías una lógica dentro de esta función aquí. Sí. Bueno, avísame si necesitas aprender un poco más. No tengo mucha experiencia o trabajo con GraphQL, pero sé que esta es generalmente la idea. Encabezado de la contraseña, la documentación. Probablemente debería poner un ejemplo en sus documentos. Vale. Sí. Esperando. De eso es de lo que estamos hablando.

Esperando que los Elementos Aparezcan en el Método de la Interfaz de Usuario

Short description:

En esta parte, discutimos el método de esperar a que los elementos aparezcan en la interfaz de usuario. Exploramos el problema de las aplicaciones de carga lenta y la necesidad de esperar a que los elementos sean visibles. Podemos cambiar el tiempo de espera predeterminado del comando en la configuración de Cypress para permitir tiempos de espera más largos. Sin embargo, establecer el tiempo de espera demasiado alto puede aumentar significativamente el tiempo de ejecución de la prueba. Alternativamente, podemos establecer un tiempo de espera de comando personalizado para pruebas o comandos específicos. Es importante encontrar un equilibrio entre esperar a que los elementos aparezcan y evitar un tiempo de ejecución de prueba excesivo. Agregar un tiempo de espera al primer comando después de que la aplicación se carga puede proporcionar información valiosa sobre la velocidad de carga y prevenir fallas inmediatas de la prueba.

Pasemos ahora a la segunda parte. Esperando que los elementos aparezcan, el método de la interfaz de usuario. Muy bien. Vale. Entonces aquí está la situación. Estamos esperando que la aplicación muestre cinco tarjetas y nuestra prueba falla. Pero después de que falla, veremos que esas tarjetas aparecen, ¿verdad? Así que cuando vuelva a ejecutar esto, verán que estamos intentando, reintentando. No pudimos encontrar las tarjetas. Nuestra aplicación se está cargando un poco lentamente. Y luego, finalmente, esas tarjetas aparecerán. Así que nuestra prueba idealmente debería estar pasando, ¿verdad? Entonces, de nuevo, ¿qué hacemos si nuestra aplicación es lenta? ¿Podemos esperar? De nuevo, si esta es la mejor solución, probablemente sea la mejor solución, ¿verdad? Pero si no, lo que podemos hacer, y encuentro que este es el mayor problema cuando estamos cargando la aplicación, ¿verdad? Cuando abrimos la aplicación, normalmente si estás trabajando con una aplicación de una sola página, podrías descubrir que cuando la abres, desencadena como 30 solicitudes, ¿verdad? Y todo se está cargando y estás esperando a que todo se cargue y quieres empezar a automatizar. Así que lo que terminas haciendo es añadir esa espera y vamos a esperar hasta que todo esté cargado. Hagamos 10 segundos. Y sólo entonces pasamos a lo siguiente, ¿verdad? El problema con eso, como dije, nuestra prueba no está haciendo nada durante 10 segundos, lo que puede que no sea ideal. Pero como solución rápida, está bien. Entonces, ¿qué podemos hacer? Nuestra prueba va a fallar después de cuatro segundos. Esto es lo que realmente dice el error. Nos quedamos sin tiempo. Estuve reintentando durante cuatro segundos para encontrar este elemento, pero no pude encontrarlo. Encuéntralo así que fallé la prueba, ¿verdad? Así que cuatro segundos, pregunté en Cypress, ¿por qué son cuatro segundos? Y me dijeron, bueno, tres parecía muy poco, cinco parecía demasiado, así que nos decidimos por cuatro, que es una historia bastante divertida. Pero me gusta eso porque también me parece bien, incluso para mí, esos cuatro segundos. Sí. Pero lo que podemos hacer es que podemos cambiar este número, ¿verdad? Así que aquí tenemos nuestro código malvado que está haciendo que nuestra aplicación se cargue muy lentamente, o está haciendo que nuestras tarjetas se carguen muy lentamente. Nos lleva 10 segundos, así que esto no está bien. Si fuera, incluso si fuera cinco segundos, eso sería malo para nosotros porque sólo tenemos el tiempo de espera de cuatro segundos, ¿verdad? Y si has estado probando aplicaciones web modernas, sabes que cinco segundos no es tanto tiempo. Entonces, ¿qué hacemos? Bueno, hay un par de opciones. Podemos ir a la configuración de Cypress y cambiar el tiempo de espera del comando predeterminado, ¿verdad? Así que el tiempo de espera del comando predeterminado es una opción que podemos cambiar. Por defecto, si no establecemos nada, son cuatro segundos, pero podemos cambiar eso a seis segundos. Cuando hago eso, mi prueba va a volver a ejecutarse. Puedes ver que la barra de progreso se mueve un poco más lento, y luego estamos pasando, ¿verdad? Así que incluso si ponemos esto a 10 segundos, nuestra prueba va a, puedes ver la barra de progreso moviéndose un poco lenta, pero incluso en esta situación, nuestra prueba va a pasar en cinco segundos, justo después de que nuestras tarjetas se carguen. Y la razón de eso es que este tiempo de espera del comando predeterminado, esto es básicamente un umbral superior. Este es el límite superior de Cypress en cuanto a cuánto tiempo va a seguir esperando. Así que si estamos, de nuevo, Cypress está optimizado para la velocidad. Tan pronto como descubrimos que la cosa, tan pronto como el comando termina de hacer su cosa, pasa al siguiente comando, y lo mismo ocurre con nuestras afirmaciones, ¿verdad? Tan pronto como llegamos al último comando, nuestra prueba ha terminado, y estamos bien para terminar la prueba. Pero lo que no intentaría poner este número demasiado alto, y la razón de eso es que el límite superior también puede traducirse en cuánto tiempo tardará la prueba en fallar, ¿verdad? Así que imagina que tienes cientos de pruebas, y 100 pruebas pueden correr bastante rápido, ¿verdad? Así que si tienes, si esas 100 pruebas normalmente se ejecutan en como dos minutos, si tienes 50 pruebas fallidas, entonces va a tomar 50 veces 10 segundos, asumiendo que no están corriendo en paralelo y todo eso, pero va a alargar el tiempo que vas a obtener la retroalimentación de tus pruebas. Y va a tomar más tiempo en tu pipeline. Y esto puede realmente hacer una mella si tus pruebas están fallando mucho. Así que usar esta configuración global no es la mejor opción. Tenemos otras opciones. Así que en lugar de cambiarlo para todas las pruebas, digamos que tienes una prueba obstinada que está tardando un poco más. Entonces la forma de cómo puedes solucionar esto es que puedes pasar un objeto entre el nombre de la prueba y el callback que contiene nuestros comandos, y este objeto en el bloque it, puedes hacer eso en el bloque describe también. Esto va a definir opciones sólo para esta prueba. Así que si estás probando como una parte obstinada, muy lenta de tu aplicación, lo que puedes hacer es pasar un tiempo de espera del comando predeterminado aquí. Y puedes establecer eso a seis segundos aquí. Así que cuando ahora guardo mi prueba va a añadir ese tiempo de espera. Así que por defecto, tenemos cuatro segundos, pero sólo para esta prueba, tenemos seis y ha fallado. Y no sé por qué. Y hay algo malo que pasa con el navegador de Cypress. A veces me pasa eso con mi aplicación cuando está como parpadeando, como quizás acabas de ver, y necesito hacer un refresco duro comando shift R para refrescar todo el navegador. No sé por qué pasa eso. Simplemente a veces pasa. Así que esa es la razón de eso. De todos modos, volviendo a la explicación. He establecido el tiempo de espera del comando predeterminado a seis segundos sólo para esta prueba. Así que todas las demás mantendrán el predeterminado de cuatro segundos. Pero si tengo una prueba obstinada, puedo hacer eso. Muy bien. Puedo cambiar el tiempo de espera también a nivel de comando. Así que si paso ocho, un objeto de opciones en este comando get, cómo el tiempo de espera hace seis segundos. Guarda mi prueba. Y de nuevo, vamos a pasar. Sí. Oh, así que si hay un elemento obstinado al que necesitas esperar, entonces puedes hacer eso. Y es mejor que intentar añadir un CY wait porque CY wait simplemente va a detener la ejecución. Pero el tiempo de espera sólo está estableciendo el umbral superior. Y puedes ver eso como una especie de marcador de rendimiento. Así que si tu aplicación no aparece realmente o muestra el elemento interactivo en un cierto punto, entonces probablemente deberías fallar esa prueba. Así que recomiendo añadir este tiempo de espera al primer comando justo después de la visita después de que tu aplicación se carga porque obtendrás la información de si se está cargando lo suficientemente pronto y también no vas a fallar inmediatamente si tu aplicación tiende a cargar un poco más de esos cuatro segundos. Muy bien. Eso es el capítulo de espera.

Interceptar y Condiciones

Short description:

Al usar la interceptación, no estás simulando la llamada a la API, sino que le estás diciendo a Cypress que la observe. La solicitud llega hasta el servidor y vuelve sin cambios. Cypress puede tener su propio conjunto de herramientas para la simulación de red. Pasemos al siguiente capítulo sobre patrones y antipatrones, cubriendo las mejores prácticas en Cypress. Discutiremos cómo evitar condiciones en las pruebas, mejorar la legibilidad y acelerar el inicio de sesión. Una pregunta común es cómo manejar las condiciones en las pruebas, como lidiar con un molesto mensaje de aceptación de cookies. Podemos usar diferentes métodos para encontrar el mensaje de cookies y hacer clic en él si aparece. Sin embargo, este enfoque puede no volver a intentar el comando, lo que hace que la prueba falle si el mensaje no aparece de inmediato. Agregar una espera puede ayudar, pero puede ser necesario depurar para asegurarse de que se utiliza el selector correcto.

¿Tenemos alguna pregunta? Vanessa, adelante. Cuando usas la interceptación, es solo una señal normal de parada, ¿verdad? No estás simulando en absoluto cuando haces la interceptación. Cuando haces la interceptación y solo estás coincidiendo con la llamada a la API, entonces ni siquiera estás simulando. Solo le estás diciendo a Cypress, oye, estoy interesado en esta solicitud. Solo observa que suceda. Pero la solicitud llega hasta el final, llega al servidor. Volverá sin cambios. ¿Cuándo defines el segundo objeto, verdad? ¿Dónde lo tenemos? ¿Aquí, verdad? Entonces puedes empezar a simular. En realidad no estoy seguro de si está usando la señal para simular eso. Tengo la sensación de que Cypress ha construido su propio conjunto de herramientas para la simulación de red, pero no estoy completamente seguro. Vale. Muchas gracias. No hay problema. Gracias por la pregunta. Así que ahora pasemos al siguiente capítulo y eso es patrones y anti-patrones. Así que este es un capítulo más general sobre, de nuevo, como mejores prácticas en Cypress. Hablaremos de cómo evitar condiciones en tus pruebas, cómo mejorar la legibilidad y también cómo acelerar tu inicio de sesión. Así que pasemos a eso. Luego comenzaremos y abriremos lo mismo aquí. Comenzaremos. Bien. Muy bien. Muchas pruebas aquí. Así que comencemos con la primera y eso son las condiciones. Muy bien. Creo que esta podría ser la pregunta número uno que se hace en el canal de Discord, o tal vez es simplemente la más molesta. Pero la pregunta básicamente es así. ¿Qué hago si quiero añadir una condición en mi prueba? Así que si el elemento no aparece, quiero hacer esto. Y si el elemento aparece, quiero hacer eso. Y normalmente la razón de eso es que tenemos algún tipo de molesto mensaje de aceptar cookies del que necesitamos deshacernos. Y que a veces aparece, a veces no. Y necesitamos manejar eso de alguna manera porque se interpone en el camino. No puedes hacer clic en nada y eso es simplemente molesto. Así que la forma práctica de hacer eso es escribiendo algo como esto. Básicamente, estoy obteniendo el elemento del cuerpo y luego estoy usando diferentes métodos para encontrar el mensaje de cookies. Y luego si el mensaje de cookies está ahí, voy a hacer clic en aceptar cookies. Correcto. Y eso es prácticamente todo. Así que si el mensaje de cookies aparece, voy a hacer clic en él. Y eso es un problema porque si echas un vistazo aquí a lo que realmente está pasando, verás que aunque tenemos esa condición aquí, en realidad no está haciendo su cosa. Correcto. Así que intentamos hacer clic en aceptar cookies, pero cuando miramos la prueba, en realidad no estamos haciendo eso. Entonces, ¿qué está pasando? El problema con este enfoque es que realmente no obtenemos todas las bondades de Cypress que normalmente obtenemos con los comandos de Cypress. Correcto. Así que lo que estamos haciendo aquí es que estamos usando una función jQuery para encontrar un cierto elemento. Pero el problema es que esta parte, en realidad no está reintentando. Así que cada comandante, probablemente debería decir que la mayoría de los comandos de Cypress tienen una lógica de reintentos. Siguen intentándolo hasta que cumplen una cierta condición. Y si no cumplen esa condición, entonces la prueba va a fallar. Correcto. Pero en este caso, no estamos haciendo ningún tipo de reintentos. Y el problema con eso es, es que este mensaje de cookies en realidad va a devolver indefinido, devuelve cero. Correcto. No vamos a encontrar ese mensaje porque cuando abrimos nuestra aplicación, el mensaje no aparece inmediatamente. Así que de nuevo, estamos ejecutando nuestra prueba demasiado rápido. Y si añado una espera, ¿verdad?, vamos a esperar al menos dos segundos, si hago eso, entonces el mensaje va a aparecer. Y, vale, realmente esperaba que eso funcionara. Pero vamos, vamos a echar un vistazo en realidad a la consola. Vamos a hacer un poco de depuración aquí. Porque esperaba que esta vez funcionara, pero no lo hace. Así que, veamos por qué es eso. Tenemos objeto, tenemos longitud de cero, así que todavía no lo encuentra. Eso es interesante porque. El cuerpo aparece después de que esperamos el contenedor del mensaje de cookies. Oh, espera, necesito, probablemente solo estoy usando un selector incorrecto aquí. Tal vez mi, mi ejemplo entero se desmorona ahora. Vale. Ahora lo ha encontrado. Así que espero dos segundos. ¿Qué pasa si quito esa espera? ¿Va a seguir? Sí.

Manejo del Mensaje Fluctuante de Cookies y Legibilidad de la Prueba

Short description:

Para manejar la naturaleza fluctuante del mensaje de cookies, podemos deconstruir la aplicación y entender su comportamiento. Al establecer una cookie para indicar el consentimiento, podemos evitar depender de la aparición del mensaje. Las condiciones en las pruebas deben evitarse ya que pueden llevar a resultados diferentes y ocultar problemas con la aplicación. Hacer las pruebas legibles es importante para fines de depuración. Las capturas de pantalla pueden no proporcionar suficiente contexto, por lo que se puede utilizar un plugin llamado Cypress plugin steps para añadir anotaciones y mejorar la legibilidad.

Vale. Vale. Vale. Entonces mi punto se mantiene. Estaba usando un selector incorrecto. Sí. El problema es la forma en que se ejecuta esto, visitamos la aplicación y el mensaje de cookies aparece como un segundo después de que cargamos todo el documento. Así que cuando hacemos esto, no obtenemos la repetición. Esto resulta inmediatamente en indefinido o resulta en el elemento. Y si ese elemento aparece, hacemos clic en él. Pero si no lo hace, básicamente saltamos esta condición. Así que este tipo de configuración, es un poco inestable por design, ¿verdad? Entonces, lo que queremos hacer, de hecho, en lugar de manejar la situación de esta manera es deconstruir la aplicación y tratar de ver qué está pasando realmente cuando estamos haciendo esto, ¿verdad? ¿Qué pasa cuando aceptamos las cookies y cómo funciona la aplicación cuando aceptamos las cookies y luego no vemos ese mensaje de nuevo, ¿verdad? Porque una vez que aceptas eso puedes recargar la aplicación y el mensaje no aparece. Y la respuesta se puede encontrar de nuevo en nuestro querido amigo DevTools. Así que en el panel de la aplicación, puedes encontrar las cookies que se guardan en toda la aplicación. Así que una vez que aceptamos el uso de cookies, lo que pasa, y puede que necesitemos recargar, es que veremos la lista de todas las cookies que se enviaron y podemos ver que se concedió el consentimiento, ¿verdad? Así que cada vez que pulsas aceptar, algo se guardará en tus cookies. Y eso asegurará que cuando recargues la aplicación, no volverás a ver ese mensaje. Y la aplicación recordará que has aceptado, que has dado el consentimiento a la página para usar cookies, y no intentará molestarte de nuevo. Así que lo que podemos hacer en lugar de tratar de averiguar si el mensaje aparece o no, es tratar de poner esta cookie en su lugar para que lleguemos a una situación en la que como si ya hubiéramos aceptado eso, ¿verdad? Así que la forma de hacer eso es hacer set cookie y luego decir consentimiento y concedido, ¿verdad? Así que el primer argumento va a ser el nombre de la cookie que vemos aquí, ¿verdad? Y el segundo argumento es el valor de la cookie. Eso está aquí. Hay algunas otras opciones que puedes establecer si necesitas, pero si ahora guardo mi prueba, verás que ya no nos molesta el mensaje de cookies. Y puedes creerme porque cada vez que volvemos a ejecutar nuestra prueba, todas las cookies son eliminadas por defecto. Así que entre pruebas, Cypress en realidad elimina todo el almacenamiento local, cookies, almacenamiento de sesión, todo tipo de almacenamiento de navegador que existe. Así que sí. Así que mi consejo aquí es tratar de deconstruir y entender qué está pasando realmente y qué hace que el elemento aparezca y no aparezca. Y me doy cuenta de que esto puede ser un poco más difícil si estás lidiando con una situación en la que no tienes el control de los data. Así que ahora, estamos hablando de la lógica de la aplicación. Podemos deconstruir eso. Podemos echar un vistazo a eso, a cómo funciona eso y tal vez escribir nuestra prueba de una manera que podamos escribir nuestra prueba de una manera que tenga sentido, que configure nuestro navegador de una manera que se comporte de la misma manera que nuestro usuario registrado o nuestro usuario que ha aceptado las cookies. La parte más difícil es cuando tienes pruebas. Cuando tienes data que no está totalmente bajo tu control. Y allí, querrías tratar de hacer algunas condiciones en tu prueba. Pero en general, es un antipatrón. La razón de eso es que cuando tienes una declaración if else en tu prueba, lo que estás creando básicamente es que tu prueba es capaz de darte dos resultados diferentes. Así que lo que eso significa es que aunque tengas la misma configuración, puedes tener dos resultados diferentes y eso puede llevarte a no darte cuenta de que hay algo mal con tu aplicación. Otro buen ejemplo podría ser la prueba A-B testing. Tienes la prueba A, tienes la prueba B. Y tu prueba está escrita de tal manera que, OK, si aparece la versión A, entonces vamos a hacer esto. Y si aparece la versión B, entonces vamos a hacer eso. Y la forma en que vas a manejarlo es encontrando o no encontrando un cierto elemento. Bueno, el problema con eso podría ser que tal vez tu versión A está rota y tu prueba siempre termina yendo con la versión B. Esa prueba nunca lo va a descubrir porque simplemente va a volver a intentarlo o lo que sea y siempre va a ir con el camino B. Y tus usuarios mientras tanto, obteniendo la versión A tendrán una mala experiencia. Así que trata de evitar las condiciones, idealmente a toda costa. Esto realmente no es una cuestión de la herramienta, sino una cuestión del design de la prueba. Y deberíamos ser realmente buenos diseñando nuestras pruebas correctamente. Muy bien. Una cosa más aquí. En realidad, dos cosas más, pero pasemos a la segunda. Si tuviera que dar un consejo, déjame reiniciar esto. Si tuviera que dar un consejo general en tus pruebas sería hacer tus pruebas legibles. Creo que es realmente importante hacer tus pruebas legibles y no ignorar la legibilidad porque depurar tu prueba es en realidad la parte de tu día que va a ser manual, ¿verdad? Si tu pipeline de CI tarda 30 segundos más, está bien. El pipeline no se va a aburrir ni se va a cansar, pero tú podrías, ¿verdad? Especialmente si estás tratando de atrapar una prueba problemática y con errores. Normalmente cuando tu prueba falla en CI, lo que terminas teniendo es una captura de pantalla, ¿verdad? Y la captura de pantalla puede parecerse a esto. Tendrá tu aplicación y tendrá la última afirmación, tal vez el mensaje de error que se lanzó. Y esto está bien. Creo que Cypress lo clavó con esto, con capturas de pantalla automáticas y videos. Pero hay un problema con esto, ¿verdad? Y podrías verlo si comparas lo que vemos en el lado izquierdo aquí y lo que vemos en el lado derecho aquí. El problema es que, aunque vemos donde falló la prueba, realmente no vemos todo este contexto que está aquí. Así que no sabemos qué, desde la captura de pantalla, no vemos lo que la prueba estaba haciendo antes de que fallara. Y eso podría ser realmente, realmente, realmente importante, ¿verdad? Porque lo que nos queda es la captura de pantalla y tal vez el nombre de la prueba. Y como estaba escribiendo mis pruebas en mi trabajo anterior, caí en esta trampa muchas, muchas veces, ¿verdad? Encontré una captura de pantalla y pensé, no sé qué estaba tratando de hacer esta prueba. Así que la forma en que abordé eso es que creé un plugin. Así que creé un plugin por mi cuenta. Puedes encontrarlo en los plugins y directorio. Está en los comandos personalizados y se llama Cypress plugin steps. Así que cuando hago eso, cuando hago clic en eso, encontrarás este plugin hecho por mí. Y lo que hace este plugin es que añadirá un nuevo comando llamado CY step. Y esto añadirá anotaciones a tus pruebas, ¿verdad? En tus pruebas, ¿verdad? Así que tengo abrir página aquí, encontrar todos los colores primarios, seleccionar azul. Y si hago zoom en la página, en la imagen, verás que tiene estos pequeños resaltados para abrir página, encontrar color primario, seleccionar azul.

Cypress Plugin Steps y Anotación de Pruebas

Short description:

El plugin Cypress Plugin Steps numera automáticamente los comandos y recopila los pasos, proporcionando información valiosa en caso de fallos en las pruebas. Al anotar las pruebas con el comando de paso de Cypress, los desarrolladores pueden ver los pasos de la prueba en la captura de pantalla y en la salida del terminal. El plugin también permite dividir las pruebas largas en secciones y reiniciar la numeración. Para utilizar el plugin, instala cypress steps y añádelo al archivo E2E. Anota la prueba con descripciones de los pasos para mejorar la legibilidad y la depuración. Los pasos de la prueba se mostrarán en caso de fallos en las pruebas, proporcionando información sobre el escenario y las acciones realizadas. El plugin puede ser una herramienta valiosa para la depuración y la comprensión del flujo de ejecución de las pruebas.

Por lo tanto, realizará la numeración automática de esos comandos, mejorando así la legibilidad, ¿verdad? Pero la parte realmente importante es que realmente recopila esos pasos. Y si tu prueba... Vaya, supongo que esto va a abrir la captura de pantalla. Si la prueba falla, mostrará cuáles fueron los pasos de la prueba y qué estaba sucediendo antes de que la prueba fallara. Así que si anotas tus pruebas de esta manera, obtendrás mucha más información de la captura de pantalla.

También, puedes ver el escenario en el terminal porque ese escenario será añadido al mensaje de error que aparecerá en el terminal. Entonces, la forma en que, oh, y también hay una sección CY que añadirá este color verde por aquí y puedes dividir. Si tienes una prueba super larga, puedes dividirla en secciones y eso reiniciará la numeración.

Así que la forma de usarlo es bastante simple. Solo tienes que hacer npm install cypress steps. Creo que ya lo he hecho. Sí. Si miro en el packet.json, sí, aquí está. Aquí tenemos cypress plugin steps. Y la segunda cosa es que necesitas añadirlo a tu archivo E2E. Así que eso es soporte E2E. Soporte E2E. Ahí es donde lo importas. Y a partir de este momento, tendrás disponible el comando de paso de cypress. Así que la forma de abordar esto es que puedes anotar lo que está sucediendo en tu prueba. Así que esta primera prueba, la primera parte va a crear un tablero. Así que hagamos cystep crear un tablero. Luego vamos a añadir una nueva lista. cystep añadir nueva lista. Así que añadimos una entrada y luego hacemos cystep y hacemos añadir nueva tarjeta. Y después de eso, estamos abriendo los detalles de la tarjeta. Así que hagamos cystep una vez más. Una vez más. Abrir, vaya, abrir detalles de la tarjeta. Bien, así que ahora cuando ejecuto mi prueba, prácticamente todo va a ser igual. Oh, en realidad no, porque necesito eliminar todos los tableros. Vamos a ejecutarlo de nuevo. Bien, todo será igual, pero mi prueba fallará. Y puedes ver que tengo esta anotación. Así que incluso cuando intento debug mi prueba localmente, puedo ver lo que estaba haciendo la prueba, cuál era el escenario de la prueba. Y luego cuando falló, veré los pasos de la prueba impresos. Así que estaba creando un tablero, añadiendo una nueva lista, añadiendo una nueva tarjeta, abriendo detalles de la tarjeta. Y luego nuestra afirmación ha fallado. Así que veremos que el elemento no era visible. Algo no era visible. Detalles de la tarjeta, dataCYCartDetail. No sé qué... Oh sí, la afirmación es que no debería ser visible. Así que los detalles de la tarjeta en realidad aparecen. Así que esto va a fallar porque es visible. La afirmación debería ser visible, ¿verdad? Necesito reiniciar mis data. Supongo que olvidé añadir el script aquí. En realidad, ¿por qué es eso? Creo que eso podría ser un problema. Bien, antes de pasar al último conjunto de pruebas, necesito averiguar por qué mi aplicación no está sembrando la database, por qué mi prueba no está sembrando. Así que dame un segundo y lo arreglaré. Si tienes alguna pregunta mientras tanto, no dudes en desactivar el silencio.

¿O cómo siembras y gestionas la database en las pruebas de extremo a extremo para que no se interfieran entre sí? Oh, esa es una buena pregunta. Creo que la respuesta definitiva a esa pregunta es el diseño de la prueba, ¿verdad? Así que necesitas encontrar el elemento de nivel superior que va a asegurar que las pruebas no interfieran entre sí. Así que lo que quiero decir con eso es, por ejemplo, si tienes un servicio SaaS, estás testing una aplicación SaaS, entonces un solo elemento, como un elemento de nivel superior puede ser la cuenta, ¿verdad? Así que cuando tienes dos usuarios registrados en tu producto, no van a interferir entre sí porque simplemente no puedes compartir data entre dos cuentas. Eso tiene sentido, ¿verdad? No quiero ver tus data, tú no quieres ver las mías, o no quiero que veas mis data. Así que lo que haría, diseñaría mis pruebas de tal manera que cada prueba crearía una nueva cuenta, y eso es un poco excesivo, así que tal vez esa no sea la mejor parte. Así que la forma en que abordé eso en mi empresa anterior, crearía una única cuenta de testing que se utilizaría para el 90% de las pruebas, y luego dentro de esa cuenta, cada prueba crearía como una entidad dentro de ella. Así que por ejemplo, si tienes, no sé, si tengo una aplicación Trello, te registras y creas tu tablero, y todas las pruebas de los tableros, cada prueba de tablero comenzaría creando un tablero por API, y luego usando ese tablero en la prueba, ¿verdad? De esa manera, al final de la ejecución de la prueba, tendría un usuario con quizás 100 tableros diferentes, pero al menos no interferiría uno con otro. Luego, como mencioné, el 90% de las pruebas funcionan así, y luego, por supuesto, el 10% restante serían pruebas que se ocupan de la gestión de usuarios. Así que quiero invitar al usuario a mi organización, o quiero eliminar al usuario de mi organización, y cosas así. Así que la forma en que se trataría eso sería que esas pruebas realmente crearían una nueva cuenta. Así que al final de una ejecución de prueba, terminaría con un montón de cuentas creadas, y un montón de recursos creados en la database de testing. Ahora, el único problema con eso era que cada ejecución de prueba crearía algunos data. Así que la forma en que tratamos con eso en mi empresa anterior es que crearíamos una convención de nomenclatura para esas cuentas. Así que se llamarían como tester, más uno, dos, tres, cuatro, cinco, seis, o algo así. Y luego todas esas cuentas serían eliminadas al final del día. Así que tendríamos un trabajo cron que básicamente encontraría todos los recursos, todos los data que serán creados por estas cuentas de testing, y simplemente los eliminaría de la database. Así que no contaminaríamos nuestra database con demasiada información y la haríamos lenta o hinchada o lo que sea. Así que sé que esto podría ser como para no la respuesta más satisfactoria, porque realmente no se trata de cómo hacer eso. No mostré cómo hacer eso, pero es prácticamente una cuestión de diseño de la prueba.

Optimizando el inicio de sesión con CY Session

Short description:

Para optimizar el proceso de inicio de sesión, Cypress proporciona la API de CY session, que permite que la secuencia de inicio de sesión se ejecute solo una vez y luego toma una instantánea de las cookies del navegador, el almacenamiento local y otros datos. Esta información se almacena y se carga para las pruebas subsiguientes, asegurando que el usuario esté conectado sin pasar por el proceso de inicio de sesión de la interfaz de usuario varias veces. El comando CY session se utiliza para envolver la secuencia de inicio de sesión, con el nombre de la sesión como primer argumento y una función de devolución de llamada que contiene los comandos de inicio de sesión como segundo argumento. Cuando se ejecuta la prueba, si la sesión no ha sido creada, se ejecutan los comandos de inicio de sesión. Si la sesión ha sido creada, se cargan las cookies almacenadas y otros datos, permitiendo que la prueba proceda sin necesidad de inicio de sesión de la interfaz de usuario. Esta optimización es especialmente útil cuando se prueban aplicaciones que requieren autenticación para acceder a recursos o utilizar ciertas características.

Y es realmente bueno pensar en esto desde el primer día, desde el día uno, porque si lo haces, entonces te vas a ahorrar un gran dolor de cabeza cuando intentes paralelizar tus pruebas. Y ahí es donde realmente te va a golpear.

Bueno, tal vez las importaciones de fixture están mal en el conjunto de archivos de hook de prueba. Creo que, sí, creo que podrías tener razón sobre eso, pero pude resolverlo básicamente reescribiendo la database. Así que sí, podemos pasar a esto. Muy bien, así que tengo un bloque de descripción aquí. Y en este, lo que estoy haciendo, en realidad tengo un comando personalizado aquí que visitará mi aplicación y luego tomará un campo de inicio de sesión, llenará mi correo electrónico, y tomará un campo de contraseña, llenará la contraseña, y luego hará clic en enviar para ser redirigido al tablero, ¿verdad? En realidad, podría querer agregar como un CY location path name. Dispara, oops, dispara igual a slash. Eso es lo que quiero. Creo que sí. Sí, está bien. Así que esta es como la Cypress, la secuencia de inicio de sesión que hago antes de cada prueba. Así que si miro en la prueba número uno, veo que se llama al comando CY login. Lo tengo en la segunda prueba y lo tengo en la tercera prueba. Normalmente podría hacer algo como antes de cada uno o algo por el estilo, pero esto es solo para fines de demostración. Y también no pondría mi correo electrónico y contraseña aquí normalmente. Mi correo electrónico es real, pero la contraseña no. Así que, sí.

Bueno. Así que lo que estoy haciendo aquí es que estoy usando prácticamente la misma secuencia antes de cada prueba para estar conectado en mi prueba. Así que lo que estoy haciendo es que estoy preparando mi prueba y asegurándome de que estoy autorizado para ver los tableros privados o recursos privados, cualquier tipo de elementos que tengo en mi aplicación. Ahora he visto esto bastante para hacer un inicio de sesión antes de cada prueba. Y tiene sentido porque necesitas estar conectado para acceder a algunos recursos o incluso para usar la aplicación, ¿verdad? Algunas de las aplicaciones funcionan de tal manera que básicamente solo se te permitirá usarla si estás conectado. Así que usar un inicio de sesión de UI es un poco excesivo. Pero de nuevo, he visto que eso sucede.

Ahora la respuesta natural a, bien, ¿cómo acelero mi inicio de sesión? ¿Cómo hago esto más efectivo? Sería usar un inicio de sesión programático. Y eso suena realmente elegante y suena realmente divertido. Pero en la práctica, sé que cuanto más complicado sea tu método de authentication, más difícil será crear un inicio de sesión programático. Así que mientras la idea es realmente genial y si tienes los recursos y el conocimiento para hacerlo, por todos los medios, adelante. Pero si no lo haces, puedes optimizar esto de una manera que funcionaría realmente bien. Porque Cypress ha creado una API que se llama CY session. Eso básicamente hará que esta secuencia de inicio de sesión se ejecute solo una vez. Y luego básicamente tomará una instantánea de tu navegador de todas las cookies, almacenamiento local, y todo tipo de data. Almacenará esa información y luego la cargará para todas tus próximas pruebas. De esa manera te conectas a través de la UI solo una vez y luego estás conectado para todas tus otras pruebas. Así que antes de mostrarte eso, quiero hablar un poco como el principio de cómo se hace el inicio de sesión. Y por supuesto, si vamos a hablar sobre diferentes métodos de inicio de sesión, entonces las cosas pueden complicarse realmente rápido. Pero el principio básico de iniciar sesión es que tienes tres entidades. Tienes el front end, que es la aplicación que vemos. Tienes el backend, que se encarga de asegurarse de que estás autenticado y realmente tienes acceso a ciertos recursos. Y luego tenemos el navegador, ¿verdad? Ese navegador generalmente almacena información, algún tipo de información ya sea del servidor o, sí, del servidor, ¿verdad? Así que podemos ver esa información. Nuestra aplicación utiliza métodos de inicio de sesión muy simples. ¿Puedo ver eso? Oh, en realidad tengo, sí, vamos a ejecutar solo la primera prueba. Eso nos conectará. Y verás eso en las cookies. Así que cuando hacemos el inicio de sesión, hay una llamada a la API haciendo el inicio de sesión de la API. Así que si miro en el panel de red, veré que lo que sucede cuando envío la carga útil al servidor, el servidor va a responder con este token de acceso, ¿verdad? Lo que sucede entonces es que ese token de acceso se va a guardar en nuestras cookies del navegador. Así que vemos el token de autenticación

Optimizando el inicio de sesión con el comando Session

Short description:

Al usar el comando de sesión en Cypress, puedes optimizar las secuencias de inicio de sesión y evitar inicios de sesión redundantes en múltiples pruebas. El comando de sesión te permite cargar una sesión almacenada, reduciendo el tiempo de inicio de sesión y mejorando la eficiencia de la prueba. La sesión se puede almacenar en caché en diferentes especificaciones en la misma máquina, mejorando aún más el rendimiento. Además, puedes usar la opción de validación para asegurarte de que la sesión aún está activa y evitar fallos de prueba debido a tokens de autorización caducados.

Entonces esto va a hacer algo interesante con nuestra prueba porque cuando descomento esto y vuelvo a ejecutar mi prueba, va a ejecutarse, déjame comentar esto y mostrarte la diferencia. Entonces, si no uso la sesión y ejecuto mi comando, va a tardar unos cinco segundos en ejecutarse, ¿verdad? Si vuelvo a poner esto y ejecuto, mi prueba la primera vez va a hacer un inicio de sesión en lugar de tres y va a ejecutarse durante dos segundos. Si lo ejecuto de nuevo, solo va a tardar aproximadamente un segundo porque para todas las tres pruebas, en realidad va a cargar esa sesión en lugar de ejecutarla. De esta manera, digamos que tenemos una ejecución de prueba donde tenemos 20 pruebas y todas ellas necesitan un inicio de sesión. En lugar de hacer el inicio de sesión 20 veces, lo haces solo una vez y luego cargas la sesión. Sí, gran pregunta. Si ejecutas esas pruebas en paralelo ¿Cypress seguirá recordando las cookies de la sesión? La respuesta es sí, pero, hay otro argumento en el comando de sesión y ese es el objeto de opciones. Entonces, aquí, puedes definir la opción de caché en todas las especificaciones y decir verdadero. Entonces, lo que esto va a hacer es que va a almacenar en caché la sesión no solo dentro de esta especificación sino también con todas las demás especificaciones en esa máquina. Entonces, si tengo esta opción y ejecuto mi prueba y tengo 20 especificaciones diferentes, voy a ejecutar solo una vez, hacer el inicio de sesión solo una vez y luego para todas las demás pruebas estoy conectado. Si ejecuto en paralelo, si ejecuto en paralelo, normalmente la forma en que lo hago es si tengo un CI y estoy ejecutando por ejemplo, en 10 máquinas voy a iniciar sesión 10 veces, ¿verdad? Entonces, en cada máquina la sesión se va a ejecutar una vez y luego para todas las demás veces en esa máquina simplemente se va a usar la caché, ¿verdad? Hay otra opción que se llama validar y esta es en realidad una función que puede ayudarnos a validar si la sesión aún está activa. Entonces, imagina que haces un inicio de sesión pero ese inicio de sesión solo es válido para, no sé, cinco minutos, ¿verdad? Si tus pruebas se ejecutan más de cinco minutos podrías tener un problema porque tu token de autorización podría caducar y tus pruebas simplemente empiezan a fallar en medio de la ejecución. Entonces, la forma en que puedes validar eso, puedes agregar una función donde puedes usar cualquier tipo de lógica que validará si la sesión aún está activa. Entonces, la forma en que normalmente funcionaría es que llamarías a una solicitud de CY para llamar tal vez a cierta entidad e intentar validar si esa clave de API aún es válida. Si no es así, la solicitud de CY te dará un error 403 o 401 y eso señala a Cypress, bien, en realidad necesito ejecutar esta sesión, esta secuencia de comandos de nuevo. Entonces, debido a eso, podrías no terminar obteniendo un inicio de sesión solo una vez sino tal vez dos o tres veces dependiendo de cuánto tiempo tarde en expirar la sesión. Pero de nuevo, esta es una forma muy agradable de asegurarte de que tu prueba puede ejecutarse.

Simulando APIs de terceros y depurando con Replay

Short description:

Al simular APIs de terceros, puedes utilizar el comando intercept en Cypress para definir qué API coincidir y cómo manejarla. Pasando una función al comando intercept, puedes modificar dinámicamente la solicitud y la respuesta. Antes de simular, puedes validar la respuesta real para asegurarte de que nada ha cambiado. Si algo ha cambiado, la afirmación fallará, indicando que los simulacros pueden estar desactualizados. Este enfoque te permite combinar la simulación con la validación. Replay es un navegador que registra las interacciones de la aplicación, permitiendo la depuración de información interna que puede no ser visible en las pruebas de Cypress. Al abrir una nueva pestaña, pulsar el botón de grabación e interactuar con la aplicación, puedes crear una grabación para la depuración. Replay proporciona herramientas de desarrollo de viaje en el tiempo para la depuración y análisis del comportamiento de la aplicación.

Tenemos una pregunta de Davi. Así que quiero leerla. Entonces, al simular APIs de terceros ¿cómo organizarías el ejemplo de las imágenes para diferentes escenarios? Hice un montón de JSONs en el pasado pero las formas fácilmente se quedan obsoletas y desincronizadas. Estoy considerando ahora las fábricas de simulación pero tal vez una database sería interesante para mantener la integridad a través de las entidades. Esperemos que cualquier solución pueda ser compartida con las pruebas unitarias. ¿Algún consejo sobre este tema?

Buena pregunta. No tengo mucha experiencia simulando APIs de terceros pero hay algo que podría estar conectado a esto que podría ser interesante. Como mencioné, cuando tienes el comando intercept puedes pasar un objeto que definirá qué API quieres coincidir, ¿verdad? Así que el primer objeto define lo que quieres coincidir. Así que vamos a añadir forms. El segundo objeto define cómo quieres manejar eso. Así que puede haber cosas como, no sé, el cuerpo que quieres cambiar el cuerpo, lo que sea, ¿verdad? La parte divertida es cuando pasas una función aquí, ¿verdad? Porque ahora puedes hacer cosas de forma dinámica. Puedes cambiar el cuerpo de la solicitud. Puedes cambiar la respuesta, ¿verdad? Así que hay una función llamada reply y usando esa función puedes cambiar cosas sobre el cuerpo de la respuesta, por ejemplo. Así es como harías la simulación, ¿verdad? Así que tomemos la respuesta y cambiémosla a un array vacío, por ejemplo. ¿Verdad? Pero ¿qué pasa si este cuerpo de respuesta no vuelve o viene en una forma o forma diferente a la que estaba acostumbrado antes? Bueno, dentro de esta función puedes hacer una afirmación primero. Así que espero, no sé, espero que el cuerpo de la respuesta, no sé, sea un objeto primero o, no sé, espero que el nombre del cuerpo sea una cadena o puedes hacer, puedes hacer un, esto necesita un plugin, pero hay un esquema JSON y puedes decir qué tipo de esquema JSON debería tener ese cuerpo de respuesta, para ser, no sé, no puedo encontrar las palabras correctas, ¿verdad? Así que antes de empezar a simular, primero compruebas si todo está correcto con la respuesta real. Y sólo después de eso, vas a empezar a simular. Así que puedes hacer ambas cosas, ¿verdad? Puedes obtener lo mejor de ambos mundos. Puedes hacer la simulación, pero también puedes validar si nada ha cambiado. Si algo ha cambiado, esa afirmación va a fallar y te va a dar información valiosa sobre el hecho de que, oh, algo sobre esto ha cambiado realmente. Así que, nuestros simulacros pueden estar desactualizados. Así que esta podría ser tu solución en la medida en que entiendo el problema. Así que si no he respondido correctamente a la pregunta, no dudes en intervenir. Pero sí, así es como abordaría eso.

Tengo un capítulo final. No sé si tengo... Oh, esta es la última diapositiva. Ni siquiera tengo la diapositiva de lo que aprendes. Y eso es depurando CI con viaje en el tiempo. Bien. Así que mencioné al principio que trabajo como dev rel para una empresa llamada replay IO. También soy embajador de Cypress. Así que he estado haciendo masterclasses de Cypress y tengo un blog lleno de posts sobre Cypress. Y una cosa que siempre me pareció curiosa sobre Cypress era el hecho de que pasé bastante tiempo depurando. Y mientras que Cypress viene con muchas herramientas geniales de serie para ayudarte a debug, pasé una gran parte de mi día depurando, sin embargo. Así que cuando me enteré de replay, pensé que era como el compañero perfecto para las pruebas de Cypress. Y eso es lo que quiero mostrarles. Básicamente, la idea es simple. Déjame abrir una nueva ventana y tengo React... Tengo como esta pequeña aplicación react aquí y voy a ejecutarla. Vamos a hacer NPM, run dev. Sí, eso está bien para abrir eso. Vamos a hacer... Bien. Y tengo como una pequeña aplicación aquí que prácticamente no hace nada. Simplemente cuenta. Y cada vez que hago clic en ella, simplemente va a iterar este número. Así que normalmente cuando estaría haciendo testing en Cypress, haría clic en esto y vería la interfaz de usuario. Y cada vez que quisiera debug algo, miraría la interfaz de usuario. Miraría la captura de pantalla, en el video y demás. Ahora puedo mostrarles el código de esta aplicación y hacer algo como, no quiero decir malo porque no es malo, pero es algo que puede hacer que la depuración de mis pruebas, de mi aplicación sea un poco más difícil. Así que aquí está el conteo, y va a mostrar el número, ¿verdad? Si miro la aplicación, ves que el conteo es, y luego mostrará el número. Así que si cambio esto y digo que el conteo está oculto. Ahora puedo estar haciendo clic en este botón y no vería el número real, pero el número real está en la aplicación. Todavía está en los internos de las aplicaciones. Y hay muchos tipos de información que todavía se guardan en el estado interno de la aplicación que no son visibles. Y a veces esos podrían ser realmente valiosos para averiguar. Ahora, si estoy testing con Cypress y me encuentro con un problema que es causado por esta información interna, entonces estoy un poco fuera de suerte, no puedo ver nada. Así es donde entra en juego replay. Básicamente la idea es esta. Replay es un navegador que tiene una cierta capacidad. Esa capacidad es la habilidad de grabar lo que está pasando en tu aplicación, ¿verdad? Cuando creas esa grabación, puedes tomar esa grabación y empezar a depurarla. Así que básicamente lo que harías, abrirías una nueva pestaña, pulsarías el botón de grabación, y luego interactuarías con tu aplicación. Lo que obtendrías de ello es una grabación que se ve algo así. Déjame mostrarte. La idea básica es esta, ¿verdad? Estamos construyendo en Replay Worktree y construyendo unas herramientas de desarrollo de viaje en el tiempo. Oh, aquí vamos. Aquí tenemos algo. No es realmente lo que quería mostrarles en primer lugar, pero creo que esto podría funcionar. Estamos construyendo unas herramientas de desarrollo de viaje en el tiempo.

Depuración con Replay y Playwright

Short description:

Replay te permite crear y depurar grabaciones de tu aplicación, proporcionando información sobre cómo funciona y cambia con el tiempo. Al ejecutar pruebas de Cypress con el navegador Chromium de Replay, puedes examinar los comandos, las llamadas a la API y las acciones en la grabación. El código de la aplicación interactiva revela los problemas subyacentes, como el estado que no se está mutando correctamente. El superpoder de Replay radica en su capacidad para examinar la grabación y hacer cambios en el código después de ejecutar la prueba. Esto ayuda a identificar y resolver la inestabilidad causada por el comportamiento de la aplicación. La depuración conjunta con los probadores y desarrolladores puede cerrar la brecha y mejorar la estabilidad de las pruebas. Playwright se está poniendo al día con Cypress en términos de características y puede incluso superarlo en el futuro. Considera usar Playwright para nuevos proyectos ya que ofrece una experiencia de prueba agradable.

Lo que significa es que te permitimos crear una grabación y luego debug esa grabación en las herramientas de desarrollo que hemos construido. Así que parecen un poco similares a las herramientas de desarrollo de Chrome o las herramientas de desarrollo de Firefox. Pero lo que hacen es que te permiten examinar la grabación de tu aplicación y ver cómo funciona tu aplicación. Ver cómo tu aplicación estaba cambiando con el tiempo, ¿verdad? Así que aquí tengo una grabación de mi aplicación donde estaba haciendo clic en esta pequeña aplicación que muestra una especie de demostración de e-commerce donde puedes comprar algunas zapatillas. Así que puedes hacer clic en Añadir al carrito y verás un mensaje que dice Producto añadido al carrito. Así que he creado una grabación y puedo reproducir esta grabación como un video, ¿verdad? Así que veré que se ejecuta como un video y puedo ver lo que estaba haciendo la aplicación. Puedo ver que el producto fue añadido al carrito. Ahora, ya que la capacidad de grabación está incorporada en un navegador que distribuimos, así que en realidad hicimos un fork de Chromium y construimos capacidades encima de eso. Lo que podemos hacer es que podemos ejecutar pruebas de Cypress con ese navegador. Así es como se vería la implementación es básicamente un plugin que instalarás añadirás algunas claves de API, blah, blah, blah. Y luego haces NPX Cypress run con un navegador que se llama Replay Chromium. Así que lo que esto hará es que creará una grabación como esta. Te la voy a mostrar. Aquí tengo una prueba inestable. Ejecuté esta aplicación y esta aplicación estaba fallando porque algo estaba pasando. Hice clic en el botón Añadir al carrito y en lugar de ver el producto se añadió con éxito al carrito. He visto un mensaje que decía falló al añadir el producto al carrito. Así que mi prueba estaba fallando y como puedes ver en este tipo de video puedes ver que la prueba se está reintentando. Eso también se indica en este panel de la izquierda. Podemos ver que el intento número uno falló el intento número dos falló. Finalmente, la prueba finalmente pasó. Así que puedo echar un vistazo al detalle de la prueba fallida y lo que obtendré es similar a la experiencia que obtengo en Cypress, ¿verdad? Puedo ver todos los comandos. Puedo ver todas las llamadas a la API que se hicieron. Puedo ver las acciones y lo que puedo ver con las acciones de hecho, déjame mostrarte es que cada vez que hice un clic un comando, lo que puedo hacer, puedo saltar al código y esto me llevará directamente dentro del código de la aplicación y a la línea exacta que se ejecutó mientras mi prueba estaba corriendo, ¿verdad? Así que cuando hice clic en realidad desencadenó esta llamada a la API de añadir al carrito, ¿verdad? Así que en realidad tenemos dos llamadas a la API aquí. Esto es como una tienda de e-commerce. Eso está aquí. Y hay dos llamadas a la API que se están haciendo, ¿verdad? Tenemos que comprobar la disponibilidad que comprobará si la zapatilla está realmente disponible para nosotros. Y luego está añadir al carrito. Esta es la acción que se desencadena cuando hacemos clic en el botón añadir al carrito y tratamos de comprar la zapatilla. Así que el problema con esta prueba inestable no es realmente aparente a primera vista. Hacemos clic en el botón y algo simplemente no funciona. Pero si hacemos una deep dive en el código podemos examinar lo que está pasando con ese código. Así que estas dos llamadas a la API en realidad son una condición de carrera. Y la forma en que podemos averiguarlo es que esta fuente de la aplicación este código de la aplicación que podemos ver que normalmente no podríamos ver es en realidad interactivo. Así que por ejemplo, puedo ver que este añadir al carrito está enviando un cuerpo al servidor y está enviando este parámetro de cantidad. Así que esta cantidad está en realidad guardada en un estado podemos ver que se define aquí. Y por defecto ese estado se resuelve a cero. Así que usamos el estado, vemos el cero y eso es lo que podríamos terminar enviando al servidor. Así que estamos tratando de comprar cero zapatillas. Ahora la forma en que podemos revelar esa información es que podemos hacer clic en este botón más y est

Cypress vs Playwright y Desarrollo Futuro

Short description:

Personalmente, todavía prefiero Cypress a Playwright. Playwright es más verboso pero más rápido en la ejecución. Playwright se pone al día con muchas características y es probable que se añadan las características que faltan. Migrar de Cypress a Playwright puede no ser el mejor enfoque, especialmente para grandes bases de código. Playwright no resuelve la inestabilidad, por lo que si tus pruebas son inestables, considera usar Replay. Cypress está trabajando en la adición de múltiples pestañas, pero la solución actual usando Puppeteer se ve como una solución temporal. Cypress necesita acelerar el desarrollo para mantenerse por delante de Playwright. Gracias por asistir a la masterclass.

Personalmente, todavía prefiero Cypress a Playwright. Me gusta un poco más la sintaxis. Me resulta un poco más fácil leer y navegar a través de ella. Playwright es un poco más verboso pero es más rápido en la ejecución eso hay que decirlo. Se pone al día con muchas de las características. Estoy tratando de pensar en una característica que podría faltar si hay algo. El enfoque sobre la sesión de almacenamiento en caché es ligeramente diferente. El enfoque con la interceptación es ligeramente diferente pero sí tengo eso en términos de tener características Estoy bastante seguro de que marcan la mayoría de las casillas que Cypress tiene y si no hay algo y falta probablemente lo añadirán. He visto ese patrón a lo largo del último año donde añadirían algo que los usuarios de Cypress realmente apreciaban sólo para tenerlo. No sólo para tenerlo sino básicamente para asegurarse de que no hay brecha entre estas dos herramientas. Creo que Playwright es emocionante. Te sugiero que lo pruebes. Pero si tienes como 2000 pruebas y estás pensando en migrar no creo que sea el mejor enfoque. Si tus pruebas son inestables realmente te sugiero que pruebes Replay porque vas a tener la inestabilidad en Playwright también. No va a resolver la inestabilidad aunque es emocionante en muchos aspectos y algunas personas dicen que es más estable. Creo que lo que finalmente va a decidir si tu prueba es estable es la aplicación y el diseño de la prueba design que vas a implementar. Así que migrar puede no ser lo mejor especialmente si tienes una gran base de código. Pero si quieres probarlo por todos los medios hazlo. Bueno, esto concluye prácticamente nuestra masterclass pero si tenemos más preguntas no dudes en intervenir. De lo contrario, puedes encontrarme en LinkedIn y en Twitter y si tienes problemas con la prueba de Cypress o necesitas algún consejo siempre estaré encantado de ayudar. Así que sí, nos vemos en internet.

¿Crees que Cypress va a hacer múltiples pestañas en el futuro? Sí, buena pregunta. En realidad están trabajando en eso. Crearon una especie de plugin de solución temporal que utiliza Puppeteer en segundo plano. No soy realmente un fan de esta solución. Creo que es sólo una solución temporal que siempre estuvo ahí y creo que la developer experience de Cypress es realmente, realmente buena. Y al añadir este plugin de Puppeteer que se supone que te ayuda con el problema de las múltiples pestañas básicamente estás escapando de esa developer experience esa buena developer experience de Cypress. Así que no creo que añada mucho valor pero ellos afirman que esta es una especie de solución sólo por ahora para ver cómo responderá el público si es algo que quieren o no. Y si va a ser interesante entonces lo implementarán en la developer experience nativa de Cypress pero no lo sé. No veo que eso suceda pronto. Así que, pero veremos, veremos. Creo que Cypress va a necesitar dar un paso adelante y acelerar sus desarrollos el próximo año. De lo contrario, serán desplazados de su primer lugar por Playwright. Pero así que espero, pero no lo sé. Disfruto mucho de esto. Así que gracias por estar aquí. Y sí, nos vemos la próxima vez.

Watch more workshops on topic

React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
TestJS Summit 2022TestJS Summit 2022
146 min
How to Start With Cypress
Featured WorkshopFree
The web has evolved. Finally, testing has also. Cypress is a modern testing tool that answers the testing needs of modern web applications. It has been gaining a lot of traction in the last couple of years, gaining worldwide popularity. If you have been waiting to learn Cypress, wait no more! Filip Hric will guide you through the first steps on how to start using Cypress and set up a project on your own. The good news is, learning Cypress is incredibly easy. You'll write your first test in no time, and then you'll discover how to write a full end-to-end test for a modern web application. You'll learn the core concepts like retry-ability. Discover how to work and interact with your application and learn how to combine API and UI tests. Throughout this whole workshop, we will write code and do practical exercises. You will leave with a hands-on experience that you can translate to your own project.
React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
WorkshopFree
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop
TestJS Summit 2023TestJS Summit 2023
48 min
API Testing with Postman Workshop
WorkshopFree
In the ever-evolving landscape of software development, ensuring the reliability and functionality of APIs has become paramount. "API Testing with Postman" is a comprehensive workshop designed to equip participants with the knowledge and skills needed to excel in API testing using Postman, a powerful tool widely adopted by professionals in the field. This workshop delves into the fundamentals of API testing, progresses to advanced testing techniques, and explores automation, performance testing, and multi-protocol support, providing attendees with a holistic understanding of API testing with Postman.
1. Welcome to Postman- Explaining the Postman User Interface (UI)2. Workspace and Collections Collaboration- Understanding Workspaces and their role in collaboration- Exploring the concept of Collections for organizing and executing API requests3. Introduction to API Testing- Covering the basics of API testing and its significance4. Variable Management- Managing environment, global, and collection variables- Utilizing scripting snippets for dynamic data5. Building Testing Workflows- Creating effective testing workflows for comprehensive testing- Utilizing the Collection Runner for test execution- Introduction to Postbot for automated testing6. Advanced Testing- Contract Testing for ensuring API contracts- Using Mock Servers for effective testing- Maximizing productivity with Collection/Workspace templates- Integration Testing and Regression Testing strategies7. Automation with Postman- Leveraging the Postman CLI for automation- Scheduled Runs for regular testing- Integrating Postman into CI/CD pipelines8. Performance Testing- Demonstrating performance testing capabilities (showing the desktop client)- Synchronizing tests with VS Code for streamlined development9. Exploring Advanced Features - Working with Multiple Protocols: GraphQL, gRPC, and more
Join us for this workshop to unlock the full potential of Postman for API testing, streamline your testing processes, and enhance the quality and reliability of your software. Whether you're a beginner or an experienced tester, this workshop will equip you with the skills needed to excel in API testing with Postman.
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
WorkshopFree
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.
TestJS Summit 2023TestJS Summit 2023
89 min
Building out a meaningful test suite that's not all E2E
Workshop
We're all taught to follow the Testing Pyramid but the reality is that we build out the Testing Christmas Tree. In this workshop, David will talk you through how to break down projects and put the tests where they need to be. By the end of the workshop you will be able to update your projects so that anyone and everyone can start contributing and truly living up to "Quality is everyone job".
He will walk you through:- Component Testing- API Testing- Visual Regression Testing- A11Y testing
He will also talk you through how to get these all setup in your CI/CD pipeline so that you can get shorter and faster feedback loops.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

TestJS Summit 2021TestJS Summit 2021
33 min
Network Requests with Cypress
Whether you're testing your UI or API, Cypress gives you all the tools needed to work with and manage network requests. This intermediate-level task demonstrates how to use the cy.request and cy.intercept commands to execute, spy on, and stub network requests while testing your application in the browser. Learn how the commands work as well as use cases for each, including best practices for testing and mocking your network requests.
TestJS Summit 2021TestJS Summit 2021
38 min
Testing Pyramid Makes Little Sense, What We Can Use Instead
Featured Video
The testing pyramid - the canonical shape of tests that defined what types of tests we need to write to make sure the app works - is ... obsolete. In this presentation, Roman Sandler and Gleb Bahmutov argue what the testing shape works better for today's web applications.
TestJS Summit 2022TestJS Summit 2022
27 min
Full-Circle Testing With Cypress
Cypress has taken the world by storm by brining an easy to use tool for end to end testing. It’s capabilities have proven to be be useful for creating stable tests for frontend applications. But end to end testing is just a small part of testing efforts. What about your API? What about your components? Well, in my talk I would like to show you how we can start with end-to-end tests, go deeper with component testing and then move up to testing our API, circ
TestJS Summit 2021TestJS Summit 2021
31 min
Test Effective Development
Developers want to sleep tight knowing they didn't break production. Companies want to be efficient in order to meet their customer needs faster and to gain competitive advantage sooner. We ALL want to be cost effective... or shall I say... TEST EFFECTIVE!But how do we do that?Are the "unit" and "integration" terminology serves us right?Or is it time for a change? When should we use either strategy to maximize our "test effectiveness"?In this talk I'll show you a brand new way to think about cost effective testing with new strategies and new testing terms!It’s time to go DEEPER!
TestJS Summit 2023TestJS Summit 2023
21 min
Everyone Can Easily Write Tests
Let’s take a look at how Playwright can help you get your end to end tests written with tools like Codegen that generate tests on user interaction. Let’s explore UI mode for a better developer experience and then go over some tips to make sure you don’t have flakey tests. Then let’s talk about how to get your tests up and running on CI, debugging on CI and scaling using shards.