Cypress espera automáticamente por los elementos, pero en escenarios reales necesitas controlar ese comportamiento. Aprenderás a usar cy.wait, ajustar el timeout por comando y deshabilitar el retry para que tus pruebas end to end sean más rápidas, estables y predecibles.

Esto te sirve si automatizas pruebas con Cypress y quieres entender cuándo conviene una espera fija, cuándo una espera por elemento y cómo combinar aserciones sin romper la lógica de reintentos.

¿Por qué Cypress ya espera por los elementos automáticamente?

Cypress incluye una espera implícita por defecto. Cada vez que ejecutas un comando como cy.get, la herramienta reintenta encontrar el elemento durante un tiempo determinado antes de fallar.

Ese timeout por defecto es de cuatro segundos por elemento [00:55]. Por eso, en la mayoría de pruebas anteriores no necesitaste escribir esperas manuales: Cypress ya lo hacía por ti detrás de escena con un mecanismo de retry que vuelve a intentar el comando hasta que el elemento aparece o se agota el tiempo.

¿Qué hace cy.wait en Cypress? Pausa la ejecución de la prueba durante un tiempo fijo en milisegundos. Es una espera explícita que se ejecuta sí o sí, encuentre el elemento o no.

¿Cómo se usa cy.wait con un tiempo definido?

La primera forma de espera es la más directa: pausar la prueba durante un número exacto de milisegundos. Se escribe así:

javascript cy.wait(5000)

Esto detiene la prueba cinco segundos antes de continuar [01:30]. Funciona, pero tiene un costo claro: si el elemento aparece en el segundo dos, igual esperarás los otros tres segundos en vano.

Por eso esta opción debe ser tu última alternativa. Úsala solo cuando el elemento ya está visible, ya está en el DOM, pero por alguna razón ajena a tu control la acción no se dispara correctamente. Un gran poder conlleva una gran responsabilidad.

¿Cómo esperar por un elemento específico con cy.get?

La forma elegante de esperar es apuntar directamente al elemento. Cypress reintenta hasta encontrarlo:

javascript cy.get('.button-login-CTA')

Si necesitas más de los cuatro segundos por defecto, puedes pasar un objeto con la propiedad timeout:

javascript cy.get('.button-login-CTA', { timeout: 6000 })

Esto le dice a Cypress que reintente durante seis segundos antes de marcar la prueba como fallida [03:10]. La diferencia con cy.wait es enorme: si el elemento aparece al segundo uno, la prueba sigue al instante.

¿Cómo combinar timeout con aserciones tipo should?

Aquí hay un detalle importante. Cuando encadenas una aserción como should('be.visible'), el timeout debe ir en el comando que devuelve el elemento, no en el should.

Forma correcta:

javascript cy.get('.button-login-CTA', { timeout: 6000 }).should('be.visible')

Forma incorrecta:

javascript cy.get('.button-login-CTA').should('be.visible', { timeout: 6000 })

¿Por qué importa? Porque el motor de reintentos necesita aplicar el tiempo al comando que localiza el elemento, no a la validación. Si lo pones en el should, el comportamiento de retry se rompe y el resultado no será el que esperas.

¿Cómo deshabilitar el retry en Cypress?

A veces no quieres que Cypress reintente. Quieres validar que el elemento aparezca de inmediato, sin tolerancia. La forma de lograrlo es pasar un timeout de cero:

javascript cy.get('.banner-image', { timeout: 0 })

Con esto deshabilitas el reintento por completo [06:20]. Si el elemento no está exactamente en ese momento, la prueba falla. Es útil cuando quieres comprobar renderizados instantáneos o cuando estás depurando una prueba que se comporta de forma inconsistente.

¿Cuándo conviene poner timeout en cero? Cuando necesitas que un elemento esté presente de manera inmediata, sin esperas ni reintentos. Útil para validar carga inicial o estados sincrónicos.

Cómo organizar tus esperas dentro de un beforeEach

Una buena práctica es mover la navegación a un bloque beforeEach, de manera que cada prueba arranque desde el mismo punto.

javascript beforeEach(() => { cy.visit('https://platzi.com') })

Así evitas repetir código y dejas el cuerpo de cada it enfocado en lo que realmente quieres probar: la espera, la aserción o la interacción específica.

Diferencia clave entre wait fijo y timeout dinámico

Esta es la idea que cambia el performance de tus pruebas:

• cy.wait(10000) espera siempre diez segundos, encuentre o no el elemento.
• cy.get(selector, { timeout: 10000 }) reintenta hasta diez segundos, pero si encuentra el elemento al segundo cinco, sigue avanzando.
• Cero significa sin reintento; cuatro mil es el valor por defecto; cualquier número intermedio te da margen sin sacrificar velocidad.

La diferencia entre una suite lenta y una suite rápida muchas veces está en este detalle. Cada cy.wait innecesario suma segundos muertos al pipeline.

Después de dominar las esperas, el siguiente paso es ejecutar tus pruebas sin la interfaz visual, usando el famoso modo headless y scripts personalizados en tu package.json. ¿Qué estrategia de espera estás usando hoy en tus pruebas? Cuéntalo en los comentarios.