Sesiones, comandos propios y organización

Login una vez, no doscientas

Probar el login por UI en cada test agrega minutos sin probar nada nuevo. cy.session() cachea el estado (cookies, localStorage) entre tests:

// cypress/support/commands.js
Cypress.Commands.add('loginPorApi', (user = 'demo') => {
  cy.session(user, () => {
    cy.request('POST', '/api/login', {
      email: `${user}@test.cl`,
      password: Cypress.env('TEST_PASSWORD'),
    }).then(({ body }) => {
      window.localStorage.setItem('token', body.token);
    });
  });
});

beforeEach(() => {
  cy.loginPorApi();
  cy.visit('/dashboard');
});

El primer test paga el login por API (rápido); el resto lo reutiliza al instante. El login por UI se prueba aparte, en su propio spec — una sola vez.

Custom commands con criterio

Los comandos propios brillan para acciones transversales... y se vuelven trampa cuando esconden lógica de negocio:

// ✅ Transversal, se usa en 30 specs
Cypress.Commands.add('getByCy', (id) => cy.get(`[data-cy="${id}"]`));

// ❌ Lógica de un solo flujo disfrazada de comando global
Cypress.Commands.add('crearReservaComplataConDescuentoYRecordatorio', ...);

Para flujos, prefiere funciones importables (o el patrón page object si vienes de Selenium) — se tipan mejor y se encuentran más fácil que los comandos mágicos globales.

Estructura de suite que escala

cypress/
  e2e/
    smoke/        # 5-10 tests críticos, corren en cada push
    reservas/     # specs por dominio de negocio
    admin/
  fixtures/
  support/

En CI, dos jobs: smoke bloquea el merge (rápido), la suite completa corre en paralelo después. Cypress paraleliza por spec — muchos specs pequeños paralelizan mejor que tres gigantes.

Datos por test, no compartidos

// Cada test siembra lo suyo por API
beforeEach(() => {
  cy.request('POST', '/api/test/seed', { escenario: 'agenda-vacia' });
});

El test que depende de lo que dejó otro no puede reintentarse ni paralelizarse — es el origen del 80% de la flakiness en suites Cypress reales.

Ejercicio

Refactoriza los tests de las lecciones anteriores: agrega getByCy, organiza los specs por dominio y crea un spec smoke/ con los 3 tests más críticos. Mide el tiempo de la suite antes y después de introducir cy.session().