View on GitHub

manual-da-engenharia-para-codar

Este é o manual para compromissos de "código com" a engenharia.

Teste de Contrato Orientado pelo Consumidor (CDC)

O Teste de Contrato Orientado pelo Consumidor (ou CDC, na sigla em inglês) é uma metodologia de teste de software usada para testar componentes de um sistema isoladamente, garantindo que os componentes provedores sejam compatíveis com as expectativas que os componentes consumidores têm deles.

Por que Teste de Contrato Orientado pelo Consumidor

O CDC tenta superar as várias desvantagens dolorosas dos testes E2E automatizados com componentes interagindo juntos:

Embora as melhores práticas de teste sugiram escrever apenas alguns testes E2E em comparação com os testes de integração e unitários mais baratos, rápidos e estáveis, como ilustrado na pirâmide de testes abaixo, a experiência mostra que muitas equipes acabam escrevendo muitos testes E2E. Uma razão para isso é que os testes E2E dão aos desenvolvedores a maior confiança para lançar, pois estão testando o “sistema real”.

Pirâmide de Teste E2E

O CDC aborda essas questões testando interações entre componentes isoladamente usando mocks que estão de acordo com um entendimento compartilhado documentado em um “contrato”. Contratos são acordados entre consumidor e provedor e são regularmente verificados contra uma instância real do componente provedor. Isso efetivamente divide um sistema maior em partes menores que podem ser testadas individualmente isoladas umas das outras, levando a testes mais simples, rápidos e estáveis que também dão confiança para lançar.

Alguns testes E2E ainda são necessários para verificar o sistema como um todo quando implantado no ambiente real, mas a maioria das interações funcionais entre componentes pode ser coberta com testes CDC.

O teste CDC foi inicialmente desenvolvido para testar APIs RESTful, mas o padrão se aplica a todos os sistemas consumidor-provedor e existem ferramentas para outros protocolos de mensagens além do HTTP.

Blocos de Design de Teste de Contrato Orientado pelo Consumidor

Em uma abordagem orientada pelo consumidor, o consumidor direciona as mudanças nos contratos entre um consumidor (o cliente) e um provedor (o servidor). Isso pode parecer contraintuitivo, mas ajuda os provedores a criar APIs que se ajustem às necessidades reais dos consumidores, em vez de tentar adivinhá-las antecipadamente. A seguir, descrevemos os blocos de construção do CDC ordenados por sua ocorrência no ciclo de desenvolvimento.

Teste CDC

Testes do Consumidor com Mock do Provedor

Os consumidores começam criando testes de integração contra um mock do provedor e executando-os como parte de seu pipeline de CI. Respostas esperadas são definidas no mock do provedor para solicitações disparadas a partir dos testes. Por meio disso, o consumidor essencialmente define o contrato que espera que o provedor cumpra.

Contrato

Contratos são gerados a partir das expectativas definidas no mock do provedor como resultado de uma execução bem-sucedida do teste. Frameworks de CDC como o Pact fornecem uma especificação para contratos no formato json, consistindo na lista de solicitações/respostas geradas a partir dos testes do consumidor, além de alguns metadados adicionais.

Contratos não são um substituto para uma discussão entre a equipe do consumidor e do provedor. Este é o momento em que essa discussão deve ocorrer (se já não tiver ocorrido antes). Os testes do consumidor e o contrato gerado são refinados com o feedback e a cooperação da equipe do provedor. Por último, o contrato finalizado é versionado e armazenado em um local central acessível por ambos, consumidor e provedor.

Contratos complementam documentos de especificação de API como o OpenAPI. Especificações de API descrevem a estrutura e o formato da API. Um contrato, por outro lado, especifica que para uma determinada solicitação, uma determinada resposta é esperada. Um documento de especificações de API é útil para escrever um contrato de API e pode ser usado para validar que o contrato está em conformidade com a especificação da API.

Verificação de Contrato do Provedor

Do lado do provedor, testes também são executados como parte de um pipeline separado que verifica contratos contra respostas reais do provedor. A verificação do contrato falha se as respostas reais diferirem das respostas esperadas, conforme especificado no contrato. A causa disso pode ser:

  1. Expectativas inválidas do lado do consumidor, levando à incompatibilidade com a implementação atual do provedor.
  2. Implementação defeituosa do provedor devido a alguma funcionalidade ausente ou a uma regressão.

De qualquer forma, graças ao CDC, é fácil identificar problemas de integração até o consumidor/provedor da interação afetada. Isso é uma grande vantagem em comparação com a dor de depuração que isso poderia ter sido com uma abordagem de teste E2E.

Frameworks e Ferramentas de Teste CDC

Pact é uma implementação de teste CDC que permite a simulação de respostas no código-base do consumidor e a verificação das interações no código-base do provedor, enquanto define uma especificação para contratos. Foi originalmente escrito em Ruby, mas tem wrappers disponíveis para várias linguagens. Pact é o padrão de facto a ser usado ao trabalhar com CDC.

Spring Cloud Contract é uma implementação de teste CDC da Spring e oferece fácil integração no ecossistema Spring. Suporte para provedores e consumidores não-Spring e não-JVM também existe.

Conclusão

O CDC tem vários benefícios que o tornam uma abordagem a ser considerada ao lidar com sistemas compostos por múltiplos componentes interagindo juntos.

Os esforços de manutenção podem ser reduzidos testando interações entre consumidor e provedor isoladamente, sem a necessidade de um ambiente integrado complexo, especialmente à medida que as interações entre componentes aumentam em número e se tornam mais complexas.

CDC VS Testes E2E

Além disso, uma colaboração próxima entre as equipes de consumidores e provedores é fortemente incentivada através do processo de desenvolvimento do CDC, o que pode trazer muitos outros benefícios. Contratos oferecem uma forma formal de documentar o entendimento compartilhado de como os componentes interagem entre si e servem como base para a comunicação entre as equipes. De certa forma, o repositório de contratos serve como uma documentação ao vivo de todas as interações entre consumidor e provedor de um sistema.

O CDC tem algumas desvantagens também. Uma camada extra de teste é adicionada, exigindo um investimento adequado em educação para que os membros da equipe entendam e usem o CDC corretamente.

Além disso, o escopo do teste CDC deve ser considerado cuidadosamente para evitar confundir o CDC com outras camadas de teste funcional de nível superior. Testes de contrato não são o lugar para verificar a lógica de negócios interna e a correção do consumidor.

Recursos