introduction contract testing with examples
Este tutorial de Teste de Contrato de Pacto explica o que é Teste de Contrato Orientado ao Consumidor, como funciona e por que você deve usá-lo em sua estratégia de teste:
O que é o teste de contrato?
O Teste de Contrato Orientado ao Consumidor é uma forma de teste de API que realmente permite mudar para a esquerda. A ferramenta de contrato que usamos é Pact.io , e aprenderemos sobre isso mais tarde nesta série de tutoriais.
O teste de contrato é um método para verificar a integração entre dois aplicativos de forma independente, a fim de testar o que foi aprovado e ver se o que é retornado corresponde ao “contrato”.
Os testes de contrato se encaixam perfeitamente em uma arquitetura de microsserviço, operando em um ambiente ágil. Portanto, os exemplos serão baseados na experiência que adquirimos ao trabalhar neste ambiente.
O que você aprenderá:
- Lista de tutoriais nesta série de testes de contrato
- Teste de contrato orientado para o consumidor
- Teste de contrato vs. teste de integração
- Integração contínua
- Conclusão
Lista de tutoriais nesta série de testes de contrato
Tutorial # 1: Introdução ao teste de contrato com exemplos (Este tutorial)
Tutorial # 2: Como escrever um teste de pacto do consumidor em JavaScript
Tutorial nº 3: Como Publicar Contrato do Pacto para Corretor do Pacto
Tutorial nº 4: Verificar contrato de pacto e implantação contínua com Pact CLI
Teste de contrato orientado para o consumidor
O ponto de partida é a documentação da API que forma o contrato para seus testes, neste ponto geralmente, as equipes de desenvolvimento pegam o documento API e desenvolvem contra o documento wiki (ou qualquer formato que resida em sua organização, como Documento Word).
Por exemplo, um aplicativo da Web em que o front-end está sendo desenvolvido pela Team Krypton e a API está sendo desenvolvida pela Team Thoron. O projeto começa com uma reunião de kick-off onde os requisitos são apresentados e pactuados entre as equipes.
Cada equipe pega os requisitos e começa a criar o backlog refinando as histórias. O desenvolvimento começa em ambas as equipes seguindo as histórias de usuário, o teste de integração é deixado para sprints posteriores. À medida que a equipe Krypton encontra requisitos adicionais, relacionados a cenários de erro, a documentação da API é atualizada de acordo.
Casos de teste são adicionados pela Equipe Thoron relacionados aos cenários atualizados com base na documentação.
Já podemos ver algumas falhas neste processo, e adicionei mais algumas para dar sorte:
- As alterações do documento API podem não ser comunicadas de forma eficaz.
- A equipe de front-end corta o serviço de back-end e vice-versa.
- A equipe de back-end cria casos de teste de integração com base na documentação.
- O ambiente de integração é a primeira vez em que a integração completa é testada.
- Versão de API diferente no ambiente de integração vs produção.
O teste de contrato orientado para o consumidor tem dois lados, ou seja, o consumidor e o fornecedor. É aqui que o pensamento tradicional sobre teste em microsserviços é invertido.
O Consumidor é o curador dos cenários, incluindo a solicitação e a resposta esperada. Isso permite que você siga Lei de Bed o que determina que você deve ser flexível no que sua API pode aceitar, mas conservador no que é enviado. Referindo-se às falhas no. 1, 3 e 4, as alterações na documentação são conduzidas pelo consumidor.
Por exemplo, na circunstância em que a equipe Thoron altera um campo de string para não aceitar valores nulos, os testes do consumidor não refletem a alteração e, portanto, apresentam falha. Ou pelo menos até que as mudanças fossem feitas na Equipe Krypton.
(imagem fonte )
O Fornecedor verifica os cenários fornecidos pelo consumidor em relação ao ambiente “dev”. Isso permite que seus microsserviços imponham Mudança Paralela que afirma que você deve expandir a funcionalidade da API, seguido pela migração para uma nova versão. Referindo-se à falha no. 2, os stubs normalmente criados pelas equipes de back-end para seus próprios requisitos de teste agora podem ser baseados nos cenários de consumidor usando Servidor Pact Stub .
O elemento de ligação dos dois lados é o “contrato” que deve ser compartilhado entre as equipes. O pacto fornece uma plataforma para permitir o compartilhamento de contratos chamada de Corretor de Pacto (disponível como um serviço gerenciado com Pactflow.io )
O Corretor armazena a saída dos cenários do consumidor. O contrato é então armazenado no corretor junto com a versão da API. Isso permite o teste em várias versões da API, portanto, a compatibilidade pode ser confirmada antes do lançamento, conforme destacado na falha no.5.
Um benefício agregado ao Pact Broker nas plataformas legadas é a visibilidade dos consumidores. Nem todos os consumidores são conhecidos pelos autores da API, especialmente não é como está sendo consumida.
Referindo-se especificamente a uma ocorrência em que duas versões da API eram suportadas, havia um problema de dados na versão 1 (V1) em que a API estava causando dados sujos no banco de dados.
A mudança foi implementada na V1 da API e colocada em produção, porém o consumidor confiava no formato que estava causando o problema de dados, interrompendo assim a integração com a API.
Como funciona
O exemplo acima mostra o fluxo de autenticação, o serviço web requer que os usuários se autentiquem para acessar os dados confidenciais. O serviço da web envia uma solicitação à API para gerar um token usando um nome de usuário e uma senha. A API retorna um token do portador que é adicionado à solicitação de dados como um cabeçalho de autenticação.
O teste de consumidor constrói uma solicitação POST para um token passando o corpo com nome de usuário e senha.
Um servidor simulado é ativado durante o teste, que valida a solicitação que você construiu, junto com a resposta esperada que neste exemplo inclui o valor do token.
A saída do teste do consumidor gera um arquivo de contrato de pacto. Isso será armazenado no corretor do pacto como versão 1.
O provedor então puxa a versão 1 do corretor do pacto e reproduz essa solicitação em seu ambiente local, verificando a correspondência da solicitação e da resposta com os requisitos do consumidor.
Papéis e responsabilidades
Garantia de Qualidade (QA) / Testador: Criando contratos usando Pact.io e trabalhando com o BA para gerar os cenários de teste.
Desenvolvedor: Emparelhar com o QA na criação de testes e ajudar a preparar a API para implementação em Integração Contínua (CI).
Analista de Negócios (BA): Gerar os cenários e trabalhar com o arquiteto para verificar as partes afetadas.
Solução de arquitetura (Pode não existir em sua organização): Acionar as mudanças da API e coordenar com o BA na implementação, também comunicando as mudanças aos consumidores (usando o Pact Broker para entender a quem pode interessar).
Gerenciamento de liberação: (Sim, eu sei que é antiquado, mas ainda existe no meu mundo): Cheio de confiança de que as alterações serão lançadas com sucesso devido à cobertura de teste do contrato.
Equipe inteira: Verifique os resultados para determinar se os lançamentos podem ser enviados para produção com a ferramenta Pact CLI, Posso implantar .
Teste de contrato vs. teste de integração
O teste de integração deve existir para validar se o sistema está funcionando antes da promoção para o ambiente de produção, mas os cenários podem ser significativamente reduzidos.
O impacto disso pode ser:
- Feedback mais rápido antes de liberar para o ambiente de integração.
- Menos confiança na estabilidade do ambiente de integração.
- Menos ambientes com suporte para várias versões de API.
- Instâncias de ambiente instável reduzidas devido a problemas de integração.
| Integração | Contrato | |
|---|---|---|
| Identificar claramente a falha | Muitas camadas | Muito fácil |
| Configuração de API | sim | Não |
| Verificações de implantação | sim | Não |
| Controle de versão de API | sim | sim |
| Depurar localmente | Não | sim |
| Problemas ambientais | sim | Não |
| Tempo de Feedback | Lento | Rápido |
Em primeiro lugar, o teste de contrato não substitui o teste de integração. Mas provavelmente pode substituir alguns de seus cenários de teste de integração existentes, deslocar para a esquerda e fornecer um feedback mais rápido para o ciclo de vida de desenvolvimento de software.
No teste de integração, você verificará o contexto em que a API reside, como a arquitetura do ambiente, o processo de implantação, etc.
Portanto, você deseja executar os cenários de teste principais que confirmariam a configuração, por exemplo, o endpoint de verificação de integridade para a versão da API. Também provando se a implantação foi bem-sucedida, retornando uma resposta 200.
No teste de contrato, você está testando as especificações da API, que incluem os casos extremos relacionados à estrutura da API, conteúdo (por exemplo, valores de campo, existem chaves) e respostas de erro. Por exemplo, a API lida com valores nulos ou eles são retirados da resposta da API (outro exemplo real).
Alguns benefícios (se você ainda não tiver vendido)
Listados abaixo estão alguns dos benefícios a serem aproveitados ao vender testes de contrato para o negócio em geral:
- Implantação mais rápida de software
- Uma única fonte de verdade
- Visibilidade de todos os consumidores
- Facilidade de teste em diferentes versões de API.
perguntas frequentes
Algumas perguntas comuns ao tentar persuadir as pessoas a adotar os testes de contrato incluem:
P # 1) Já temos 100% de cobertura de teste, então não precisamos dela.
Responda: Bem, isso é impossível, mas o teste de contrato tem muitos outros benefícios além da cobertura de teste.
P # 2) É responsabilidade do Arquiteto de Soluções comunicar as mudanças de API.
Responda: A qualidade é responsabilidade de toda a equipe.
P # 3) Por que estamos criando os cenários de teste para a equipe de API?
Responda: A equipe da API não sabe como o serviço da web funciona, então por que deveria haver responsabilidade?
P # 4) Nossos testes de ponta a ponta cobrem todo o fluxo do início ao fim, incluindo outros pontos de integração.
Responda: Exatamente por que estamos dividindo os testes para testar uma coisa e não é sua responsabilidade testar o fluxo de ponta a ponta de um sistema que você não sabe como funciona.
P # 5) Em qual repositório da equipe os testes residem?
Responda: Ambos. O consumidor em seu repositório e o Provedor em seu. Então, no ponto central, o contrato vive fora de qualquer um deles.
Argumentos
Estes são os argumentos contra os quais achamos difícil argumentar quando se trata da transição para o contrato para teste:
- Documentação Swagger já implementada que pode ser usada para gerar testes de integração.
- As equipes possuem serviços de front-end e back-end com um mecanismo eficaz para alterações de API.
Integração contínua
Como isso se encaixa em seu conjunto de testes de integração contínua? O lugar desejável para o teste de contrato viver é com seus testes de unidade.
Os testes de consumidor geram um servidor simulado que não requer dependências externas fora do teste.
proteção de firewall grátis para windows 10
Os testes de provedor requerem uma instância de API, portanto, a API local pode ser encapsulada usando um servidor de teste na memória . No entanto, se não for fácil agrupar sua API localmente, uma solução alternativa que usamos anteriormente é criar um ambiente e implantar o código nesse ambiente como parte das verificações automatizadas de solicitação pull.
(imagem fonte )
Conclusão
Neste tutorial, aprendemos o que significa teste de contrato e como ele se parece em uma infraestrutura de microsserviço, e vimos como fica em um exemplo do mundo real.
Lições foram aprendidas sobre como os testes de contrato podem ajudá-lo a mudar seus testes de integração para a esquerda. Além disso, vimos como isso pode reduzir custos para sua organização, reduzindo o tempo de feedback relacionado a problemas de integração.
O teste de contrato não é apenas uma ferramenta para teste técnico, ele reforça a colaboração das equipes de desenvolvimento, comunicando as mudanças e incentivando o teste como uma unidade. No geral, esse deve ser um pré-requisito para qualquer pessoa que pretenda mudar para a implantação contínua.
PRÓXIMO Tutorial
Leitura recomendada
- Como escrever um teste de pacto do consumidor em JavaScript
- Verificar contrato de pacto e implantação contínua com Pact CLI
- Como Publicar Contrato do Pacto para Corretor do Pacto
- Processo de integração contínua: como melhorar a qualidade do software e reduzir o risco
- As diferenças entre teste de unidade, teste de integração e teste funcional
- O que é teste de integração (tutorial com exemplo de teste de integração)
- Dez principais ferramentas de teste de integração para escrever testes de integração
- Implantação contínua em DevOps