No cometas estos errores de prueba

En esta presentación, cubriré los errores comunes en las pruebas de Cypress. Y luego hablaré sobre algo que estamos tratando de hacer para minimizar la cantidad de errores, mejorando nuestra documentación. Terminaré con una discusión sobre nuestro repositorio de GitHub. Puedes encontrar las diapositivas en línea y si tienes preguntas, encuéntrame en Twitter.

Comencemos con los errores de Cypress. Cuando las personas comienzan a escribir pruebas de Cypress, olvidamos que las pruebas de Cypress se ejecutan en el navegador. Sé que es un hecho simple, pero es fácil escribir algo como esto, requerir el módulo del sistema de archivos y luego intentar leer el archivo. Bueno, esto nunca funcionará porque la prueba de Cypress se ejecuta en el navegador. No podrías ejecutar este código en el código del navegador de tu aplicación, ¿verdad? Entonces, en lugar de intentar acceder al sistema de archivos y al sistema operativo directamente desde su especificación, debes usar el comando Cypress que proporcionamos para acceder al sistema de archivos, código Node y tu sistema operativo. Puedes leer archivos, escribir archivos, ejecutar cualquier programa o ejecutar código Node usando la tarea.

La tarea es el comando más poderoso, es el que ejecuta el código Node que escribes. Por ejemplo, un caso de uso muy común es intentar conectarse a una base de datos. Por ejemplo, si quieres restablecer la base de datos antes de comenzar una prueba. Si escribes tu archivo de complemento de esta manera, se ejecuta en Node, puedes reutilizar parte de tu aplicación código para conectarte a la base de datos y luego, por ejemplo, truncar la tabla en una tarea. Tenemos muy buenos ejemplos de truncar la base de datos y volver a sembrarla con datos en nuestra aplicación real de Cypress. Puedes ver que estamos ejecutando la tarea DB seed antes de cada prueba.

Un pequeño detalle que quiero señalar, si miras los nombres de los archivos de especificación, bueno, aquí tienes un ejemplo de prueba de API y aquí tienes un ejemplo de una prueba de interfaz de usuario. Un error muy común es no elegir el tipo correcto de prueba. Si tu prueba es difícil de escribir, difícil de mantener, tiene mucho código repetitivo, bueno, tal vez elegiste el tipo de prueba incorrecto y estás luchando contra la corriente. Si estás probando un flujo de usuario para una aplicación web, es una prueba de extremo a extremo. Si estás probando una pieza individual de código como una función o una clase, probablemente quieras escribir una prueba unitaria. Si estás intentando probar un servidor y cómo responde a una solicitud REST o una solicitud de GraphQL, querrás escribir una prueba de API.

Si quieres ver cómo se ve una página y si se ve igual, o tal vez haya cambiado algún estilo CSS, no quieres usar afirmaciones individuales. Quieres hacer una prueba visual que compare la página o un elemento píxel por píxel. Si quieres probar un componente individual de React, Vue o Angular, quieres escribir una prueba de componente. Si quieres ver cómo se comporta tu página en una resolución diferente, quieres ejecutar una prueba de extremo a extremo con una vista diferente. Si quieres probar la accesibilidad, quieres escribir una prueba de accesibilidad utilizando un complemento.

Por último, si quieres ejecutar código Node, no el código del navegador, sino código Node, y probarlo. No puedes hacerlo con Cypress en la actualidad, pero mantente atento porque estamos trabajando en el Cypress Node test runner.

A menudo vemos pruebas de extremo a extremo que son demasiado cortas. Por otro lado, a veces vemos pruebas que son demasiado largas. Es un poco contradictorio. No quieres tener demasiado dinero o no tener suficiente dinero. Pero aquí tienes un ejemplo de una prueba demasiado corta. Creo que estas pruebas fueron escritas por alguien que está acostumbrado a las pruebas unitarias donde cada prueba solo tiene una afirmación. En este caso, estamos obteniendo un elemento de entrada y haciendo una afirmación para cada atributo en una prueba separada. Esto es demasiado corto. No es productivo. Recomendamos poner todas las afirmaciones relacionadas con ese elemento en una sola prueba.

Por otro lado, esta prueba probablemente es demasiado larga. Esta prueba recorre varios campos en múltiples páginas, llenándolos uno por uno. Creo que esta prueba tarda demasiado tiempo en ser efectiva. Imagina que estás trabajando en una función y tienes que hacer un cambio en tu código y luego esperar 30 segundos, un minuto, cinco minutos, solo para volver a pasar por todos los pasos una y otra vez. No eres muy productivo.

Si divides las pruebas largas en pruebas más pequeñas, en realidad detectarás el problema más rápido porque cuando la prueba falla, sabrás exactamente qué función ha fallado. Si divides archivos de especificación largos en archivos de especificación más cortos, entonces tu CI podrá ejecutar esos archivos de especificación en paralelo, acelerando la ejecución general de las pruebas. Y siendo honestos, cuanto más larga sea la prueba, mayor será la probabilidad de que el navegador se quede sin memoria y se bloquee, por lo que tendrás menos fallos en el CI si usas especificaciones más cortas.

Recuerda que al escribir una prueba de Cypress, todos los comandos son asíncronos y también se encolan para ejecutarse uno tras otro. Un error muy común es usar una variable local, como nombre de usuario, y luego ejecutar visit y encontrar el elemento. Pero recuerda, esos comandos no se ejecutaron. Solo se encolaron. Entonces, si intentas acceder a esa variable de inmediato, ¿adivina qué? Todavía será indefinida en este momento, por lo que la rama else siempre se ejecutará y tu rama if nunca se ejecutará. Lo correcto es mover todo el código que obtiene el elemento dentro del callback then que se ejecuta después de visitar la página y encontrar el elemento. Y luego podemos hacer clic en el elemento correcto dependiendo del texto del elemento. Hemos discutido esta cuestión sobre la concatenación de comandos en nuestras presentaciones, y también nuestra documentación detalla y proporciona muchos ejemplos de pruebas correctas e incorrectas. Otro ejemplo común al escribir pruebas de extremo a extremo es no tener suficientes afirmaciones. Este es un ejemplo de una prueba de navegación. Va a la página de inicio, encuentra el enlace a la página Acerca de, hace clic en él, confirma que vamos a la página Acerca de, luego hace clic en el enlace para ir a la página de usuario. Este es el flujo que queremos probar. Y la prueba parece razonable. De hecho, se completa. Terminamos en la página de usuario. Pero si te fijas bien, hay algunas señales de alerta. Por ejemplo, cuando hacemos clic en el enlace Acerca de, el registro de comandos de Cypress afirma que hicimos clic en un elemento invisible. También parece que encontramos el texto de usuario antes de navegar a la página de usuario. ¿Cómo es posible? Bueno, en este caso, podemos usar el comando site post y revisar la prueba paso a paso o usar el depurador de viaje en el tiempo y repasar los comandos para ver qué sucedió y cómo se veía la página en ese momento particular. Por ejemplo, si vamos al comando get que encuentra el texto Acerca de en una página, bueno, usamos ese comando para verificar que estamos en la página Acerca de, pero mira lo que sucedió.

Accidentalmente encontramos el texto 'about' en la página principal en lugar de en la página Acerca de. Por lo tanto, en realidad pasamos esta prueba accidentalmente y por la razón equivocada. Lo que queremos hacer, especialmente cada vez que navegamos, es agregar afirmaciones. Por ejemplo, si hacemos clic en el enlace de la página Acerca de, nuestra aplicación hará algo en respuesta. Entonces, antes de hacer otro comando, queremos afirmar que esa acción haya finalizado, pero en realidad navegamos a la página Acerca de y luego queremos asegurarnos de que el texto esté allí. Si observamos el resultado y nos colocamos sobre el comando contains, ahora podemos ver claramente que estamos en la página Acerca de y encontramos el texto que esperamos encontrar.

En general, al igual que una cebra, intenta alternar comandos y afirmaciones para asegurarte de que el ejecutor de pruebas no se aleje de la aplicación y, de hecho, haga lo que esperas que haga. Al agregar afirmaciones, puedes agregar afirmaciones positivas. Por ejemplo, tratar de encontrar elementos y asegurarte de que se encuentren dos elementos y que cada uno tenga una clase completada es una afirmación positiva. Pero las afirmaciones que comienzan con palabras clave NOT, como un elemento no debe tener la clase completada o el elemento de carga no debe ser visible, se llaman afirmaciones negativas.

Ten cuidado con las afirmaciones negativas. Es fácil cometer un error. Aquí tienes un ejemplo. Imagina que mi aplicación está cargando data. Mientras se carga el data, muestra un indicador de carga. Escribes una prueba que visita una página y luego dice que el indicador de carga no debe ser visible. Bueno, la prueba pasa, todo está bien, ¿verdad? Bueno, hay algunas señales de alerta. Observa la afirmación negativa. El indicador de carga no es visible. Pero parece que ocurre antes de que se realice la solicitud Ajax. ¿Cómo es posible? Bueno, investiguemos. En mi aplicación en particular, puedo retrasar la carga de data pasando un parámetro de consulta. ¿Cómo se ve ahora? Bueno, la prueba termina y luego vemos la carga de data. Algo está mal. Nuestra afirmación negativa pasa antes de que ocurra el evento real. Y eso es correcto. Nuestra aplicación no muestra el indicador de carga de forma predeterminada. Entonces, nuestra afirmación pasa inmediatamente, incluso antes de cargar el data. La solución que suelo recomendar es tener siempre una afirmación positiva que verifique si la acción comienza antes de usar una afirmación negativa. En este caso, la afirmación positiva es que el elemento de carga debe ser visible y luego debe ser invisible, y ahora pasa. Esta prueba no es la mejor prueba en realidad porque es inestable debido a que el indicador de carga es tan rápido. Lo que realmente queremos hacer es asegurarnos de ralentizar la solicitud usando el comando intercept de Cypress, y luego es claramente visible y desaparece.

El mayor error, creo, en todo esto es que la gente se salta la lectura de la documentación. Si no lees la documentación, estás cometiendo un error. Sabemos que la documentación hace o deshace proyectos. Lo podemos ver.

Nuestros usuarios tuitean o nuestros usuarios tuitean. Por ejemplo, mi organización estaba evaluando un framework de automatización. Yo estaba a favor de Playwright, pero Cypress ganó debido a la percepción de tener más documentación disponible y soporte de la comunidad. Creo que ganamos por la razón correcta. Cada vez que leo nuestro foro de soporte y chat, siento dolor porque veo tantas preguntas, y cada vez que un usuario tiene una pregunta. En mi opinión, es un fracaso de la documentación, probablemente será un problema de soporte, o tal vez un cliente perdido para el panel de Cypress.

Realmente queremos que nuestros usuarios encuentren todas las preguntas por sí mismos. Desafortunadamente, escribir una buena documentación es difícil porque a menudo es contradictoria. Algunos usuarios necesitan que se respondan las preguntas en un orden diferente. Por ejemplo, un visitante por primera vez podría preguntar: `muéstrame Hello World`, mientras que un usuario recurrente podría preguntar: `muéstrame cómo hacer x primero`. Y estas demandas son contradictorias. Hemos optimizado la estructura de nuestra documentación para principiantes. Colocamos Hello World primero porque creemos que hay 10 principiantes por cada usuario avanzado. Cada usuario avanzado solía ser un principiante. Luego agregamos toda nuestra documentación a nuestra estructura. Raspamos toda nuestra documentación y cada respuesta se puede encontrar mediante búsqueda. Incluso raspamos no solo nuestra documentación, sino también nuestras publicaciones de blog y nuestros ejemplos para que puedas encontrar toda la información. Incluso miro las búsquedas sin resultados. Luego tomo esas búsquedas y escribo documentación para responder esas preguntas. Ni siquiera tienes que usar el navegador para buscar en nuestra documentación. Lanzamos un módulo NPM llamado SysSearch que te permite buscar en nuestra documentación directamente desde tu terminal para que nunca salgas de tu entorno favorito.

Si quieres saber más sobre cómo estructuramos nuestra documentación y resolvemos este problema, tenemos un par de presentaciones. Mi objetivo personal es tener diez veces más ejemplos y recetas de Cypress de las que tenemos ahora en todas nuestras propiedades de documentación, documentos, ejemplos, publicaciones de blog e incluso videos. El gran problema ahí es mantener los ejemplos actualizados y correctos. No hay nada peor que encontrar un ejemplo, copiarlo y luego descubrir que no funciona. Aquí tienes un ejemplo de cómo lo resolvemos. Imagina que hay una pregunta en un chat. ¿Cómo cambio el estado de una casilla de verificación? Veo esa pregunta y comienzo a escribir un documento markdown donde describo la pregunta y proporciono HTML para la miniaplicación web que la tiene. Luego escribo mi código de prueba en un bloque de JavaScript. Bueno, tenemos un preprocesador de markdown para Cypress que nos permite usar archivos markdown como especificaciones.

Así que probamos esos ejemplos. Luego empujamos y publicamos ese markdown. Se convierte en una página de documentación estática. Y luego respondo la pregunta original con un enlace. Por supuesto, esas páginas de documentación han sido raspadas y están disponibles para cualquiera que quiera encontrar la respuesta más tarde. Por lo tanto, no respondemos directamente a preguntas de soporte, especialmente para soporte privado, porque no es escalable, porque tendríamos que hacerlo una y otra vez. En su lugar, actualizamos la documentación, creamos un nuevo ejemplo o escribimos una publicación de blog o una receta, y luego respondemos con un enlace, como puedes ver en mi ejemplo. Creo que el equipo de soporte realmente debería automatizar sus propios trabajos, pero escribiendo más documentación y más documentación, me refiero a ejemplos, hasta que todos los usuarios puedan encontrar las respuestas por sí mismos.

Así que quiero terminar con algo importante. Muchas personas comentan en nuestros problemas de GitHub y están enojadas y frustradas porque no hay soluciones para sus problemas. Bueno, tenemos muchos problemas abiertos en nuestro repositorio. Nuestro número de problemas cada mes es tremendo. Por ejemplo, en enero tuvimos 300 problemas en nuestro repositorio. Cerramos 200, pero 78 quedaron abiertos.

Un solo período de 24 horas muestra mucha actividad. Aún peor es el número de menciones, comentarios y actualizaciones que ocurren todos los días. Esta es mi bandeja de entrada y muestra solo correos electrónicos de Cypress.io. Repositorio de Cypress en un período de aproximadamente 30 horas. Hay mucha actividad en nuestro ejecutor de pruebas. Como puedes ver, leo la mayoría de ellos.

Si tienes un problema, te sugiero que primero busques en nuestra documentación. Como he mostrado, hemos puesto mucho esfuerzo en los documentos y búsquedas. Si no encuentras una respuesta, por favor busca en nuestros problemas de GitHub. A veces, la búsqueda de texto en GitHub es mala. Entonces, lo que puedes hacer en su lugar es mirar la etiqueta que comienza con el tema. Tenemos alrededor de 60 temas. Tal vez haya un tema que coincida con tu problema, como visibilidad, origen cruzado, almacenamiento local o red. Haz clic en esa etiqueta y busca entre los problemas. Abre y cierra. Tal vez ya haya un problema que describa tu problema.

Si no encuentras un problema que describa tu problema, no te preocupes. Abre uno nuevo, nos encanta. Entonces, el escenario más probable para que solucionemos tu problema o proporcionemos una solución es que podamos reproducirlo. Si podemos ejecutar el código y ver el problema nosotros mismos, las posibilidades de que podamos solucionarlo son altas. Ahora puedes usar uno de nuestros repositorios de inicio, como Cypress Test Tiny o ejemplos de recetas de Cypress, como base para tu reproducción. O puedes preparar tu propio repositorio que podamos instalar y ejecutar. Sea lo que sea que hagas, lo más importante es que por favor completes la plantilla del problema. A veces recibimos problemas en los que solo vemos una captura de pantalla o un fragmento de código personalizado que dice que no funciona. ¿No funciona en qué versión de Cypress, qué esperas ver? ¿Ves algún error en la consola? No tenemos idea.

Quiero dejarte con el último consejo para resumir. Para que puedas escribir buenos tests sin errores, por favor lee la documentación. Gracias. Soy Gleb Bakhmutov. Encuéntrame en línea. Y también encuentra las diapositivas aquí. Muchas gracias. Cuídate.

Hola a todos. ¡Hola! ¿Qué piensan? ¿Las respuestas fueron correctas para la encuesta? Las respuestas fueron absolutamente correctas. Yo mismo elegí la cobertura de código porque me gusta ver esa insignia verde de cobertura de código. Pensé que más personas elegirían todas las anteriores. Así que esto significa que aún hay margen de mejora para Cypress y hacer que sea más divertido escribir tests. Sí. Esa cobertura no es el objetivo, pero es una buena manera de ver qué tan bien lo estás haciendo. En mi trabajo actual, me contrataron para ayudar a mejorar las pruebas y pasé del 12% al 80%, ese era mi trabajo. O fue del 17% al 70%... No recuerdo los porcentajes exactos, pero eso es como, sí, hice un buen trabajo. Así que espero que las personas también sientan esa satisfacción cuando su porcentaje de cobertura aumente. Pero la gente está aquí para hacer preguntas. Así que pasemos a la primera pregunta de la audiencia. Tengo una pregunta de Marcus, ¿cuál sería la ventaja de usar el Cypress Node test runner en comparación con otros runners de prueba existentes, como por ejemplo Jest? Entonces estábamos pensando, ¿verdad? ¿Cuál es tu experiencia de desarrollo al escribir pruebas en Node? Y no estoy hablando de pruebas unitarias, como la pieza más pequeña. ¿Qué pasa si quieres probar tu servidor express? Iniciarlo y luego ejecutar solicitudes contra él y ver qué hace. Y si hay un fallo, ¿cómo es tu experiencia de depuración cuando la prueba falla? ¿Verdad? Así que estábamos pensando en hacer lo mismo que hemos hecho para las pruebas de navegador. ¿Verdad? Eso significa tener un contenedor donde se ejecute tu proceso Node, donde puedas absorber todo.

Ese contenedor puede espiar cada solicitud de red. También puede espiar todas las llamadas de acceso al sistema de archivos y otras llamadas de proceso. ¿Verdad? Y te proporcionará una interfaz gráfica de usuario. Así podrás ver todas tus pruebas de Node, al igual que ves las pruebas de extremo a extremo y todos los comandos en una prueba. Y luego podrás rastrear cómo se comporta tu código para cada paso de una prueba. ¿De acuerdo? Por lo tanto, esta experiencia de depuración, la interfaz gráfica de usuario, los resultados de las pruebas, la capacidad de volver atrás a la prueba fallida y no volver a ejecutarla, ¿verdad? Como haces ahora. Pero en realidad, poder comprender el fallo paso a paso, eso será diferente. Así que eso es lo que se añade... Básicamente, es para completar nuestra experiencia, si puedo resumirlo así. Sí. Sí. De acuerdo. Gracias.

La siguiente pregunta es de Lias. ¿Es bueno usar pruebas de datos o selectores de prueba? Absolutamente. Así lo creemos. Recomendamos agregar atributos especiales de datos a los elementos que deseas seleccionar. Por ejemplo, un botón para hacer clic o un texto para una afirmación. Tenemos una guía de mejores prácticas en nuestra documentación que explica nuestra lógica. Creemos que los selectores dedicados son fáciles de entender y te dan una pista: 'Oye, úsame para tus pruebas'. No me elimines. Está bien. No me cambies accidentalmente como puedes hacer con las clases. A mucha gente le gusta usar la biblioteca de pruebas Cypress que selecciona por rol, por etiqueta, por formulario de entrada. También lo alentamos absolutamente. Si descubres que escribes mejores pruebas usando la biblioteca de pruebas Cypress, también usa esos selectores. Solo asegúrate de no usar selectores extraños como XPath profundos. Correcto. Eso es lo único. De acuerdo. La siguiente pregunta es de Artem. ¿No sería mejor utilizar un await basado en la red para asegurarse de que la navegación haya terminado? Correcto. Cuando escribes una prueba de Cypress y visitas la página o haces clic en un botón, navega a otra página. ¿Cómo sabes que ha terminado? Correcto. ¿Cómo sabe tu usuario que ha terminado? Bueno, probablemente el usuario vea el cambio de URL. Correcto. Esa es una forma. Otra forma es que el usuario vea la nueva página. Al usuario no le importa si hay una llamada de red que ocurra. No, el usuario quiere ver la página actualizada. Por lo tanto, te recomendamos observar la página, al igual que el usuario, y saber que has terminado la página de esa manera. Puedes observar las llamadas de red si, por ejemplo, espías los datos, si estás confirmando el comportamiento profundo de tu aplicación.

Pero no lo conviertas en tu observación principal, diría yo. Así que te conectas con la ideología de, bueno, lo has mencionado, la biblioteca de testing que prueba tanto como sea posible como el usuario real. Sí. Sí. Sí.

Tercera pregunta de Artem. Oh no, esa es la que acabamos de responder. Lo siento. Una pregunta de nof3412. ¿Cuál sería un buen patrón para probar una trayectoria de usuario más grande, como una experiencia de compra sin finalizar la compra? Ve por toda la historia, simplemente escribe la prueba que carga la página, selecciona un artículo, lo coloca en el carrito, selecciona otro artículo, lo coloca en el carrito, verifica, ya sabes, hace clic en el carrito, verifica que el número de artículos sea correcto. Conoces la información de pago, la información de envío y luego haces clic en enviar. Ahora, cuando haces clic en enviar, no quieres que esa llamada vaya realmente a una pasarela de pago de terceros, ¿verdad? Probablemente quieras interceptar esa llamada en tu prueba usando nuestro subcomando scientist y confirmar que lo que va a la tercera parte es lo que realmente ingresaste y esperas, ¿verdad? Entonces escribes la prueba completa, pero luego comienzas a testing todos los casos extremos, ¿verdad? ¿Qué sucede si la información de envío es incorrecta, verdad? Luego puedes omitir y dividir esa prueba larga en partes, ya sabes, seleccionar artículos sería una prueba, pero tal vez, ya sabes, ingresar información de envío, ¿verdad? Así que comienza con una trayectoria de usuario simple hasta el final, tal vez detén la llamada saliente, confirma que se envía correctamente y eso será una prueba.

De acuerdo, de acuerdo. Esa es la última pregunta que podemos responder. No tenemos más tiempo. Pero si haces una pregunta en el chat y necesitas esa dulce y valiosa respuesta, GLEB estará en su sala de conferencias disponible. Así que ve aquí abajo al horario, haz clic en la sala de conferencias y GLEB estará allí en breve. GLEB, quiero agradecerte mucho por unirte a nosotros hoy y espero verte nuevamente pronto. Absolutamente. Gracias por tenerme. Feliz testing a todos. Cuídense. Adiós.