Teste de contrato

O teste de contrato (contract testing) verifica o acordo entre dois serviços de forma isolada. Cada lado é testado contra uma descrição compartilhada das interações, o contrato, em vez de contra o outro serviço rodando de verdade. Se o provedor muda o nome de um campo do qual um consumidor depende, um teste de contrato falha no próprio pipeline do provedor, antes de qualquer deploy. Em custo e em confiança, ele fica entre os testes de integração e os testes end-to-end.

Como funciona o teste de contrato orientado ao consumidor

A forma mais comum, popularizada pela ferramenta Pact, é orientada ao consumidor (consumer-driven):

1. O consumidor escreve um teste contra um provedor mockado, declarando as requisições que envia e as partes da resposta que realmente usa. Por exemplo: GET /orders/42 retorna 200 com um número id e uma string status.
2. Rodar esse teste gera um arquivo de contrato (um “pact”) que registra essas interações.
3. O contrato é compartilhado, normalmente por meio de um serviço broker.
4. O provedor verifica o contrato reproduzindo cada requisição registrada contra a sua implementação real e conferindo se as respostas batem.
5. Antes do deploy, o time verifica se a versão que está prestes a liberar é compatível com as versões do outro lado que já estão naquele ambiente.

Como o consumidor lista apenas os campos que usa, o provedor fica livre para adicionar campos ou mudar qualquer coisa da qual nenhum consumidor dependa.

Diferença em relação a verificações parecidas

• Validação de schema compara uma resposta com o schema publicado pelo provedor. Ela mostra que o provedor é consistente com a própria documentação, não que ainda atende às necessidades de cada consumidor.
• Testes de integração chamam o provedor real. Precisam dos dois serviços e de suas dependências rodando, e tendem a ser mais lentos e mais instáveis.
• Testes end-to-end provam que uma jornada completa funciona, mas são uma forma lenta e cara de descobrir que um campo foi renomeado.

Contratos orientados ao provedor (provider-driven), em que o provedor publica uma especificação OpenAPI e os consumidores testam contra ela, são uma alternativa quando o provedor não consegue conhecer nem se coordenar com todos os seus consumidores, como no caso de uma API pública.

Erros comuns

• Especificar demais. Fazer asserções sobre valores exatos ou sobre todos os campos transforma os contratos em testes funcionais frágeis. Use matchers de tipo e inclua só o que o consumidor lê.
• Testar regra de negócio nos contratos. Contratos verificam o formato da conversa; a correção da lógica pertence aos testes do próprio provedor.
• Ignorar os provider states. “O pedido 42 existe” precisa ser preparado do lado do provedor durante a verificação, senão ela falha pelo motivo errado.