Ganando confianza con pruebas Cypress

Bienvenidos a React Advanced London. Soy Rob Richardson y vamos a aprender sobre cómo ganar confianza con las pruebas de Cypress. Aquí es donde les digo que definitivamente voy a publicar las diapositivas en mi sitio web esta noche. He sido esa persona persiguiendo al orador y nunca me ha funcionado muy bien a mí tampoco, por eso pueden ir a RobRich.org ahora mismo, hacer clic en Presentaciones aquí en la parte superior y aquí está cómo ganar confianza con las pruebas de Cypress. Las diapositivas y el código están disponibles en línea.

Mientras estamos aquí en RobRich.org, hagamos clic en Acerca de mí y veremos algunas de las cosas que he hecho recientemente. Soy un defensor del desarrollo de SIRL. Si tienes problemas para controlar tu data mesh, hablemos. También soy un Microsoft MVP, capitán de Docker, amigo de RedGate y AZ Give Camp es realmente divertido. AZ Give Camp reúne a desarrolladores voluntarios con organizaciones benéficas para construir software gratuito. Comenzamos el viernes después del trabajo. El domingo por la tarde, entregamos el software completo a las organizaciones benéficas. Dormir es opcional, se proporciona cafeína. Si estás en Phoenix, únete a nosotros en el próximo AZ Give Camp, o si quieres un campamento de regalos aquí en Londres, o donde sea que te estés conectando, contáctame por correo electrónico o Twitter y organicemos un campamento de regalos en tu vecindario también. Algunas de las otras cosas que he hecho. Fui un contribuyente principal de Gulp en la versión dos y tres, y respondí a un episodio del podcast .NET Rocks. Leyeron mi comentario en el aire y me enviaron una taza. ¡Woo-hoo!

Así que ahí está mi reclamo a la fama, mi codiciada taza de .NET Rocks. Vamos a adentrarnos en cómo ganar confianza con Cypress Tess. Ahora, no estoy muy seguro de cómo va a ir esta charla, así que voy a iniciar esto y veamos si mi sitio está listo. Ahora, nuestro primer paso es hacer una compilación de TypeScript. Así que vamos a iniciar eso. Una vez que tengamos nuestra compilación de TypeScript, luego comenzaremos a ejecutar cada una de nuestras pruebas. Hasta ahora parece bien. Está funcionando bastante bien. Sí. Parece que esta prueba va a funcionar bastante bien. Sí, mi sitio está funcionando bien. Eso es genial. Eso es increíble. Parece que mi sitio funcionará y esta charla saldrá muy bien. Vimos pruebas funcionales basadas en el navegador en Cypress. Eso fue bastante genial. O dicho de otra manera, vimos pruebas de extremo a extremo. Cypress es ese mecanismo para ejecutar experiencias de manera similar a como lo haría un usuario. Es una aplicación de electron y un complemento del navegador. Y está construido sobre Mocha y Chai. Como muchas buenas historias, comenzamos en el medio. Retrocedamos y comencemos desde el principio. Hablemos sobre las pruebas de navegador. Mientras hago pruebas de navegador, probablemente crearé pruebas en cada una de estas categorías. Puede que tenga pruebas relacionadas con una unidad de trabajo específica, un servicio empresarial específico. O puedo probar una API. Tal vez sea GraphQL o GRPC o REST. Puedo probar este servicio. Ahora, no es un servicio web, sino un servicio empresarial, y puedo querer probar ese servicio ejecutándose en un navegador específico. Puedo querer probar componentes donde todavía estoy haciendo pruebas unitarias, por lo que puedo estar simulando componentes hijos, y para cada uno de estos, puedo usar diferentes herramientas. Si quiero probar una pequeña unidad de trabajo,

Si quisiera validar esas pruebas, usaría mocha, Chai, Jest o Jasmine. Si quisiera validar esas pruebas, usaría Karma. Karma no realiza pruebas de extremo a extremo, sino que ejecuta pruebas unitarias dentro de un navegador. Si quiero validar un componente en particular, podría tomar mis pruebas de mocha o Jest y también incluir la biblioteca de utilidades de prueba. Hay una versión de utilidades de prueba para cada framework spa.

Si quiero probar mi API, no necesito un navegador en absoluto. Solo puedo enviar solicitudes web a ella. Verificar el código de estado en el cuerpo de la respuesta. Si quisiera hacer pruebas de extremo a extremo, podría usar Selenium, Cypress, Test Cafe o PlayWrite. A medida que obtienes estas diapositivas de robridge.org, puedes hacer clic en cada uno de estos enlaces azules para obtener más información sobre esa biblioteca en particular. Vamos a profundizar en las pruebas de extremo a extremo. Podría usar Selenium. Selenium es un controlador web y puedes programarlo en muchos lenguajes diferentes. Selenium es conocido por realizar pruebas frágiles y quebradizas. No sabe nada del navegador. Simplemente controla el mouse y mira el HTML. Si la API aún no estaba lista, podría volver a ejecutar mis pruebas. Eso hace que mis pruebas sean frágiles. O podría extender el tiempo de espera. Eso hace que mis pruebas sean lentas. Selenium es conocido por pruebas lentas y quebradizas. En comparación, si uso Cypress, Cypress es un complemento del navegador. Puedo esperar a que el DOM esté listo o a que se complete esa llamada de API. Si son 10 milisegundos o un segundo, es cuando mis pruebas continuarán. Cypress, al estar profundamente integrado en el navegador, solo puedes escribir esas pruebas en JavaScript. Pero puedes tomar videos y capturas de pantalla en el camino, lo cual es perfecto. A continuación, Test Café. Si usas DevExpress para otro contenido, es posible que te sientas como en casa con Test Café. Con Test Café, no utiliza Mocha o Jest para su biblioteca de aserciones, por lo que se sentirá un poco extraño. También pasarás mucho tiempo manejando contenido entre el contexto de prueba y el contexto del navegador.

A continuación, Playwright. Playwright fue creado por los creadores de Puppeteer, por lo que si estás familiarizado con la automatización de Chrome con Puppeteer, te sentirás como en casa con Playwright. Sin embargo, la sintaxis de aserciones de Playwright se siente un poco añadida, por lo que es posible que no tengas mucho éxito allí, pero puedes usarlo en muchos lenguajes diferentes. En última instancia, la elección de qué framework de pruebas utilizar depende de ti, elige el que se ajuste a tus preferencias. Hoy vamos a echar un vistazo a Cypress. El primer paso que haré es instalar Cypress con NPM y ejecutar NPX Cypress open. Una vez que ejecute NPX Cypress open, se generará todo el contenido necesario para facilitar el inicio con Cypress. Ya lo he hecho aquí y podemos ver todas las pruebas generadas automáticamente. Por defecto, estará en JavaScript, pero he elegido hacer mis pruebas en TypeScript en su lugar. Ahora puedo elegir en qué navegador ejecutarlo y descubrirá todos los navegadores que tengo instalados en mi máquina. Viene con un navegador de electron, que es un navegador basado en Chromium. En este caso, está indicando que tengo una bandera específica de Chrome que Firefox no entiende. Eso está bien. Ahora puedo elegir ejecutar todas mis pruebas o seleccionar una prueba en particular. Así que vimos cómo lanzamos esta prueba y pudimos validar el contenido. Ahora notaremos que aquí está mi Chrome regular y aquí hay un nuevo Chrome. Se ha lanzado un nuevo perfil para asegurarse de que ninguno de mis complementos o formularios guardados interfieran con la ejecución de las pruebas. Ahora, es solo un navegador. Así que puedo hacer cosas interesantes. Puedo abrir otras pestañas del navegador y mis pruebas seguirán ejecutándose. No es necesario que me aleje de mi máquina cuando se ejecuten mis pruebas. Ahora, las pruebas ejecutarán cada paso en mi contenido y podrán validar que mis pruebas funcionen como se esperaba. Pero esto es solo un navegador. Así que si abro las herramientas de desarrollo F12, puedo cambiar a la pestaña de fuentes y ver mis pruebas. Si quiero establecer un punto de interrupción en mi prueba, ahora puedo actualizar y comenzar a depurar mi prueba con las herramientas de depuración normales F10 y F11. También puedo cambiar a la pestaña de consola y ver la salida en la consola en cada paso. Aquí está la salida en la consola en este paso y en este paso. Y puedo ver esa salida en la consola para cada una de las pruebas. Al cerrar las herramientas de desarrollo F12, puedo ver el contenido en cada paso, pero también puedo ver, por ejemplo, dónde hizo clic.

Hicimos clic justo aquí para poder realizar esa tarea. Ahora, puedo usar esta herramienta para poder seleccionar cosas. Volveremos a los selectores, pero aquí está el código exacto que necesito para poder seleccionar este objeto si lo pongo en mi prueba. También puedo elegir volver a ejecutar mis pruebas y ver éxitos y fallos. Ahora, eso es genial. Pudimos ver cómo funcionaba este IDE, y funcionó muy bien. Ahora, echemos un vistazo al contenido detrás de esto. Ahora, estábamos probando el sitio To-Do MVC. Ahora, está un poco desactualizado, pero tenemos ejemplos de MVC en varios frameworks y el proyecto To-Do MVC recopila estos para que podamos comenzar a comparar frameworks. Así que tengo mis pruebas, y abramos nuestro proyecto Cypress. Aquí está Cypress.json, y ese es el primer archivo que vamos a ver. Ahora, el trabajo de Cypress.json es dirigirnos a este archivo de complementos. En este caso, lo tengo en un proyecto TypeScript, así que iré a test/Cypress, complementos, y aquí está mi archivo plugins.index.html. Y esto definirá las carpetas para todo el resto del contenido en mi proyecto Cypress. Mis fixtures están aquí en la carpeta fixtures, mi carpeta de integración, ahí es donde están todas mis pruebas unitarias. Tengo capturas de pantalla y videos en la carpeta de resultados para asegurarme de que estén excluidos del control de código fuente. Y volveremos a los archivos de soporte que están aquí. A continuación, he elegido hacer mis pruebas en TypeScript. Este es el archivo de configuración base de TS en mi proyecto, y no tiene ningún detalle de TypeScript. Esto es solo la definición de TypeScript, la definición de compilación que tendría como parte de mi proyecto. Ahora, aquí dentro de la carpeta de pruebas de Cypress, también tengo un archivo de configuración de TS. Estas son las anulaciones específicas que necesito para poder iniciar Cypress desde TypeScript. Ten en cuenta que he extendido el archivo de configuración TypeScript anterior, por lo que solo necesito anular aquellas partes que son específicas de TypeScript. En mi archivo package.json, he elegido crear algunos atajos para poder hacer npx cypress open. Diré npm run cy:open, y eso iniciará el IDE. También puedo ejecutar cy:run desde mi compilación automatizada, y eso ejecutará la compilación sin cabeza. Puedo identificar navegadores específicos y luego concatenarlos. Entonces, si digo npm test, se ejecutará Chrome, Firefox y Edge, y validar que mis pruebas funcionen en los tres navegadores. Eso es perfecto. Así que echemos un vistazo a la prueba que escribimos para lograr esto.

Ahora estoy probando el proyecto To-Do MVC y alternando entre diferentes implementaciones. En este caso, estoy viendo la versión de AngularJS. Obtengo los nombres de los sitios para poder ponerlos en mi bloque de descripción de una manera realmente elegante y, antes de cada prueba, visitaré ese sitio. Lo hago para validarlo y no tener que hacer esto CY.visit al comienzo de cada prueba, pero definitivamente podría hacerlo si quisiera. Ahora, hagamos una prueba de hola mundo, donde simplemente obtenemos la URL y debería ser igual a la URL del sitio. Esto fue realmente útil. Cuando originalmente escribí esta charla, este sitio era HTTP, no HTTPS, por lo que fue realmente útil darme cuenta de que no estaba probando lo que esperaba. Si refactorizas tu sitio web, podría ser bueno saber si este contenido es 301 o 302 a una nueva página que no estás probando lo que esperas. Ahora, a continuación, echemos un vistazo a la lista de tareas. No hemos ingresado ninguna tarea, por lo que esta lista de tareas no debería existir. Perfecto. Dependiendo de esta implementación de SPAT, podría existir pero estar en blanco, pero en última instancia, estamos buscando los elementos li dentro de la lista, por lo que podría ser una suposición segura. A continuación, subamos de nivel y comencemos a interactuar con la página. Tengo un contenido y quiero escribirlo en el cuadro de tareas. Entonces, seleccionemos el nuevo cuadro de tareas y escribamos ese contenido y presionemos enter. Observa que hay un signo de dólar aquí y no aquí. Este enter es para que podamos ingresar comandos únicos. Mayús, opción, control, teclas F, cualquier cosa que podamos escribir de esta manera. Una vez que haya terminado, obtendré la lista de tareas y validaré que contenga mi nueva tarea. Observa que no hay esperas aquí. Tan pronto como terminemos de escribir ese contenido, esperará a que todos los eventos del navegador terminen antes de que Cypress pase a la siguiente línea. Entonces, vamos a validar que nuestro cuadro de tareas ahora esté en blanco y ahora hemos agregado una tarea. ¡Eso es perfecto! Marquemos una tarea como completada. Comenzaré creando esta tarea irrelevante, porque quiero asegurarme de completar la correcta. Luego marcaré mi nueva tarea que quiero hacer y validaré que pueda llegar allí. Entonces, obtendré esa vista que coincide con esta nueva tarea y obtendré los hijos del botón de alternancia. Ahora, haré clic en ese botón de alternancia y eso marcará esa tarea como terminada. Entonces, ¿qué significa estar terminado? Bueno, debería tener esta clase de completado y lo validaré seleccionando ese elemento de la tarea. Perfecto. Ahora hemos podido comenzar a

interactuar con la página de una manera realmente elegante. A continuación, vamos a eliminar una tarea. Entonces, escribiré una tarea relevante. Escribiré esta nueva tarea. Luego, buscaré esa tarea y encontraré el botón de eliminar. Ahora, el botón de eliminar solo es visible si pasamos el mouse sobre él, y estamos utilizando eventos de JavaScript. No estamos utilizando eventos del DOM, por lo que no obtenemos ese CSS pasar el mouse. No hay movimiento del mouse en este caso. Así que voy a decir que force es true para poder hacer clic en él aunque no esté visible. Perfecto. Ahora solo debería quedar una tarea, porque una de ellas se marcó como terminada, y podemos ver que solo debería ser la irrelevante.

Vamos a crear una nueva tarea, no la que marqué como completada. Perfecto. Ahora, a medida que empiezo a escribir estas cosas, me estoy volviendo un poco redundante. Quiero mostrar solo las tareas activas, pero no quiero seguir haciendo esto una y otra vez. Creemos un nuevo comando llamado agregar tarea. Ahora, este comando agregar tarea, tomará mi cosa y podrá realizar esos pasos asociados con la creación de la nueva tarea.

Así que aquí en mis comandos, tengo un index.ts que simplemente importa esos comandos. Aquí están mis comandos. Y tengo este comando agregar tarea. Toma una cadena, escribe en el cuadro y estoy aquí. También puedo validar que ese cuadro ahora esté vacío. Perfecto. De vuelta en mi prueba, ahora puedo describir las interacciones del usuario. Quiero agregar tres nuevas tareas. Si alguna vez has usado el objeto de página de Selenium, esto te resultará familiar. Hagamos algo similar para completar. Así que tenemos una acción completa, que buscará la vista, hará clic en el interruptor y marcará eso como completado. Ahora estamos empezando a describir las interacciones de los usuarios, por lo que nuestra prueba es más concisa y descriptiva. Genial. Vamos a buscar el botón de tareas activas, haremos clic en él y validaremos que ahora solo se muestren dos, que estamos filtrando solo por tareas activas. Terminando esta prueba, haremos cosas similares usando nuestras nuevas acciones y buscaremos el botón de tareas completadas y validaremos que ahora solo se muestre la que hemos marcado como completada. Y haremos algo similar haciendo clic en el botón de borrar tareas completadas, validando que ya no tengamos ninguna. Esto fue genial para poder mejorar a través de las diversas funciones en Cypress.

A continuación, hablemos de las interacciones en red. Similar a TodoMVC, tenemos la aplicación web progresiva de Hacker News. Ahora, podemos decir que esta es una continuación espiritual de TodoMVC. Crea una PWA que muestra detalles de Hacker News. Ahora, es genial porque puedo hacerlo en diferentes frameworks, pero no sé qué historias habrá en Hacker News. ¿Cómo puedo validar que ese contenido sea correcto? Vamos a ejecutar esta prueba y ver cómo funciona. Aquí está mi prueba de Hacker News PWA. Y mientras realiza esa prueba, realmente obtendrá las historias reales de Hacker

Hacker News. Ahí está nuestro JavaScript, nuestra compilación de TypeScript, y Cypress se da cuenta cuando hay cambios en cualquier archivo, por lo que reinició la prueba sabiendo que la compilación de TypeScript acaba de terminar. Ok, hagamos nuestra prueba de Hola Mundo. Eso funciona muy bien. Ahora, vamos a visitar el sitio de Hacker News para obtener detalles. Ahora, podríamos crear algunas historias falsas para poder validar que esa prueba sea como se espera, pero sería realmente desafortunado si solo usáramos datos falsos porque podríamos engañarnos fácilmente y no mostrar contenido de prueba real. Echemos un vistazo a eso. Veamos nuestra Hacker News PWA. En este caso, elegí la versión Angular 2, pero también podríamos ver la versión Next o la versión Nuxt. Comenzaré visitando esa página cada vez, y vamos a validar que la URL sea como se espera. Luego, queremos tener una historia principal específica. Ahora, no sé cuál es la historia principal en Hacker News, por lo que no hay forma de que pueda validar eso. Pero puedo interceptar esta solicitud web. En este caso, elegí una expresión regular, pero también podríamos usar una cadena aquí. Y cada vez que la aplicación realiza una solicitud a esto, voy a interceptarla y en su lugar devolveré este fixture. Aquí está este fixture, el Hacker News. Ahora sé que esta es la primera historia que será la primera historia en mi lista. Ahí está mi resultado esperado. Al visitar ese sitio de Hacker News, debería obtener ese título en mis resultados. Perfecto. Sería fácil engañarme y presumir que mi fixture es exactamente lo que la API devolverá. Y en este caso, vamos a realizar la solicitud web real, no la simularemos, para validar que mi API tenga la estructura esperada. Voy a asumir que Hacker News tiene 30 o más historias en él. Ahora, si esta solicitud de API fuera a tomar mucho tiempo, podría elegir darle un nombre específico y luego esperar específicamente con cy.wait. Pero en este caso, la API de Hacker News devuelve lo suficientemente rápido y no necesito hacerlo. Así que pudimos ver excelentes ejemplos de cómo construir pruebas en Cypress de varias formas. Y mejoramos a través de diferentes interacciones, desde solicitudes web hasta interactuar con la página, validar y seleccionar elementos DOM específicos, crear comandos para simplificar y ser más descriptivos en nuestras pruebas y, en última instancia, interceptar solicitudes web. Ahora, una de las cosas que queremos analizar son las mejores prácticas asociadas con Cypress. A medida que comenzamos a hacer nuestros selectores, definitivamente podríamos crear el selector CSS con una ruta completa que muestre todos los divs de cómo llegar de aquí a allá. Pero si refactorizáramos nuestra página, todo eso sería en vano. En su lugar, crea un selector específico que identifique un ID o una clase.

O incluso mejor, crea un elemento data-cy en tu elemento específico y luego especifica eso en tu prueba. cy.get data-cy es igual a ese elemento en particular. Ahora, la belleza aquí es que no solo obtienes exactamente el elemento que deseas cada vez, incluso si se mueve en la página, sino que también estás documentando que una prueba es responsable de este contenido en particular. Eso puede ser realmente útil. ¿Estás filtrando tu contenido de prueba en producción? Sí. Pero ¿no sería genial también ejecutar pruebas en producción? Tal vez cada hora o algo así, voy a iniciar mi página de inicio. Voy a acceder al catálogo de productos. Voy a agregar un artículo a mi carrito de compras. Voy a llegar a la página de pago. No ingresaré un número de tarjeta de crédito. No finalizaré la compra, pero ¿no sería genial si pudieras ejecutar esa prueba para todas las rutas más importantes en producción y saber si tu infraestructura falló antes de que tus clientes llamen? Eso sería ideal. Entonces, este mecanismo data-cy no solo facilita la documentación de que una prueba está asociada a él, sino que también te permite ejecutar pruebas en producción. A continuación, usemos comandos. Vimos cómo podíamos usar comandos para crear un mecanismo más simple para poder identificar los pasos en nuestras pruebas. Ahora el contenido de respaldo se puede reutilizar de formas interesantes y nuestras pruebas son mucho más concisas y descriptivas. A continuación, evita iniciar sesión en cada prueba. Definitivamente queremos validar la experiencia de inicio de sesión, pero solo queremos hacerlo una vez. En su lugar, al inicio de todas las pruebas, accede a una API y obtén un token que puedas usar para el resto de las pruebas. Tal vez esta sea una API solo para desarrollo o tal vez estés accediendo a la página del backend que la experiencia de inicio de sesión llamaría. Una vez que tengas ese token, úsalo en el resto de las pruebas. Quieres validar tu experiencia de inicio de sesión, pero no quieres hacerlo al inicio de cada prueba. Eso hará que tus pruebas sean más lentas. A continuación, usa mocks para poder... usar fixtures para poder mover datos reutilizables data fuera del contenido de prueba a un lugar más reutilizable. Esto hará que tus pruebas sean más concisas, más cortas y te permitirá reutilizarlas en diferentes pruebas. En este caso, teníamos un fixture que podíamos usar para simular los datos de Hacker News data. Esto es genial, podemos adjuntarlo a una solicitud web específica a través de CY.Intercept, y si algo sucede, ahora podemos comenzar a validar que nuestros controles se rendericen como se espera. Puedes hacer clic en el enlace azul aquí en las diapositivas que obtienes de rawbridge.org para acceder al código asociado para lograr eso. Ha sido divertido mostrarte Cypress y poder recorrer todas las diferentes partes. Puedes obtener este código en rawbridge.org y contactarme en Twitter en rob underscore rich. También puedes unirte a mí en ese lugar donde la conferencia está designada para preguntas y respuestas en vivo. Gracias por unirte a nosotros aquí en React Advanced London.