BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Notícias Usando o teste de contrato para aplicativos com microservices

Usando o teste de contrato para aplicativos com microservices

Ao usar microservices, os pontos de integração entre os serviços são um foco para bugs. O teste de contrato orientado pelo consumidor, é uma técnica em que o receptor define o contrato e as verificações são feitas contra esse contrato no ciclo de vida de criação/teste dos provedores. O teste de contrato se encaixa bem em um fluxo de trabalho de microservice e elimina seus erros de integração, argumentou Maarten Groeneweg, testador da Portbase, na European Testing Conference 2019.

As pessoas estão se afastando de grandes monólitos para ir em direção aos microservices, porque isso os ajuda a entregar em um ritmo mais rápido, com menos preocupação com a complexidade. Os microservices permitem que as equipes sejam liberadas de forma autônoma. Os testes de ponta a ponta estão acabando com o propósito de ter microservices, argumentou Groeneweg. Esses testes são lentos, de alta complexidade e as equipes dependem dos testes um do outro para passar para a produção.

Quando nos movemos na direção dos microservices, o número de pontos de integração explodirá. E cada um desses pontos de integração tem o risco de conter alguns bugs, disse Groeneweg. Especialmente quando os serviços são feitos por equipes diferentes, o risco de um pequeno ou grande mal entendimento no comportamento (esperado) é alto.

Groeneweg explicou que o teste de contrato consiste em três etapas:

  1. Como consumidor de uma API, você escreve um "contrato". Este contrato indica o que se espera do provedor (de uma API). Com base neste contrato, é gerado uma simulação do provedor.
  2. Como consumidor pode-se testar seu próprio aplicativo contra o mock do provedor.
  3. O contrato pode ser enviado ao fornecedor, que pode validar se a implementação real corresponde às expectativas do contrato.

O que torna o teste de contrato algo incrível é que o modelo faz isso de uma maneira que realmente se encaixa bem em um fluxo de trabalho de microservice, disse Groeneweg. O mais importante é que isso dissocia o teste entre o serviço que está usando a API (consumidor) e a própria API (provedor). Isso permite que levemos ambos para a produção sem um precisar do outro. É especialmente útil quando são mantidos por equipes diferentes, pois permitem que sejam autônomos em testes e lançamentos.

Groeneweg afirmou que o teste de contrato é uma maneira de reduzir o risco de erros de integração. Além disso, o teste de contrato é muito mais rápido do que outras formas de teste de integração. Isso é importante, pois nos permite diminuir o lead time e que matemos o desperdício, que é causado pelo lento feedback dos testes, disse ele.

Como o consumidor define o contrato, o teste do contrato também leva a melhores interfaces e APIs que são realmente usadas.

O InfoQ cobriu a Conferência Européia de Testes de 2019 e falou com Maarten Groeneweg sobre os testes de contrato.

InfoQ: Quais antipadrões existem nos testes de contrato e como podemos lidar com eles?

Maarten Groeneweg: O teste de contrato é um ótimo tipo de teste para reduzir o risco de integração entre os serviços. Mas, como em todo tipo de teste, às vezes pode ser difícil de implementar. Se quisermos iniciar com o teste de contrato, primeiramente gostaria de avisá-los destes sete antipadrões.

  1. A coisa boa sobre o teste de contrato é que permite que os consumidores de uma API anotem as expectativas. Isso pode impulsionar o desenvolvimento do provedor para fazer uma solução que melhor atenda aos desejos do consumidor. Mas, às vezes, passa do consumidor para o ditado pelo consumidor.
  2. As ferramentas podem tentar substituir a interação humana. Esse também é o caso do teste de contrato. Fazer uma solicitação de recurso sobre testes de contrato ou forçar equipes a escrever contratos antes de ter uma boa discussão cara a cara é uma má ideia.
  3. Ao criar testes, é importante ter cobertura adequada. Não se esqueça de testar os fluxos complexos que podem estar cheio de erros. Cenários como resultados zero ou falha na autenticação são rapidamente supervisionados. Mas esses são cenários típicos que podem falhar.
  4. Como consumidor, devemos apenas criar um contrato para o que precisamos. Não precisamos usar campos em contratos dos quais não utilizamos em nossos aplicativos. Desta forma, um provedor tem mais liberdade para alterar e otimizar seus serviços.
  5. Para fazer testes de contratos entre equipes, existe a necessidade de prévios alinhamentos. Se uma das equipes não concordar em participar, isso pode ser difícil. Por exemplo, como um provedor pode saber se as alterações não estão quebrando nenhum receptor, se nem todos os consumidores tiverem seus testes implementados? Portanto, antes de implementar o teste de contrato em sua organização, verifique se as equipes estão alinhadas.
  6. Às vezes as pessoas podem reclamar que o teste de contrato é complexo. E normalmente estão certos. Mas não deixe que isso os faça parar. Todo o teste de integração é complexo; basta olhar para os seus testes de ponta a ponta. Além disso, muita complexidade nos testes também pode ser o cheiro de uma solução muito complexa.
  7. Como todos os testes automatizados, os testes de contrato devem estar em execução no pipeline de entrega. Não queremos depender de humanos para executá-los, porque a qualquer momento podem esquecer de fazer isso. A configuração do pipeline para o teste de contrato pode ser um pouco mais complexa do que para outros testes. O consumidor e o provedor terão seu próprio canal e esses precisam se comunicar para garantir que os testes sejam aplicados em todos os casos. Esquecer de olhar para isso vai te custar muito caro. Por isso, é bom ler sobre esse assunto antes de começar.

InfoQ: Você mencionou o antipadrão de passar de orientando ao consumidor para ditado pelo consumidor. Como isso acontece?

Groeneweg: Vejamos o exemplo em que um consumidor exige uma combinação específica de campos na resposta. Para a equipe de provedores, essa combinação específica é difícil de ser implementada, pois é executada em bancos de dados diferentes, o que dificulta a implementação e normalmente, o desempenho será muito ruim. O consumidor continua pressionando essa solução específica, sem espaço para uma discussão saudável. Agora o contrato não é movido pelo desejo do consumidor, mas ditado pelo consumidor. Nessa situação, a equipe de provedores gastará muito tempo e esforço para acabar com uma solução que é muito lenta e todos ficarão frustrados. A abordagem correta, neste caso, é cooperar nos contratos e encontrar a solução que funcionam melhor para todos.

InfoQ: Se os leitores quiserem aprender mais sobre testes de contrato, onde eles podem procurar informações?

Groeneweg: Existem muitos recursos excelentes na internet sobre testes de contrato, incluindo algumas boas conversas. Eu realmente gosto da documentação do PACT (uma ferramenta de teste de contrato), também incluí alguns bons artigos sobre testes de contrato em geral. Além disso, listei alguns links úteis no meu site: teste de contrato.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT