Escritor de Tests de Integracion

El Problema

Los tests unitarios verifican funciones individuales, pero los bugs de produccion suelen vivir en los espacios entre componentes. Una funcion funciona perfectamente aislada, pero falla cuando la base de datos retorna null, la API cambia su formato de respuesta o el cache sirve datos obsoletos. Escribir tests de integracion es mas dificil porque necesitas setups realistas, teardown adecuado y conocimiento de cuales puntos de interaccion realmente importan.

El Prompt

Escribe tests de integracion para la siguiente interaccion del sistema. Estos tests deben verificar que los componentes funcionan correctamente juntos, no aislados.

SISTEMA BAJO TEST:
[describe la interaccion — ej. "Flujo de registro: endpoint API → validacion → insert en DB → servicio de email → respuesta"]

COMPONENTES INVOLUCRADOS:
[lista servicios, bases de datos, APIs, colas, etc.]

STACK TECNOLOGICO:
[ej. Express + PostgreSQL + Redis + SendGrid]

FRAMEWORK DE TESTING: [ej. Jest + Supertest, pytest + httpx]

Para cada punto de integracion, escribe tests cubriendo:
1. **Happy path** — flujo completo exitoso end-to-end
2. **Fallo parcial** — un componente falla, los otros lo manejan correctamente
3. **Consistencia de datos** — verificar que el estado es correcto en todos los componentes despues de la operacion
4. **Limpieza/rollback** — verificar que operaciones fallidas no dejan datos huerfanos
5. **Timing** — testear manejo de timeouts y comportamiento de reintentos

Incluir:
- Setup de tests con fixtures realistas (no stubs minimos)
- Teardown adecuado para evitar contaminacion entre tests
- Comentarios explicando CUAL frontera de integracion verifica cada test
- Manejo de transacciones o reset de base de datos entre tests

Ejemplo de Salida

describe('Integracion de Registro de Usuario', () => {
  beforeEach(async () => {
    await db.migrate.latest();
    await db('users').truncate();
  });

  it('debe crear usuario en DB y enviar email de bienvenida en registro valido', async () => {
    const res = await request(app).post('/api/register')
      .send({ email: 'nuevo@example.com', password: 'Fuerte!Pass1' });
    expect(res.status).toBe(201);
    const user = await db('users').where({ email: 'nuevo@example.com' }).first();
    expect(user).toBeDefined();
    expect(emailService.sendWelcome).toHaveBeenCalledWith('nuevo@example.com');
  });

  // Verifica: rollback de DB cuando el servicio de email falla
  it('debe revertir creacion de usuario si el servicio de email lanza error', async () => {
    emailService.sendWelcome.mockRejectedValueOnce(new Error('SMTP caido'));
    const res = await request(app).post('/api/register')
      .send({ email: 'fallo@example.com', password: 'Fuerte!Pass1' });
    expect(res.status).toBe(503);
    const user = await db('users').where({ email: 'fallo@example.com' }).first();
    expect(user).toBeUndefined(); // sin registro huerfano
  });
});

Cuando Usar

Usar cuando construyes features que abarcan multiples servicios, despues de un incidente en produccion causado por una falla en la interaccion de componentes, o cuando migras de un monolito a microservicios. Los tests de integracion son tu red de seguridad para las costuras entre componentes donde los tests unitarios no llegan.

Tips Pro

• Usar testcontainers — levantar bases de datos y servicios reales en Docker en vez de mockearlos. La IA puede generar el setup completo de testcontainers para tu stack.
• Testear el contrato, no la implementacion — verificar que la forma de respuesta de la API y el estado de la base de datos son correctos, no las llamadas internas a funciones.
• Separar rapidos y lentos — etiquetar tests de integracion para que corran en CI pero no en cada guardado de archivo. Pedir a la IA la configuracion apropiada del test runner.
• Pedir una matriz de fallos — promptear “Lista cada forma en que el componente A puede fallar al llamar al componente B” antes de escribir tests.