Control del backend con cy.intercept()

Esperar la request, no el reloj

cy.intercept('POST', '/api/contact').as('sendContact');

cy.get('[data-cy="submit"]').click();

cy.wait('@sendContact').its('response.statusCode').should('eq', 200);
cy.contains('Mensaje enviado').should('be.visible');

cy.wait('@alias') espera esa request específica — ni un milisegundo más de lo necesario, y falla con un mensaje claro si nunca ocurre.

Stub: probar la UI sin backend

cy.intercept() puede responder por el servidor. Esto desbloquea los casos difíciles de reproducir con datos reales:

// Lista vacía: ¿la UI tiene empty-state o explota?
cy.intercept('GET', '/api/servicios', { body: [] }).as('servicios');

// Respuesta lenta: ¿aparece el skeleton?
cy.intercept('GET', '/api/servicios', (req) => {
  req.reply({ delay: 2000, fixture: 'servicios.json' });
});

// Error 500: ¿hay mensaje amable o pantalla blanca?
cy.intercept('POST', '/api/bookings', { statusCode: 500 }).as('bookingError');

Los estados de error son donde viven los bugs vergonzosos — y con stubs cuestan un test de 5 líneas.

Fixtures para datos de prueba

// cypress/fixtures/servicios.json contiene el catálogo de prueba
cy.intercept('GET', '/api/servicios', { fixture: 'servicios.json' });

Regla de sanidad: las fixtures modelan formas de respuesta (vacía, una página, con caracteres raros), no copias de producción.

¿Cuándo stubbear y cuándo no?

• Suite de UI (mayoría de tests): stub. Rápida, determinista, sin backend que mantener.
• Smoke e2e real (pocos tests): sin stubs, contra un entorno real. Verifica la integración de verdad.

El error clásico es elegir uno solo: todo stubbeado no prueba integración; todo real es lento y flaky. Las dos capas se complementan.

Ejercicio

Para un formulario público cualquiera: escribe 3 tests con intercept — uno que espere la request real y verifique el status, uno que stubbee un 500 y verifique el mensaje de error, y uno que stubbee una respuesta lenta y verifique el estado de carga.