Gestor de Tests Snapshot

El Problema

Los tests snapshot empiezan siendo utiles — detectan cambios inesperados en la salida de componentes. Pero en semanas, los desarrolladores actualizan snapshots a ciegas sin revisar diffs, haciendolos inutiles. Los archivos de snapshot grandes se convierten en ruido, y nadie sabe si un cambio de snapshot es un bug o una actualizacion intencional. Sin una estrategia clara, los tests snapshot se vuelven lo peor de ambos mundos: ralentizan el desarrollo sin atrapar bugs reales.

El Prompt

Revisa mi estrategia de snapshot testing y arreglala. Quiero tests snapshot que realmente atrapen bugs, no que los desarrolladores actualicen a ciegas.

SETUP ACTUAL:
[describe tu snapshot testing — framework, cantidad de snapshots, puntos de dolor]

COMPONENTE/MODULO:
[pega el componente o salida que se snapshottea]

Analiza y proporciona:

1. **Auditoria de Snapshots** — Para mi snapshot actual, identificar:
   - Lineas que cambian frecuentemente pero no son bugs (timestamps, IDs aleatorios, hashes de classnames)
   - Secciones demasiado grandes que deberian dividirse en aserciones dirigidas
   - Datos que deberian usar property matchers en vez de coincidencia exacta

2. **Test Snapshot Mejorado** — Reescribir el test snapshot con:
   - Snapshots inline para salidas pequenas (menos de 20 lineas)
   - Property matchers para valores dinamicos (expect.any(String), expect.any(Number))
   - Snapshots enfocados que capturen solo las partes significativas
   - Nombres de test claros que expliquen que protege el snapshot

3. **Reglas de Higiene de Snapshots** — Proveer un checklist de equipo para revisar actualizaciones de snapshots en PRs.

4. **Ruta de Migracion** — Mostrar cuales snapshots deberian convertirse en aserciones explicitas.

Ejemplo de Salida

// ANTES: Snapshot fragil de componente completo
it('renderiza correctamente', () => {
  expect(render(<UserCard user={mockUser} />)).toMatchSnapshot();
});

// DESPUES: Snapshot dirigido y resiliente con matchers
it('renderiza info de usuario con estructura correcta', () => {
  const { container } = render(<UserCard user={mockUser} />);
  expect(container).toMatchInlineSnapshot(`
    <div class="user-card">
      <h3>Maria Gonzalez</h3>
      <span class="role">Miembro Premium</span>
    </div>
  `);
});

// Valores dinamicos usan property matchers
it('genera datos validos de tarjeta de usuario', () => {
  expect(generateCardData(mockUser)).toMatchSnapshot({
    id: expect.any(String),
    createdAt: expect.any(Date),
    displayName: 'Maria Gonzalez',
  });
});

Cuando Usar

Usar cuando tu equipo tiene tests snapshot existentes que son ruidosos o ignorados, al introducir snapshots en un proyecto nuevo, o durante una limpieza de la suite de tests. Es particularmente importante despues de adoptar una solucion CSS-in-JS o cualquier herramienta que genera classnames dinamicos.

Tips Pro

• Preferir snapshots inline — viven junto al test para que los revisores vean la salida esperada sin abrir un archivo separado.
• Nunca snapshottear paginas enteras — snapshottear componentes individuales o estructuras de datos especificas. Mientras mas pequeno el snapshot, mas util el diff.
• Agregar un check CI para tamano de snapshot — pedir a la IA que escriba un script que falle si algun snapshot individual excede 50 lineas.