Interceptar network requests en Cypress te permite controlar cómo responde tu aplicación frente a peticiones inestables, APIs lentas o servicios de terceros impredecibles. Si trabajas con pruebas automatizadas y has sufrido flaky tests, este enfoque con cy.intercept te ayuda a estabilizarlas y validar el comportamiento real del front-end.

Muchas veces el problema no está en tu código, sino en librerías externas, ambientes de staging con recursos limitados o APIs que responden distinto cada vez. Aquí entra Cypress como aliado para que tus pruebas dejen de fallar por motivos ajenos a tu lógica.

¿Cuál es la diferencia entre cy.request y cy.intercept?

Ambos comandos consultan APIs, pero su propósito es distinto y entenderlo te ahorra horas de depuración.

cy.request lanza una petición directa a una API sin pasar por la interfaz. Sirve para autenticarte, obtener un token o validar respuestas desde el backend. Por ejemplo, una petición a PokeAPI para traer la información de Ditto y validar que el status sea 200 y que el body contenga la propiedad name con el valor esperado.

cy.intercept, en cambio, se queda escuchando las peticiones que tu front-end ejecuta mientras navegas. Eso te permite verificar que tu aplicación realmente está llamando al endpoint correcto cuando el usuario interactúa con un botón o un formulario.

¿Qué hace cy.intercept en Cypress? Intercepta peticiones de red que origina tu aplicación durante la prueba. Puedes esperar su respuesta, validar el statusCode, leer el body o incluso simular respuestas falsas.

¿Cómo configurar un cy.intercept paso a paso?

La estructura básica recibe el método HTTP, la URL a interceptar y un alias para referenciarla luego con cy.wait.

• Define el método: GET, POST, etc.
• Pasa la URL exacta del endpoint que quieres escuchar.
• Asigna un alias con .as('bulbasaur') para esperar esa petición más adelante.

Después de configurar el intercept, visitas la página con cy.visit y disparas la acción que provoca la llamada. En el ejemplo, al hacer clic en el botón "más detalles" de Bulbasaur, se ejecuta una petición específica al endpoint del Pokémon número uno del Pokédex.

¿Cómo encuentro la URL que debo interceptar?

Abre la página en el navegador, entra a las herramientas de desarrollador y ve a la pestaña Network. Recarga, ejecuta la acción que dispara la petición y observa qué URL se llama. Esa es la que pasas a cy.intercept.

En el ejercicio, el botón "más detalles" no es único: aparece en cada uno de los 50 pokémons listados. Para seleccionar el correcto, el truco fue moverse en el DOM con .parent().parent() desde el texto "Bulbasaur", envolver el elemento con cy.wrap, validar que contenga "más detalles" y darle clic.

¿Cómo validar la respuesta de un intercept?

Una vez interceptada la petición, usas cy.wait('@bulbasaur') para detener la prueba hasta que llegue la respuesta. Lo que recibes es un objeto interception que contiene request y response.

Una diferencia clave frente a cy.request: aquí el código de estado se llama statusCode, no status. Y el cuerpo vive dentro de interception.response.body.

Puedes hacer aserciones de dos formas:

• Con .then(interception => {...}) para acceder al objeto completo y validar varias propiedades.
• Con la sintaxis encadenada its('response.statusCode').should('equal', 200) para una validación rápida.

¿Cómo aumento el tiempo de espera de un intercept? Pasa la opción timeout al comando, por ejemplo { timeout: 20000 } para esperar 20 segundos. Útil cuando sabes que la API es lenta.

¿Qué información me devuelve la interceptación?

Al hacer cy.log(interception) ves el panorama completo: el id de la petición, el request con sus headers y body, el estado de completitud y el response con la data que devolvió el servidor. Esto es oro puro para depurar pruebas que fallan sin explicación clara.

¿Cómo simular respuestas con cy.intercept para pruebas más estables?

Aquí está el verdadero superpoder. Puedes forzar la respuesta de una API sin que la petición real llegue al servidor.

Imagina que pruebas un checkout con Stripe. No quieres ejecutar pagos reales en cada corrida. Entonces interceptas el POST a la URL de Stripe y devuelves un objeto fijo como { success: true }. Tu interfaz reacciona como si el pago hubiera funcionado, pero la base de datos y la API de pagos jamás se tocan.

Este patrón sirve para:

• Probar formularios de pago en staging sin ejecutar transacciones reales.
• Simular errores de red para validar el manejo de fallos en tu UI.
• Aislar el front-end de servicios de terceros inestables.

Usa esta técnica con criterio, sobre todo si decides aplicarla en producción. La idea es que tus pruebas reflejen el comportamiento del usuario sin depender de variables que no controlas.

En la siguiente clase vas a ver dos casos más que harán tus pruebas todavía más resilientes. ¿Tú ya usas cy.intercept en tu suite? Cuéntame en los comentarios cómo lo aplicas.