MUnit para programadores Java: duplas de teste

MUnit para programadores Java: duplas de teste

MUnit para programadores Java: duplas de teste
cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br


O que são duplos de teste?

Um duplo de teste é um termo usado para descrever a substituição de um componente dependente da funcionalidade que está sendo testada por uma versão fictícia do componente real – semelhante a um duplo de dublê, apenas para testes de unidade. O teste duplo precisa apenas emular o comportamento do componente dependente original o suficiente para que a funcionalidade em teste não detecte que não está usando o componente real.

Tipos de duplas de teste

Existem cinco tipos principais de duplas de teste: manequins, stubs, espiões, zombarias e falsificações. Embora cada um tenha um objetivo definido, na realidade, seu uso estrito é ignorado em favor de uma abordagem simplificada, na qual zombarias são usadas para substituir componentes reais e espiões são usados ​​para verificar o comportamento de objetos reais.

Um objeto simulado verifica se um componente está sendo usado corretamente pela função em teste. Se passar no teste de unidade, é provável que o objeto real seja usado da mesma maneira. Por outro lado, um espião permite chamar os métodos reais do objeto subjacente, além de rastrear e verificar todas as interações.

Zombaria

O JUnit não fornece uma funcionalidade de simulação, portanto, os desenvolvedores precisam chamar estruturas de teste colaborativas, como o Mockito. O Mockito é uma estrutura de teste de código aberto projetada para fornecer uma variedade de duplos de testes. Um mock do Mockito stubs uma chamada de método, o que significa que podemos stub um método para retornar um objeto específico. Normalmente, será um método que interage com um sistema externo, como um banco de dados. Zombar desse tipo de chamada de método significa que o banco de dados real não é necessário para o teste de unidade.

Vamos começar analisando como simular o uso do JUnit / Mockito e, em seguida, como isso é feito no MUnit.

Teste de unidade com Mockito

Considere uma fachada de serviço que executa ações CRUD simples por meio de uma instância de repositório. O repositório é apoiado por um banco de dados. No cenário de teste, queremos substituir o repositório por uma simulação para que os métodos na fachada do serviço possam ser testados.

A fachada do serviço gerencia o CRUD para um repositório de funcionários.

Fig 1: O Empregado Fachada de serviço que usa o EmployeeRepository.

O repositório do funcionário interage com o banco de dados. Substituí a configuração real do banco de dados por uma ArrayList para tornar o exemplo mais simples.

Fig 2: O EmployeeRepository interage com o banco de dados e será ridicularizado.

O Mockito é orientado por anotações, portanto, a configuração de zombarias é simplificada pelo uso do @Zombar anotação.

Fig 3: Mockito instancia zombarias.

Agora que o EmployeeRepositoy e Empregado objetos são zombados, cada teste de unidade pode testar os métodos do EmployeeService classe sem um método real do EmployeeRepositoy classe sendo chamada. Um exemplo disso está no seguinte caso de teste.

Fig 4: O caso que testa a funcionalidade de salvar funcionário.

O caso de teste chama o saveEmployee () método no EmployeeService que, por sua vez, chama o método save no EmployeeRepository classe, embora neste caso como o EmployeeRepository foi ridicularizado e um valor de retorno foi definido usando o quando() Mockito, o método zombado é chamado e não o método real. Portanto, estamos testando com segurança o saveEmployee () método.

O MUnit fornece um recurso de simulação que atende ao mesmo requisito de simulação.

Munit Mock Quando

O MUnit permite que os processadores de eventos, como conectores de banco de dados e referências de fluxo, sejam zombados. No exemplo abaixo do serviço ao empregado fluxo chama o empregado persistente subfluxo. O que o MUnit fornece Zombar de Quando recurso para simular a chamada para o subfluxo, para que o serviço ao empregado o fluxo pode ser testado.

Fig 5: O fluxo de serviço dos funcionários usa o empregado persistente subfluxo.

O teste MUnit intercepta chamadas para o empregado persistente subfluxo e substitui a resposta por um objeto JSON de carga útil codificado:

Fig 6: MUnit simulado quando O recurso zomba de uma chamada para o empregado persistente subfluxo.

o serviço ao empregado o fluxo é testado sem que seja feita uma chamada para o banco de dados externo.

Espião

Um espião Mockito funciona como uma zombaria parcial. Alguns dos métodos do objeto podem ser removidos, enquanto outros não, permitindo invocações desses métodos reais. Portanto, chamar um método para um espião invocará o método real, a menos que tenha sido stub.

Vamos voltar ao EmployeeService exemplo. o EmployeeRepository foi marcado com o @Espião anotação e o Salve () O método foi removido. Todos os outros métodos permanecem sem interrupção. O teste JUnit chama o saveEmployee método que delega a chamada para a versão stubbed e retorna o objeto empregado simulado. Todos os outros métodos permanecem desmarcados e, se chamados, invocam o método real.

Fig 7: O teste chamará de zombado Salve () quando saveEmployee () é chamado.

MUnit Spy

O MUnit fornece um recurso de espionagem, no entanto, sua implementação é uma interpretação literal do que o espião significa no sentido em que realmente permite que o teste examine e afirme o estado de um objeto antes e depois da execução de um processador de eventos.

Usando o mesmo fluxo que no exemplo anterior, o espião MUnit pode ser usado para verificar o sata do objeto de carga útil antes e depois da execução do empregado persistente subfluxo.

Fig 8: O espião MUnit afirma no estado antes e depois da execução do processador de eventos.

O teste afirma que a carga útil é NULL antes da chamada para o fluxo de funcionário persistente e que possui um valor posteriormente.

Verificar chamada

As invocações de métodos geralmente precisam ser verificadas, foram chamadas um determinado número de vezes. Mockito fornece o verificar() método que determina o número de vezes que um método foi chamado.

Fig 9: O excluir() O método do repositório deve ser chamado quando deleteEmployee é chamado.

MUnit verificar chamada

O MUnit oferece a mesma funcionalidade em que uma chamada para um processador de eventos pode verificar se foi chamada um certo número de vezes ou por um número maior ou menor de vezes

Fig 10: Verifique se o Persistir Funcionário o fluxo é chamado uma vez.

Testes de falha / exceção

É tão importante testar os caminhos positivos quanto os negativos. É aqui que o teste de exceção desempenha um papel. Precisamos garantir que, quando algo der errado, a exceção correta seja lançada. JUnit e MUnit fornecem funcionalidade para esse tipo de teste.

O JUnit oferece duas maneiras de especificar que uma determinada exceção é esperada por meio de anotações ou com um ExpectedException regra. Vamos ver como usar a anotação.

Fig 11: Exceção esperada especificada na anotação.

O teste será aprovado se o IndexOutOfBoundsException é jogado. Qualquer outra exceção falhará no teste.

Teste de exceção MUnit

O MUnit fornece esse mesmo recurso. O erro esperado está configurado no próprio fluxo de teste do MUnit.

Fig 12: Defina o erro esperado no próprio teste do MUnit.

O erro Mule é definido no fluxo de teste da munit e, se lançado durante a execução do teste, o teste será aprovado. No exemplo de código, o teste Munit espera o tipo de erro MULE: CONECTIVIDADE e nos testes munit: execução corpo o Aumentar erro processador de eventos simula o MULE: CONECTIVIDADE erro. O teste será aprovado porque esse erro é esperado.

Afirmar falha

Semelhante ao teste de exceção, uma falha no teste pode avaliar se um determinado comportamento não ocorre. JUnit fornece o Assert.fail () asserção que fará com que uma execução de caso de teste falhe.

Fig 13: O teste falhará se a exceção esperada não for lançada.

No exemplo, o caso de teste falhará se o Exceção de argumento ilegal exceção não é lançada.

Evento de falha de Munit

O Munit pode replicar esse comportamento com o Falhou processador de eventos.

Fig 14: O caso de teste falhará com a mensagem “Payload is a CAT”

Quando o Falhou Se o processador de eventos for encontrado, o caso de teste falhará com a mensagem fornecida.

Conclusão

Os testes duplos, como zombarias e espiões, são uma parte fundamental da construção de um conjunto determinístico de suítes de testes. O MUnit suporta totalmente zombaria e fornece sua própria interpretação literal de espiões, que se desvia do comportamento no JUnit. Para desenvolvedores Java que desejam aprender mais, o conhecimento de integração do Mule encontrará seus conhecimentos e habilidades atuais diretamente aplicáveis ​​à criação de testes duplos e de exceção no MUnit.
Se você estiver interessado em aprender mais sobre o MUnit e atividades relacionadas ao DevOps essenciais para implementar aplicativos Mule prontos para produção, considere nosso curso Anypoint Platform Development: Production-Ready Development Practices (Mule 4).


cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br
Luiz Presso
Luiz Presso