Por qué usar fixtures en Cypress
Las fixtures son archivos de datos estáticos que simulan respuestas de APIs o estados de la aplicación. En lugar de depender de servicios externos durante los tests, cargás datos controlados desde archivos JSON. Esto hace que tus tests sean más rápidos (no hay llamadas HTTP reales), más estables (sin timeouts ni errores de red) y completamente reproducibles.
Cypress busca fixtures en cypress/fixtures/ por defecto. Un error común es crear estructuras JSON incorrectas o demasiado simplificadas que no reflejan la complejidad de las respuestas reales. Otro problema típico: olvidar actualizar las fixtures cuando la API cambia, lo que genera falsos positivos en los tests.
Las fixtures brillan en cy.intercept() para mockear endpoints, en cy.fixture() para cargar datos en comandos custom, y en tests de componentes donde necesitás props realistas. Usarlas correctamente acelera tu suite de pruebas en un 60-80% comparado con tests que golpean APIs reales.
Estrategias para fixtures efectivas
Organizá tus fixtures por dominio o entidad: users/, products/, orders/. Dentro de cada carpeta, creá variantes: user-admin.json, user-guest.json, user-suspended.json. Esto facilita encontrar el fixture correcto y mantener consistencia en los datos de test.
Incluí casos extremos en tus fixtures: usuarios sin avatar, productos sin stock, respuestas de error 400/401/500. Muchos equipos solo generan casos "felices" y después descubren bugs en manejo de errores en producción. Tené fixtures para estados vacíos (arrays [], objetos sin propiedades opcionales) y payloads grandes (listas de 100+ items para probar paginación y scroll).
Tip pro: usá TypeScript para tipar tus fixtures. Creá interfaces que coincidan con tus modelos de backend y validá los JSON con un script pre-commit. Esto previene fixtures rotos que causan tests flaky. También considerá generadores de datos como Faker.js para crear fixtures dinámicas cuando necesitás volumen (ej: 1000 usuarios únicos).
Patrones avanzados con cy.intercept
El patrón más poderoso: cy.intercept() + cy.fixture(). Interceptás rutas específicas y devolvés fixtures customizadas por test. Ejemplo: cy.intercept('GET', '/api/users/*', { fixture: 'users/admin.json' }). Esto te permite probar flujos completos sin backend funcionando.
Para tests de loading states, usá delays artificiales: cy.intercept('/api/products', { fixture: 'products.json', delay: 2000 }). Verificás que spinners aparecen y mensajes de "cargando" se muestran correctamente. Para simular errores de red: cy.intercept('/api/checkout', { forceNetworkError: true }) o respondé con statusCode 500 y una fixture de error.
Mantené fixtures versionadas con tu código. Si un endpoint cambia de v1 a v2, mantené ambos fixtures temporalmente para facilitar rollback. Y cuidado con datos hardcodeados tipo IDs o timestamps: usá valores placeholder que sean claramente fake (999, '2024-01-01') para que sea obvio que son datos de prueba.
Errores comunes y cómo evitarlos
Error #1: Fixtures desactualizadas. El backend agrega un campo nuevo, los tests pasan porque la fixture vieja no lo incluye, pero la UI rompe en producción. Solución: script que compara fixtures contra schema OpenAPI o validaciones de Zod/Yup en el pipeline CI.
Error #2: Datos demasiado genéricos. Fixtures con "Test User", "Example Product" pierden valor: no prueban caracteres especiales, textos largos, o formatos edge case. Usá datos realistas: nombres con tildes, emails con +alias, precios con decimales raros (9.999), URLs largas.
Error #3: No testear fixtures vacías. Cuando un endpoint devuelve [], ¿tu UI muestra el empty state correcto? Muchos tests asumen que siempre hay datos. Creá fixtures tipo empty-users.json, no-results.json para verificar estos escenarios.
Por último: no abuses de fixtures para todo. Si necesitás probar lógica de ordenamiento o filtros complejos, a veces conviene generar datos en el test mismo con beforeEach() en lugar de mantener 50 fixtures casi idénticas.