Generador de Escenarios de Error

El Problema

Los desarrolladores testean lo que deberia pasar pero raramente testean lo que no deberia pasar. Un formulario de login se testea con credenciales correctas pero no con payloads de SQL injection, passwords vacios o usernames de 10,000 caracteres. Los escenarios de error son donde viven los bugs del mundo real, y generarlos sistematicamente es algo que la IA hace excepcionalmente bien.

El Prompt

Genera escenarios de error y fallo completos para el siguiente feature. Piensa en todo lo que puede salir mal — desde errores del usuario hasta fallas de infraestructura.

FEATURE:
[describe el feature — ej. "flujo de checkout", "subida de archivos", "login de usuario"]

Genera escenarios de error para cada categoria:

1. **Errores de Input del Usuario** — formatos invalidos, campos requeridos faltantes, valores muy largos/cortos, caracteres especiales
2. **Fallas de Red** — timeout, conexion rechazada, falla DNS, respuesta lenta
3. **Errores del Servidor** — 500, 502, 503, respuesta JSON malformada
4. **Fallas de Autenticacion** — sesion expirada, permisos revocados
5. **Errores de Estado de Datos** — registro referenciado eliminado, modificacion concurrente, cache obsoleto
6. **Limites de Recursos** — archivo muy grande, disco lleno, rate limit excedido
7. **Errores de Logica de Negocio** — saldo insuficiente, oferta expirada, sin inventario

Para cada escenario: descripcion, como simularlo, comportamiento esperado, stub de test.

Ejemplo de Salida

// Red: timeout de API durante checkout
it('debe mostrar boton de reintento cuando la API de pago expira', async () => {
  server.use(rest.post('/api/payment', (req, res, ctx) => {
    return res(ctx.delay(30000));
  }));
  await userEvent.click(screen.getByText('Pagar Ahora'));
  await waitFor(() => {
    expect(screen.getByText('El pago expiro. Por favor intenta de nuevo.')).toBeVisible();
  });
});

Cuando Usar

Usar cuando disenas cualquier feature nuevo para asegurar que el manejo de errores esta incorporado desde el inicio, durante revisiones de seguridad, o al escribir tests para codigo legacy sin manejo de errores.

Tips Pro

• Testear el mensaje al usuario, no el codigo de error — los usuarios ven el mensaje de error, no el status HTTP.
• Usar MSW (Mock Service Worker) — simular errores de red sin cambiar codigo de produccion.
• Combinar con chaos engineering — usar los escenarios generados como checklist para experimentos de caos.
• Priorizar por impacto al usuario — un timeout en la pagina de pago es critico; en la pagina de configuracion es menor.