Disenador de Tests de Contrato

El Problema

Los microservicios se rompen entre si silenciosamente. El servicio A cambia su formato de respuesta, y el servicio B solo descubre el problema en produccion. Los tests de integracion ayudan pero requieren correr todos los servicios juntos, lo cual es lento y fragil. El contract testing resuelve esto definiendo la interaccion esperada entre consumidor y proveedor, verificando cada lado independientemente.

El Prompt

Disena tests de contrato consumer-driven para la siguiente interaccion de servicio. Necesito tests que atrapen breaking changes de API antes del deployment sin requerir que ambos servicios corran juntos.

SERVICIO CONSUMIDOR: [describe el servicio que llama a la API]
SERVICIO PROVEEDOR: [describe el servicio que sirve la API]
INTERACCION: [describe la llamada API]

HERRAMIENTA: [Pact / Spring Cloud Contract / Specmatic]

Genera:

1. **Contrato del Consumidor** — Definir request y response esperados con matchers flexibles
2. **Verificacion del Proveedor** — Configurar provider states y verificar contratos
3. **Configuracion de Pact Broker** — Configurar comparticion de contratos
4. **Deteccion de Breaking Changes** — Mostrar ejemplos de cambios que rompen y no rompen el contrato

Ejemplo de Salida

describe('Contrato API de Usuarios', () => {
  it('debe retornar perfil de usuario para ID valido', async () => {
    await provider.addInteraction({
      state: 'usuario con ID usr_123 existe',
      uponReceiving: 'un request por perfil de usuario',
      withRequest: { method: 'GET', path: '/api/users/usr_123' },
      willRespondWith: {
        status: 200,
        body: {
          id: like('usr_123'),
          name: like('Maria'),
          email: term({ generate: 'maria@test.com', matcher: '.*@.*' }),
        },
      },
    });
  });
});

Cuando Usar

Usar cuando multiples equipos manejan diferentes servicios que se comunican via APIs, al deployar servicios independientemente, o cuando los entornos de tests de integracion no son confiables.

Tips Pro

• El consumidor guia el contrato — el consumidor define lo que necesita, no lo que el proveedor ofrece.
• Usar matchers, no valores exactos — like('Maria') significa “cualquier string”, no literalmente “Maria”.
• Testear provider states — el proveedor debe configurar el estado de datos correcto antes de la verificacion.
• Versionar tus contratos — usar checks can-i-deploy en CI para verificar compatibilidad antes del deploy.