Refactorizador de Tests

El Problema

El codigo de tests se deteriora igual que el codigo de produccion. Bloques de setup copiados, nombres de test poco claros, mocking excesivo y tests que prueban detalles de implementacion en vez de comportamiento crean una carga de mantenimiento. Los desarrolladores evitan tocar tests porque cambiar uno rompe otros diez. Eventualmente la suite de tests se convierte en un obstaculo para refactorizar el mismo codigo que deberia proteger.

El Prompt

Refactoriza el siguiente archivo de tests para que sea mas mantenible, legible y resiliente. Los tests deben sobrevivir cambios de implementacion mientras siguen atrapando bugs reales.

ARCHIVO DE TESTS:
[pega tu archivo de tests]

ARCHIVO FUENTE TESTEADO:
[pega la implementacion, si es util]

Aplica estos patrones de refactorizacion:

1. **Extraer setup compartido** — Identificar bloques arrange duplicados y extraer en beforeEach, funciones factory o helpers de test
2. **Mejorar nombres de tests** — Reescribir nombres siguiendo el patron "debe [comportamiento esperado] cuando [condicion]"
3. **Eliminar acoplamiento a implementacion** — Reemplazar tests que verifican llamadas a metodos internos con tests que verifican comportamiento/salida observable
4. **Reducir over-mocking** — Identificar mocks que hacen el test sin sentido y reemplazar con implementaciones reales o fakes minimos
5. **Una asercion por test** — Dividir tests con multiples aserciones no relacionadas en tests separados enfocados
6. **Agregar casos borde faltantes** — Identificar vacios durante la refactorizacion y agregar tests para escenarios no cubiertos

Mostrar el archivo de tests refactorizado con comentarios explicando cada cambio y POR QUE mejora la mantenibilidad.

Ejemplo de Salida

// ANTES: Test fragil acoplado a implementacion
it('test login', () => {
  const spy = jest.spyOn(authService, 'validateToken');
  const mockDB = jest.fn().mockReturnValue({ id: 1 });
  login('user', 'pass');
  expect(spy).toHaveBeenCalledTimes(1);
});

// DESPUES: Test enfocado en comportamiento, resiliente
describe('login', () => {
  const validCredentials = createCredentials({ user: 'maria', pass: 'Fuerte!' });

  it('debe retornar token de sesion cuando las credenciales son validas', async () => {
    const result = await login(validCredentials);
    expect(result.token).toMatch(/^eyJ/);
    expect(result.expiresIn).toBeGreaterThan(0);
  });

  it('debe lanzar AuthError cuando el password es incorrecto', async () => {
    const invalid = createCredentials({ user: 'maria', pass: 'mal' });
    await expect(login(invalid)).rejects.toThrow(AuthError);
  });
});

Cuando Usar

Usar durante sprints dedicados de mantenimiento de tests, cuando notas que los tests se rompen frecuentemente durante refactorizaciones, o al incorporar nuevos desarrolladores que encuentran la suite de tests confusa. Tambien es el movimiento correcto antes de una refactorizacion mayor — limpiar tests primero, luego refactorizar la implementacion con confianza.

Tips Pro

• Pedir un reporte de smells primero — promptear “Lista cada smell de test en este archivo (over-mocking, nombres poco claros, duplicacion de setup, acoplamiento a implementacion) antes de refactorizar.”
• Mantener la misma cobertura — despues de refactorizar, verificar que todos los casos de test originales siguen cubiertos.
• Introducir test helpers gradualmente — extraer una factory createUser() o helper setupAuthenticatedSession() y reutilizar en multiples archivos de test.
• Ejecutar mutation testing despues — verificar que los tests refactorizados siguen atrapando bugs reales.