BDD - desenvolvimento através do comportamento. O BDD para microsserviços é uma colaboração do cliente, desenvolvedores e testadores. O BDD é um desenvolvimento que leva em consideração interesses técnicos e requisitos de negócios. Essa abordagem geralmente é usada para descrever interfaces de aplicativos e, como os microsserviços são os detalhes da implementação do sistema, o BDD também é adequado para o desenvolvimento de microsserviços. Como fazê-lo - na tradução de Ken Pugh.
Sobre o autor: Ken Pugh ensina as empresas a desenvolver flexibilidade, cria sistemas de alta qualidade usando o Development-Driven Development, BDD, aceleração de DevOps. Ken escreveu vários livros sobre desenvolvimento de software e foi vencedor do Jolt Award 2006 Prefactoring, um dos criadores do curso de Engenharia de Software Ágil da SAFe.
O comportamento no BDD é geralmente expresso pelo construto Given / When / Then. Nos é dado um determinado estado quando uma ação ou evento ocorre, então o estado muda e / ou as informações são retornadas.
Por exemplo, a lógica sem estado, como regras de negócios e cálculos, descreve simplesmente a conversão de entrada em saída.
O Design Orientado a Interface usa o princípio de
"design para interfaces, não implementações" . Os consumidores do serviço usam a interface que ele fornece, não os internos. Isso significa que essa interface deve ser claramente pensada, incluindo comportamento de erro. Para definição de termos na descrição da interface ou seu comportamento, é possível usar DDD - Domain Driven Design.
Os microsserviços podem ser síncronos quando o consumidor
chama diretamente outro serviço e espera o resultado, ou assíncronos quando o
serviço responde a uma mensagem que o cliente colocou na fila .
Considere um exemplo de serviço síncrono.
Serviço síncrono
Imagine um serviço que calcula um desconto em um pedido de vendas.O processo todo é um conjunto de operações relacionadas.
O comportamento deste serviço pode ser descrito da seguinte maneira:
Get discount for a customer Given these inputs Customer category Order Amount Then service outputs Discount Amount
O serviço pode calcular o desconto usando algoritmos no código, com base no banco de dados de dados local ou entrando em contato com outros serviços.
Pode usar JSON ou XML como um formato de mensagem. No entanto, descrever o serviço sem especificar detalhes da implementação ajuda a separar a semântica das operações da sintaxe.
Qual é o comportamento?
Usando o BDD, você pode começar a projetar com dados de amostra para ter uma idéia do comportamento desejado. Os desenvolvedores de serviços, clientes e testadores podem criar esse exemplo. As duas primeiras colunas são a entrada para o serviço e a coluna à direita é a saída.
O exemplo mostra termos de domínio que podem exigir refinamentos adicionais - por exemplo, descreva valores válidos.
Entende-se que o serviço retornará o resultado correto se os dados de entrada estiverem dentro da faixa de valores aceitáveis.
A descrição do comportamento, especialmente para microsserviços, geralmente inclui respostas no caso de falhas e erros. Uma descrição de possíveis falhas ajuda o consumidor a entender o que fazer nesses casos. Os clientes do serviço podem usar bibliotecas especiais, por exemplo, Hystrix, da Netflix, para corrigir algumas dessas falhas.
Alguns erros em potencial do nosso serviço:
As falhas podem ser expressas como constantes numéricas ou de caracteres no protocolo de comunicação.
O uso de nomes significativos no BDD ajuda a enfatizar a semântica de uma falha, não sua sintaxe.
Se o valor que foi passado como categoria não estiver na lista de valores válidos, o serviço retornará um indicador de falha: "Valor inválido dos parâmetros de consulta". Isso pode ser representado, por exemplo, retornando o código HTTP 400 e a descrição de texto correspondente.
Como alternativa, você pode determinar o valor do desconto que será retornado, por exemplo, 0 se algum dos parâmetros estiver incorreto. Nesse caso, o serviço deve ser responsável por registrar esse problema para que suas conseqüências possam ser analisadas.
Os testes de serviço BDD podem formar um contexto para seus testes de unidade. No processo de design, a
responsabilidade de passar nos testes do BDD recai sobre classes e métodos . Os testes de unidade determinam essas responsabilidades.
Stubs
Ao testar um serviço, geralmente são necessários stubs de serviços dependentes que ele chama. Eles são especialmente necessários para serviços lentos, caros ou aleatórios. Se o comportamento do serviço de desconto nunca mudou, ao testar o cliente, você pode usar a instância de combate.
A mudança geralmente é inevitável, portanto, geralmente são necessários stubs.
Um stub sempre pode retornar os mesmos valores, por exemplo:
Os testes do cliente podem confiar nesses valores. Neste exemplo, o comportamento constante pode ser suficiente. Para outros testes, é preferível uma resposta de stub personalizada.
Como alternativa, o stub do serviço de desconto pode simplesmente retornar o mesmo valor, independentemente da entrada.
Como esse esboço se encaixa em um cenário mais amplo? Considere o comportamento do sistema para um pedido, que inclui um desconto e um imposto. O imposto é calculado pelo microsserviço, semelhante ao desconto.
Existe um comprador.
Desconto ajustável.
O imposto está estabelecido.
Quando um cliente faz um pedido:
Encomende as opções.
Serviços com estado
Se o serviço de desconto usar o banco de dados para obter informações para calcular o desconto, seu conteúdo será o estado do serviço. Alterações de estado em resposta a atualizações de dados devem ser documentadas. Suponha que o serviço tenha esse estado.
Nesse caso, o serviço deve permitir a alteração desses dados. A atualização pode ser organizada para que elementos individuais sejam atualizados ou a tabela inteira seja atualizada imediatamente. Aqui está um exemplo de um teste comportamental para uma atualização individual.
Dados os dados atuais.
Quando um item é atualizado.
Dados atualizados.
Você também pode verificar se os dados atualizados são usados para calcular o desconto.
O serviço de desconto pode ter armazenamento local para salvar dados neste exemplo, mas também pode depender de um serviço de armazenamento separado para esses dados. Nesse caso, os testes da seção anterior se aplicam a um serviço separado. Mas todo vício acrescenta problemas. Qual deve ser o comportamento de um serviço se suas dependências não estiverem disponíveis? Para um serviço de desconto, isso deve indicar uma falha ou deve simplesmente retornar o valor padrão, o mesmo 0? Às vezes, você pode usar políticas globais de tratamento de erros, mas
geralmente a decisão depende do contexto do serviço .
Formulação e automação de testes
Uma vez que o comportamento do microsserviço seja consistente, ele poderá ser formulado como testes automatizados. Existem vários sistemas de teste de microsserviços, como PACT ou Karate. Além disso, você pode usar estruturas de BDD, como Pepino ou FIT.
Por exemplo, o Pepino usa bibliotecas para consultar serviços. Em seguida, informações adicionais sobre o ambiente podem ser apresentadas como parte do script.
Por exemplo, um arquivo de objeto de pepino pode incluir.
As opções da etapa dependem das suas convenções de teste.
Os valores nas duas primeiras colunas podem ser transferidos para qualquer convenção de chamada, por exemplo, para consultar parâmetros. O resultado no corpo deve corresponder à terceira coluna. Se os nomes e os valores da consulta forem os nomes e os valores das colunas, isso reduzirá as diferenças entre o teste e a implementação.
Para reutilização, as etapas podem ser escritas para um serviço arbitrário que faz cálculos ou determina o resultado de uma regra de negócios. No exemplo acima, o uso do símbolo "?", Como no "Valor do desconto" acima, ajuda o analisador a distinguir entre entrada e saída.
Os testes também devem incluir falhas, por exemplo.
Conclusão
Os microsserviços dependem de outros serviços e sistemas, o que requer uma especificação clara das interfaces e seus testes precisos. Isso pode ser conseguido descrevendo o comportamento e as interfaces definidas pelos testes. Usando o BDD, a funcionalidade dos serviços é descrita por testes executáveis que se concentram
na semântica das operações, e não na sintaxe . A automação de tais testes geralmente requer a configuração de stubs de outros serviços, cujo comportamento é descrito por seus testes individuais de BDD.
Design orientado a interface - IOD, inclui obrigações adicionais do serviço: restrição no uso de recursos, largura de banda e relatórios de erros. Juntos, o BDD e o IOD ajudam a descrever o comportamento do serviço, para que os clientes possam entender e confiar facilmente nele.
- O BDD para microsserviços concentra-se na cooperação da tríade - desenvolvedor de serviços, desenvolvedor de clientes e testador.
- Crie convenções claramente definidas para interfaces de microsserviço usando o IOD.
- Os microsserviços geralmente exigem conectores de teste para acelerar os testes.
- Os testes devem ser independentes.
- Teste cenários negativos em testes.
De 27 a 28 de maio, durante o festival RIT ++ , na conferência QualityConf, Artyom Malyshev discutirá a importância de expressar claramente o modelo de domínio no código e mostrará como fazer isso usando exemplos.
Venha falar sobre o desenvolvimento de produtos de qualidade e compartilhe suas idéias!