Forzar fallos de red y modificar el cuerpo de una respuesta con cy.intercept te permite validar cómo reacciona tu front-end ante escenarios reales sin tocar el backend. Aprende a simular errores HTTP y a cambiar payloads para detectar bugs de UI que de otra forma pasarían desapercibidos en pruebas QA con Cypress.

¿Cómo forzar un error de red con cy.intercept?

Cuando quieres comprobar si tu interfaz maneja bien la caída de un servidor, puedes interceptar la petición y destruir la conexión antes de que llegue una respuesta. Esto se hace con la propiedad forceNetworkError dentro del objeto que pasas como tercer argumento de cy.intercept.

js cy.intercept('GET', 'https://pokeapi.co/api/v2/pokemon-species/1', { forceNetworkError: true }).as('error');

Al correr la prueba, Cypress destruye la conexión y la API responde con un error tipo force network error code. En el ejemplo de la clase, la app se quedó congelada en estado de loading porque el desarrollo no contempló un manejo de error. Y ahí está justo el valor de la prueba [01:45].

¿Para qué sirve forzar un error de red en Cypress? Sirve para validar cómo reacciona la UI cuando una API falla. Te permite detectar estados de carga infinitos, ausencia de mensajes 404 o cualquier error que el front-end no esté manejando, sin tocar el backend.

Como QA, este escenario te da material concreto para levantar un ticket: si la API devuelve 404 y la pantalla no muestra feedback al usuario, hay un bug que reportar.

¿Cómo validar que la intercepción capturó el error?

Usa cy.wait con el alias de la intercepción y aplica una aserción sobre la propiedad esperada. Para confirmar que el error llegó al request, basta con encadenar should('have.property', 'error').

js cy.wait('@error').its('error').should('exist');

Con esa línea aseguras que la prueba no pasa por casualidad: confirmas que el network request fue interceptado y que la simulación de fallo se ejecutó como esperabas.

¿Cómo cambiar el body de una respuesta con cy.intercept?

El segundo caso de uso es modificar el contenido que devuelve la API. En lugar de bloquear la red, le dices a Cypress que sustituya el cuerpo de la respuesta por uno que tú definas, junto con el status code que prefieras [04:30].

js cy.intercept('GET', 'https://pokeapi.co/api/v2/pokemon/1', { statusCode: 200, body: pikachuResponse }).as('pikachu');

En la clase, la app pedía datos de Bulbasaur (id 1), pero la intercepción devolvió el JSON de Pikachu (id 25). El front-end mostró a Pikachu sin que la API real fuera consultada.

¿Qué es mockear una respuesta en Cypress? Es reemplazar la respuesta real de una API por una que tú controlas. Sirve para probar la UI con datos específicos, simular casos edge o validar comportamientos sin depender del backend.

¿Cómo validar el body interceptado?

Después del cy.wait, puedes inspeccionar response.body y aplicar aserciones sobre las propiedades clave. En el ejemplo, se valida que el nombre sea Pikachu y que el statusCode sea 200.

js cy.wait('@pikachu').then((interception) => { expect(interception.response.body).to.have.property('name', 'pikachu'); expect(interception.response.statusCode).to.eq(200); });

Aquí entra un detalle importante: si el sitio dispara más de una petición al mismo recurso lógico (por ejemplo, pokemon-species y pokemon), debes interceptar la URL correcta. Mockear la URL equivocada provoca que el front-end reciba datos incoherentes y crashee con una excepción que Cypress reporta como sitio caído.

¿Cuándo conviene mockear respuestas en lugar de probar el backend?

Mockear con cy.intercept es ideal cuando tu objetivo es probar la capa visual y de interacción, no la base de datos. Si solo te interesa validar el contrato del backend, cy.request es más rápido porque ni siquiera necesita renderizar el sitio.

Usa intercepción cuando:

• Necesitas simular un error de pago en una pasarela.
• Quieres validar el flujo de un registro fallido sin crear usuarios reales.
• Buscas probar estados de UI difíciles de reproducir, como un 500 o un timeout.
• Estás verificando que el front-end muestre mensajes correctos ante distintos status codes.

Un detalle práctico de la clase: usar la extensión JSON Pretty Print en Chrome ayuda a leer respuestas largas, y con Prettier puedes formatear el JSON dentro del editor antes de pegarlo como mock [06:50].

¿Qué pasa si interceptas la URL equivocada?

Cypress lanza una excepción y muestra el mensaje de que el sitio crasheó, con un enlace a la documentación. La causa más común es que la página llama a varias APIs y tú estás mockeando solo una. Revisa las devtools de tu navegador, identifica todas las peticiones involucradas y ajusta el patrón de URL en cy.intercept.

En el ejemplo, la app consultaba tanto pokemon-species/1 como pokemon/1. Al cambiar el intercept a la URL correcta, Pikachu apareció en pantalla en el lugar de Bulbasaur, demostrando que el mock funcionó incluso antes de que la API real respondiera.

Te reto a probar esto en cualquier sitio: abre las devtools, copia la respuesta que te interesa, pégala como body del intercept y observa cómo el front-end reacciona a tus datos. Cuéntame en los comentarios qué API decidiste mockear y qué bug encontraste en el camino.