O que um contrato garante
Um contrato descreve aspectos relevantes de uma interação: método e caminho HTTP, campos de uma resposta, status esperados ou formato de uma mensagem. Um teste verifica esse acordo de uma perspectiva definida e detecta incompatibilidades antes do deploy combinado.
Contrato não prova toda a lógica de negócio, consistência do banco, disponibilidade ou compatibilidade de cada versão em produção. É uma camada de confiança em integrações, não substituto para testes funcionais e testes de integração apropriados.
Contrato dirigido pelo consumidor
Em contract testing dirigido pelo consumidor, cada consumidor registra quais interações usa e que resultados espera. O provedor verifica os contratos publicados antes de uma implantação. Assim, requisitos que não são utilizados não precisam ser tratados como dependências de cada consumidor, mas todos os consumidores relevantes ainda precisam participar do fluxo.
Ferramentas como Pact podem armazenar contratos e publicar resultados de verificação, mas exigem disciplina de versão, credenciais e automação. A equipe também pode usar outros formatos ou testes de esquema dependendo do estilo de integração.
Um ciclo de publicação e verificação
- O consumidor define uma interação necessária usando exemplos mínimos.
- O teste gera e publica a especificação ligada à versão do consumidor.
- O provedor executa verificações contra os contratos conhecidos.
- O pipeline registra quais combinações de versões podem ser implantadas juntas.
- Uma política de compatibilidade protege deploy e remoção de versões antigas.
Não trate a publicação do contrato como verdade sem revisão. Se ninguém executa a verificação no provedor, a especificação pode ficar verde enquanto a integração quebra.
Mensagens assíncronas também têm contrato
Eventos Kafka, mensagens em filas e comandos carregam formatos e semântica usados por produtores e consumidores. Teste campos obrigatórios, compatibilidade de esquema, significado de valores e comportamento com campos opcionais ou desconhecidos. Compatibilidade de serialização não garante semântica equivalente: mudar a unidade de um valor mantendo o mesmo tipo ainda pode quebrar consumidores.
Evite acoplar consumidores a campos incidentais. Versionamento, evolução aditiva, registro de esquema e período de convivência dependem da infraestrutura e dos requisitos do negócio. Para entrega e duplicidade, veja Outbox e Inbox e conceitos de Kafka.
Quando contratos ajudam — e quando não bastam
São úteis quando serviços são implantados independentemente, há vários consumidores ou alterações no provedor frequentemente causam regressões. Podem ser redundantes para uma chamada interna num monólito com deploy único, embora testes de esquema ainda possam ser relevantes.
Use testes funcionais para verificar comportamento de uma funcionalidade, testes de integração para fronteiras reais e contratos para compatibilidade entre aplicações. Uma cobertura forte distribui a confiança em vez de exigir um único teste amplo para tudo.