Revision de Calidad de Tests

El Problema

Numeros altos de coverage crean falsa confianza. Los equipos persiguen 80% de coverage escribiendo tests que llaman funciones sin verificar resultados significativos. Los mocks reemplazan tanto del sistema que los tests solo verifican la configuracion del mock. Nombres como “deberia funcionar” no dicen nada cuando fallan. La suite de tests corre verde mientras los bugs llegan a produccion porque los tests no prueban nada real.

El Prompt

Revisa la calidad del siguiente codigo de test. Actua como un lider de ingenieria de tests evaluando si estos tests realmente atrapan bugs.

FRAMEWORK DE TEST: [ej. Jest, Vitest, Pytest, Go testing]
CODIGO BAJO PRUEBA: [breve descripcion de lo que se esta probando]

CODIGO DE TEST:
[pegar archivos de test aqui]

CODIGO FUENTE (opcional):
[pegar la implementacion siendo probada]

Evalua en estas dimensiones de calidad de test:

1. **Calidad de Assertions**
   - Los tests verifican resultados especificos, no solo "no lanzo error"?
   - Las assertions prueban comportamiento, no detalles de implementacion?
   - Un bug sutil en el codigo fuente realmente haria fallar alguno de estos tests?
   - Se prueban casos negativos (entrada invalida, condiciones de error)?

2. **Brechas de Coverage**
   - Que edge cases faltan (entrada vacia, null, valores limite, entradas grandes)?
   - Los caminos de error estan probados (fallo de red, datos invalidos)?

3. **Independencia de Tests**
   - Cada test puede correr aislado (sin dependencia de orden de ejecucion)?
   - Los tests limpian despues de si mismos (sin estado mutable compartido)?

4. **Estrategia de Mocks**
   - Los mocks son necesarios o los tests de integracion darian mas confianza?
   - Los mocks reflejan el comportamiento real de la dependencia?
   - Se esta mockeando demasiado (probando el mock, no el codigo)?

5. **Legibilidad & Nombres**
   - Los nombres de test describen escenario Y resultado esperado?
   - Se sigue el patron Arrange/Act/Assert consistentemente?

Para cada problema, proporciona:
- **Test**: Cual caso de prueba
- **Problema**: Por que este test da falsa confianza
- **Severidad**: Falso-positivo / Coverage-faltante / Fragil / Estilo
- **Fix**: Codigo de test mejorado

Ejemplo de Salida

## Revision de Calidad de Tests: 4 problemas encontrados

### Falso Positivo: Test No Verifica Nada Significativo
Test: "deberia crear un usuario"
Codigo:
  test('deberia crear un usuario', async () => {
    const result = await createUser({ name: 'Test' });
    expect(result).toBeTruthy();  // Pasa incluso con { error: true }
  });
Fix:
  test('crea usuario con nombre correcto e ID generado', async () => {
    const result = await createUser({ name: 'Test' });
    expect(result.id).toMatch(/^usr_/);
    expect(result.name).toBe('Test');
  });

Cuando Usar

Ejecutar al revisar PRs de tests, al evaluar suites heredadas, o cuando el coverage es alto pero los bugs siguen llegando. Esencial al prepararse para un refactoring grande.

Tips Pro

• Incluir el codigo fuente — la calidad de tests solo puede evaluarse contra la implementacion.
• Hacer la pregunta de mutacion — “Si introduzco un bug off-by-one sutil en linea 15, cual test lo atraparia?”
• Revisar ratio test-a-codigo — si el archivo de test es 3x mas largo que el fuente, los tests probablemente sobre-especifican detalles de implementacion.