No cometas estos errores de prueba

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

En esta charla, discutiré los errores comunes que cometen los desarrolladores al escribir pruebas en Cypress y cómo evitarlos. Hablaremos sobre pruebas que son demasiado cortas, pruebas que codifican datos, pruebas que compiten contra la aplicación y otros errores. Creo que esta presentación será útil para cualquier persona que escriba pruebas E2E utilizando JavaScript.

This talk has been presented at TestJS Summit - January, 2021, check out the latest edition of this JavaScript Conference.

FAQ

Algunos errores comunes incluyen no entender que las pruebas de Cypress se ejecutan en el navegador, lo que impide ejecutar código que acceda directamente al sistema de archivos. Otro error común es no realizar suficientes afirmaciones en las pruebas de extremo a extremo, lo que puede llevar a pasar pruebas por razones incorrectas.

Para interactuar con el sistema de archivos en Cypress, se debe utilizar el comando 'task', que permite ejecutar código Node.js, incluyendo operaciones sobre el sistema de archivos.

Depende del contexto: para flujos de usuario en una aplicación web, se recomienda una prueba de extremo a extremo. Para probar código individual como funciones o clases, una prueba unitaria es más apropiada. Para probar cómo un servidor responde a peticiones REST o GraphQL, se deben utilizar pruebas de API.

Se recomienda dividir pruebas largas en pruebas más cortas para identificar problemas más rápidamente y permitir la ejecución paralela en CI, lo que mejora la eficiencia y reduce la probabilidad de que el navegador se quede sin memoria y se bloquee.

Es importante alternar comandos y afirmaciones para asegurar que la prueba se ejecute como se espera. Se deben incluir tanto afirmaciones positivas como negativas, pero con cuidado, especialmente con las negativas, para asegurar que representen correctament el estado esperado de la aplicación en ese momento.

Una buena documentación es crucial para ayudar a los usuarios a resolver problemas por sí mismos, lo que puede disminuir la carga en el soporte técnico y mejorar la experiencia del usuario. Cypress ha optimizado su documentación para ser accesible tanto para principiantes como para usuarios avanzados.

Se recomienda primero buscar en la documentación y los problemas reportados en el repositorio de GitHub. Si el problema persiste, se puede abrir un nuevo reporte con detalles específicos que ayuden a reproducir el error para que pueda ser solucionado efectivamente.

Gleb Bahmutov
Gleb Bahmutov
27 min
15 Jun, 2021

Comments

Sign in or register to post your comment.
Video Summary and Transcription
La charla discute los errores comunes en las pruebas de Cypress, como acceder directamente al sistema de archivos en lugar de usar el comando Cypress, y la importancia de escribir pruebas efectivas de Cypress para diferentes escenarios. También enfatiza la necesidad de agregar afirmaciones durante la navegación y alternar comandos y afirmaciones. La charla destaca la importancia de la documentación y ejemplos para brindar soporte y aborda las ventajas de usar el ejecutor de pruebas Cypress Node. Concluye con consejos sobre depuración, pruebas de datos y pruebas de recorridos de usuarios y casos límite.

1. Common Mistakes in Cypress Tests

Short description:

Hola, soy Gleb Bakhmutov de Cypress.io. Quiero hablar sobre los errores comunes que cometen las personas al escribir pruebas en Cypress. Olvidamos que las pruebas de Cypress se ejecutan en el navegador. En lugar de intentar acceder al sistema de archivos y al sistema operativo directamente desde su especificación, utilice el comando Cypress. La tarea es el comando más poderoso que ejecuta el código Node que escribe. Si está probando un flujo de usuario para una aplicación web, es una prueba de extremo a extremo. Si está probando una pieza individual de código, probablemente quiera escribir una prueba unitaria. Si está intentando probar un servidor y cómo responde a una solicitud REST o GraphQL, escriba una prueba de API.

Gracias por invitarme. Quiero hablar sobre los errores comunes que cometen las personas al escribir pruebas en Cypress. Y primero, quiero recordar que todavía estamos en crisis climática. A pesar de la desaceleración de COVID, tenemos que actuar y actuar ahora. Puedes cambiar tu vida o unirte a una organización que lucha junto a ti. Puedes unirte a múltiples organizaciones. Recomiendo ambas opciones aquí.

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.

2. Writing Effective Cypress Tests

Short description:

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 un framework como 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. Bueno, 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.

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.

3. Common Mistakes in Cypress Tests (Cont.)

Short description:

Esta prueba probablemente es demasiado larga. Dividir pruebas largas en pruebas más pequeñas ayuda a detectar problemas más rápido. El uso de archivos de especificación más cortos en ejecuciones de CI puede acelerar la ejecución general de las pruebas y reducir los fallos. Al escribir pruebas de Cypress, ten en cuenta los comandos asíncronos y evita usar variables locales antes de que estén definidas. Otro error común es no tener suficientes afirmaciones en las pruebas de extremo a extremo, lo que puede llevar a un comportamiento inesperado.

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ó.

4. Adding Assertions during Navigation

Short description:

Al navegar por nuestra aplicación, es importante agregar afirmaciones para asegurarnos de que las acciones esperadas hayan finalizado antes de continuar. Por ejemplo, al hacer clic en un enlace, debemos afirmar que la acción se haya completado y luego verificar que el contenido deseado esté presente en la nueva página.

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.

5. Alternating Commands and Assertions

Short description:

En general, alterna comandos y afirmaciones para asegurarte de que el ejecutor de pruebas se comporte como se espera. Ten cuidado con las afirmaciones negativas, ya que pueden llevar a errores. Por ejemplo, si un indicador de carga no es visible, puede pasar antes de que ocurra el evento real. Para evitar esto, siempre incluye una afirmación positiva antes de usar una negativa. Además, es crucial leer la documentación, ya que juega un papel importante en el éxito de los proyectos.

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.

6. Documentation and Examples

Short description:

Nuestros usuarios tuitean o nuestros usuarios tuitean. Optimizamos la estructura de nuestra documentación para principiantes. Colocamos Hello World primero porque hay 10 principiantes por cada usuario avanzado. Raspamos toda nuestra documentación y cada respuesta se puede encontrar mediante búsqueda. Incluso lanzamos un módulo NPM llamado SysSearch que te permite buscar en nuestra documentación directamente desde tu terminal. Mi objetivo personal es tener diez veces más ejemplos y recetas de Cypress de las que tenemos ahora. Resolvemos el problema de mantener los ejemplos actualizados y correctos utilizando un preprocesador de markdown para Cypress que nos permite usar archivos markdown como especificaciones.

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.

7. Providing Support and Documentation

Short description:

Probamos ejemplos, empujamos y publicamos markdown, y creamos páginas de documentación estáticas. No respondemos directamente a preguntas de soporte, pero actualizamos la documentación y proporcionamos enlaces. El objetivo es que los usuarios encuentren respuestas por sí mismos a través de la documentación y ejemplos.

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.

8. Getting Help with Cypress Issues

Short description:

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. Si tienes un problema, te sugiero que primero busques en nuestra documentación. Si no encuentras una respuesta, por favor busca en nuestros problemas de GitHub. Tal vez haya un tema que coincida con tu problema, como visibilidad, origen cruzado, almacenamiento local o red. Si no encuentras un problema que describa tu problema, no te preocupes. Abre uno nuevo, nos encanta. El escenario más probable para que solucionemos tu problema o proporcionemos una solución es que podamos reproducirlo. Ahora puedes usar uno de nuestros repositorios de inicio o preparar tu propio repositorio. Sea lo que sea que hagas, lo más importante es que por favor completes la plantilla del problema.

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.

QnA

Ventajas de Cypress Node Test Runner

Short description:

Por favor, limita tu ejemplo a lo necesario para recrearlo. Lee la documentación para escribir buenos tests. Gracias. Soy Gleb Bakhmutov. Encuéntrame en línea. Cuídate. Las respuestas de la encuesta fueron correctas. La cobertura de código es una buena manera de ver el progreso. Abordemos la primera pregunta de la audiencia sobre la ventaja de usar Cypress Node test runner en comparación con otros runners de prueba existentes como Jest. Queremos proporcionar una mejor experiencia de desarrollo para probar aplicaciones Node, incluyendo la depuración y la ejecución de solicitudes contra un servidor express.

Un atajo que puedes tomar es limitar realmente tu ejemplo a lo que realmente se necesita para recrearlo. Entonces, si no tienes un archivo de complemento o un archivo de soporte, simplemente configúralos como false, para que sepamos que esas cosas no son importantes. Y limítate a un ejemplo reproducible como ese.

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.

Experiencia de depuración y pruebas mejoradas

Short description:

Ese contenedor puede espiar cada solicitud de red, llamadas de acceso al sistema de archivos y otras llamadas de proceso. Proporciona una interfaz gráfica de usuario para ver todas tus pruebas de Node, rastrear el comportamiento del código paso a paso y comprender los fallos sin volver a ejecutar las pruebas. Esto mejora la experiencia de depuración y completa nuestra experiencia general de pruebas.

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.

Pruebas de Datos y Observación de Navegación

Short description:

¿Es bueno usar pruebas de datos o selectores de prueba? Absolutamente. Recomendamos agregar atributos especiales de datos a los elementos que deseas seleccionar. Los selectores dedicados son fáciles de entender y te dan una pista: 'Oye, úsame para tus pruebas'. La siguiente pregunta de Artem: ¿No sería mejor utilizar un await basado en la red para asegurarse de que la navegación haya terminado? ¿Cómo sabes que ha terminado? Bueno, probablemente el usuario vea el cambio de URL. 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.

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.

Pruebas de Trayectoria del Usuario y Casos Extremos

Short description:

Pero no lo conviertas en tu observación principal. 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, hace clic en el carrito y verifica que el número de artículos sea correcto. Intercepta la llamada a la pasarela de pago de terceros y confirma los datos esperados. Comienza con una trayectoria de usuario simple y prueba todos los casos extremos. Divide las pruebas largas en partes, probando cada paso de la trayectoria por separado. ¡Gracias por unirte a nosotros hoy!

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.

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

Solicitudes de Red con Cypress
TestJS Summit 2021TestJS Summit 2021
33 min
Solicitudes de Red con Cypress
Top Content
Cecilia Martinez, a technical account manager at Cypress, discusses network requests in Cypress and demonstrates commands like cydot request and SCI.INTERCEPT. She also explains dynamic matching and aliasing, network stubbing, and the pros and cons of using real server responses versus stubbing. The talk covers logging request responses, testing front-end and backend API, handling list length and DOM traversal, lazy loading, and provides resources for beginners to learn Cypress.
Pruebas de Aplicaciones Web con Playwright
TestJS Summit 2022TestJS Summit 2022
20 min
Pruebas de Aplicaciones Web con Playwright
Top Content
Testing web applications with Playwright, a reliable end-to-end testing tool. Playwright offers fast execution, powerful tooling, and support for multiple languages. It provides precise selectors, web-first assertions, and code generation for easy testing. Playwright also offers features like live debugging, tracing, and running tests on CI. The future of Playwright aims to make testing easy and fun, with a focus on creating frustration-free web experiences.
Pruebas de ciclo completo con Cypress
TestJS Summit 2022TestJS Summit 2022
27 min
Pruebas de ciclo completo con Cypress
Top Content
Cypress is a powerful tool for end-to-end testing and API testing. It provides instant feedback on test errors and allows tests to be run inside the browser. Cypress enables testing at both the application and network layers, making it easier to reach different edge cases. With features like AppActions and component testing, Cypress allows for comprehensive testing of individual components and the entire application. Join the workshops to learn more about full circle testing with Cypress.
Desarrollo Efectivo de Pruebas
TestJS Summit 2021TestJS Summit 2021
31 min
Desarrollo Efectivo de Pruebas
Top Content
This Talk introduces Test Effective Development, a new approach to testing that aims to make companies more cost-effective. The speaker shares their personal journey of improving code quality and reducing bugs through smarter testing strategies. They discuss the importance of finding a balance between testing confidence and efficiency and introduce the concepts of isolated and integrated testing. The speaker also suggests different testing strategies based on the size of the application and emphasizes the need to choose cost-effective testing approaches based on the specific project requirements.
Playwright Test Runner
TestJS Summit 2021TestJS Summit 2021
25 min
Playwright Test Runner
Top Content
The Playwright Test Runner is a cross-browser web testing framework that allows you to write tests using just a few lines of code. It supports features like parallel test execution, device emulation, and different reporters for customized output. Code-Gen is a new feature that generates code to interact with web pages. Playwright Tracing provides a powerful tool for debugging and analyzing test actions, with the ability to explore trace files using TraceViewer. Overall, Playwright Test offers installation, test authoring, debugging, and post-mortem debugging capabilities.

Workshops on related topic

Diseñando Pruebas Efectivas con la Biblioteca de Pruebas de React
React Summit 2023React Summit 2023
151 min
Diseñando Pruebas Efectivas con la Biblioteca de Pruebas de React
Top Content
Featured Workshop
Josh Justice
Josh Justice
La Biblioteca de Pruebas de React es un gran marco para las pruebas de componentes de React porque responde muchas preguntas por ti, por lo que no necesitas preocuparte por esas preguntas. Pero eso no significa que las pruebas sean fáciles. Todavía hay muchas preguntas que tienes que resolver por ti mismo: ¿Cuántas pruebas de componentes debes escribir vs pruebas de extremo a extremo o pruebas de unidad de nivel inferior? ¿Cómo puedes probar una cierta línea de código que es difícil de probar? ¿Y qué se supone que debes hacer con esa persistente advertencia de act()?
En esta masterclass de tres horas, presentaremos la Biblioteca de Pruebas de React junto con un modelo mental de cómo pensar en el diseño de tus pruebas de componentes. Este modelo mental te ayudará a ver cómo probar cada bit de lógica, si debes o no simular dependencias, y ayudará a mejorar el diseño de tus componentes. Te irás con las herramientas, técnicas y principios que necesitas para implementar pruebas de componentes de bajo costo y alto valor.
Tabla de contenidos- Los diferentes tipos de pruebas de aplicaciones de React, y dónde encajan las pruebas de componentes- Un modelo mental para pensar en las entradas y salidas de los componentes que pruebas- Opciones para seleccionar elementos DOM para verificar e interactuar con ellos- El valor de los mocks y por qué no deben evitarse- Los desafíos con la asincronía en las pruebas de RTL y cómo manejarlos
Requisitos previos- Familiaridad con la construcción de aplicaciones con React- Experiencia básica escribiendo pruebas automatizadas con Jest u otro marco de pruebas unitarias- No necesitas ninguna experiencia con la Biblioteca de Pruebas de React- Configuración de la máquina: Node LTS, Yarn
Detox 101: Cómo escribir pruebas de extremo a extremo estables para su aplicación React Native
React Summit 2022React Summit 2022
117 min
Detox 101: Cómo escribir pruebas de extremo a extremo estables para su aplicación React Native
Top Content
Workshop
Yevheniia Hlovatska
Yevheniia Hlovatska
A diferencia de las pruebas unitarias, las pruebas de extremo a extremo buscan interactuar con su aplicación tal como lo haría un usuario real. Y como todos sabemos, puede ser bastante desafiante. Especialmente cuando hablamos de aplicaciones móviles.
Las pruebas dependen de muchas condiciones y se consideran lentas e inestables. Por otro lado, las pruebas de extremo a extremo pueden dar la mayor confianza de que su aplicación está funcionando. Y si se hace correctamente, puede convertirse en una herramienta increíble para aumentar la velocidad del desarrollador.
Detox es un marco de pruebas de extremo a extremo en caja gris para aplicaciones móviles. Desarrollado por Wix para resolver el problema de la lentitud e inestabilidad y utilizado por React Native en sí como su herramienta de pruebas E2E.
Únete a mí en esta masterclass para aprender cómo hacer que tus pruebas de extremo a extremo móviles con Detox sean excelentes.
Prerrequisitos- iOS/Android: MacOS Catalina o más reciente- Solo Android: Linux- Instalar antes de la masterclass
Masterclass de Pruebas de API con Postman
TestJS Summit 2023TestJS Summit 2023
48 min
Masterclass de Pruebas de API con Postman
Top Content
WorkshopFree
Pooja Mistry
Pooja Mistry
En el panorama siempre en evolución del desarrollo de software, garantizar la fiabilidad y funcionalidad de las API se ha vuelto primordial. "Pruebas de API con Postman" es una masterclass completa diseñada para equipar a los participantes con los conocimientos y habilidades necesarios para sobresalir en las pruebas de API utilizando Postman, una herramienta poderosa ampliamente adoptada por profesionales en el campo. Esta masterclass profundiza en los fundamentos de las pruebas de API, avanza a técnicas de prueba avanzadas y explora la automatización, las pruebas de rendimiento y el soporte multiprotocolo, proporcionando a los asistentes una comprensión holística de las pruebas de API con Postman.
Únete a nosotros para esta masterclass para desbloquear todo el potencial de Postman para las pruebas de API, agilizar tus procesos de prueba y mejorar la calidad y fiabilidad de tu software. Ya seas un principiante o un probador experimentado, esta masterclass te equipará con las habilidades necesarias para sobresalir en las pruebas de API con Postman.
Monitoreo 101 para Desarrolladores de React
React Summit US 2023React Summit US 2023
107 min
Monitoreo 101 para Desarrolladores de React
Top Content
WorkshopFree
Lazar Nikolov
Sarah Guthals
2 authors
Si encontrar errores en tu proyecto frontend es como buscar una aguja en un pajar de código, entonces el monitoreo de errores de Sentry puede ser tu detector de metales. Aprende los conceptos básicos del monitoreo de errores con Sentry. Ya sea que estés ejecutando un proyecto de React, Angular, Vue, o simplemente JavaScript “vainilla”, mira cómo Sentry puede ayudarte a encontrar el quién, qué, cuándo y dónde detrás de los errores en tu proyecto frontend.
Nivel de la masterclass: Intermedio
Testing Web Applications Using Cypress
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
Top Content
Workshop
Gleb Bahmutov
Gleb Bahmutov
Esta masterclass te enseñará los conceptos básicos para escribir pruebas end-to-end útiles utilizando Cypress Test Runner.
Cubriremos la escritura de pruebas, cubriendo cada característica de la aplicación, estructurando pruebas, interceptando solicitudes de red y configurando los datos del backend.
Cualquiera que conozca el lenguaje de programación JavaScript y tenga NPM instalado podrá seguir adelante.
Mejores Prácticas para Escribir y Depurar Pruebas de Cypress
TestJS Summit 2023TestJS Summit 2023
148 min
Mejores Prácticas para Escribir y Depurar Pruebas de Cypress
Top Content
Workshop
Filip Hric
Filip Hric
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.