mockito tutorial mockito framework
Um guia completo para a estrutura do Mockito: tutoriais práticos do Mockito
site para converter vídeos do youtube para mp3
O teste de unidade é uma técnica simples, mas eficaz, para obter um bom nível de confiança no código a ser enviado.
Além disso, evita problemas de regressão com cada pedaço de código que é verificado.
Com o tipo de arquitetura de microsserviços (e mesmo para uma estrutura simples envolvendo chamadas básicas de banco de dados), o teste de unidade direto não é suficiente. O que precisamos é simular as dependências e testar a lógica real do método em teste.
Lista de TODOS os tutoriais do Mockito nesta série:
Tutorial nº 1: Mockito Framework para simulação em testes de unidade (Este tutorial)
Tutorial # 2: Criando Mocks e Spies no Mockito
Tutorial nº 3: Diferentes tipos de correspondências fornecidas por Mockito
Tutorial nº 4: Zombar de métodos privados, estáticos e vazios usando Mockito
Tutorial # 5: As 12 principais perguntas da entrevista de Mockito
************************************************** * *******************
Visão geral dos tutoriais nesta série Mockito
Tutorial # | O que você aprenderá |
---|---|
Tutorial nº 1: | Mockito Framework para simulação em testes de unidade Aprenda a fazer mocking com o Mockito - um tutorial abrangente do Mockito para iniciantes com exemplos de código. Aprenda Mocking Framework para Mocking em testes de unidade. |
Tutorial # 2: | Criando Mocks e Spies no Mockito Mocks e Spies são tipos de testes duplos, que são úteis para escrever testes de unidade. Ambos são explicados neste tutorial do Mockito Spy com exemplos de código. |
Tutorial nº 3: | Diferentes tipos de correspondências fornecidas por Mockito Aprenda a usar diferentes tipos de matchers fornecidos pela Mockito. Matchers são como curingas onde, em vez de uma entrada / saída específica, você especifica um intervalo de entrada. Argumento e Verificação são os dois tipos de Matchers no Mockito que são explicados em detalhes aqui. |
Tutorial nº 4: | Zombar de métodos privados, estáticos e vazios usando Mockito Aprenda métodos de mocking privado, estático e vazio no Mockito com exemplos. Aprenda Mocking métodos privados e estáticos por unidade de teste framework PowerMockito. |
Tutorial # 5: | As 12 principais perguntas da entrevista de Mockito Mockito Entrevista perguntas e respostas com exemplos de código de exemplo. Isso o ajudará a quebrar qualquer entrevista do Mockito Mocking Framework com sucesso. |
Vamos começar com o primeiro tutorial desta série !!
O que você aprenderá:
- Zombar em testes de unidade
- Tipos / categorias de duplas de teste
- Diferentes estruturas de simulação
- Código fonte
- Conclusão
- Leitura recomendada
Zombar em testes de unidade
Mocks / Stubs é um termo que as pessoas geralmente ouvem durante a criação de testes de unidade em particular.
Então, o que é essencialmente Mocking? Em termos simples, nada mais é do que fornecer uma instância controlada ou implementação de dependência da qual o código em teste depende para testar sua lógica central.
O motivo pelo qual mencionei isso como uma instância controlada é que o comportamento da dependência pode ser programado ou controlado conforme desejado para o método ou sistema em teste.
Para explicar de forma esquemática, vamos dar um exemplo de qualquer aplicativo de negócios ou comércio eletrônico. Quase todo tipo de aplicação tem principalmente 3 camadas, ou seja, Interface do usuário, camada de negócios e camada de acesso a dados (que se comunica com o armazenamento de dados subjacente)
Com referência ao diagrama acima, a Camada de Negócios tem 3 dependências, ou seja, Camada de Acesso a Dados e 2 outros serviços que são o Serviço 1 e o Serviço 2.
Veja desta forma - um aplicativo como o Google Maps pode ter dependências de um
- Armazéns de dados reais como MySQL ou qualquer outro banco de dados sem SQL que armazena dados de mapas.
- Um serviço externo como CoordinateService, que fornece latitudes e longitudes de um local.
- Um serviço externo como o serviço de tráfego que fornece informações de tráfego em tempo real para um determinado par de coordenadas.
Portanto, se alguém está tentando validar a lógica de negócios principal usando o teste de unidade, até e a menos que tenha implementações de trabalho dessas dependências, os testes não poderiam ser executados.
Mocks vêm para resgatar nessas situações, onde não importa se sua dependência está funcionando ou não, você sempre tem a garantia de executar sua lógica de negócios com uma resposta programada para a dependência que está sendo chamada do código em teste.
Tipos / categorias de duplas de teste
Mock é essencialmente um tipo de “Teste duplo” - é um jargão técnico. “Teste duplo” significa essencialmente um objeto que é substituído por uma instância ou dependência de objeto real equivalente.
Existem diferentes tipos de duplas de teste, conforme mencionado abaixo:
# 1) Fakes:
Uma falsa é uma implementação funcional semelhante a uma dependência real, exceto pelo fato de ser local para o sistema em teste.
Exemplo: Em vez de atingir um banco de dados de produção real, o teste usa uma coleção simples / na memória para armazenar dados.
# 2) Stubs:
Stubs são respostas pré-configuradas quando uma dependência é chamada do sistema em teste.
# 3) Espiões:
Como o nome sugere, é na verdade a chamada de função real (dependência) com algum mecanismo de observação. Poste a chamada, pode-se verificar se a chamada foi realmente acionada ou não junto com os parâmetros.
# 4) Simulações:
Mocks são instâncias especiais de objetos, nos quais respostas stubbed / pré-configuradas podem ser especificadas. O fato de o mock ter sido chamado pode ser verificado como uma afirmação no teste.
Por exemplo:
Existe uma função de gerador de relatório que envia um e-mail para um endereço especificado durante a execução.
Como não queremos enviar e-mail real, repetidamente, durante o teste, o EmailService é simulado (e o método de e-mail que envia o e-mail é configurado para não fazer nada quando é chamado). No final do teste, podemos apenas verificar se o método de envio de email do serviço de email foi chamado por meio do objeto simulado.
Diferentes estruturas de simulação
Quase todas as linguagens fornecem diferentes tipos de estruturas de simulação. Estaremos escrevendo um código de amostra usando Mockito, que é uma estrutura de simulação de código aberto para Java.
Anatomia de um teste de unidade simples com dependência simulada. Suponha que estejamos tentando fazer um teste de unidade de um aplicativo que calcula as notas totais de um aluno em todas as disciplinas e as escreve no DB.
public void calculateSumAndStore(String studentId, int() scores) { int total = 0; for (int score: scores) { total = total + score; } // write total to DB databaseImpl.updateScores(studentId, total); }
Agora, se quisermos escrever um teste de unidade para o método - calculSumAndStore, então podemos não ter uma implementação real de um banco de dados para armazenar o total. Nesse caso, nunca poderemos realizar o teste de unidade desta função.
Mas com mocks no lugar, podemos simplesmente passar um Mock para o serviço de banco de dados e validar o resto da lógica
Teste de amostra conforme mostrado abaixo:
@Test public void calculateSumAndStore_withValidInput_shouldCalculateAndUpdateResultInDb() { // Arrange studentScores = new StudentScoreUpdates(mockDatabase); int() scores = { 60, 70, 90 }; Mockito.doNothing().when(mockDatabase).updateScores('student1', 220); // Act studentScores.calculateSumAndStore('student1', scores); // Assert Mockito.verify(mockDatabase, Mockito.times(1)).updateScores('student1', 220); }
Vimos no teste acima, fornecemos um objeto mockDatabase para a classe pai (para o método em teste) e configuramos uma resposta de stub para o objeto mockedDatabase - Linha # 6 acima (Mockito.doNothing (). When (mockDatabase) .updateScores (“student1”, 220);)
Os pontos importantes a serem observados acima são:
# 1) O objeto simulado precisa configurar respostas em stub para todos os métodos que serão chamados durante a execução da função.
#dois) Os parâmetros especificados durante a criação do stub podem ser específicos ou genéricos.
Exemplo no caso acima - especificamos os parâmetros para o método updateScores como “student1” e 220 porque sabemos que essas são as entradas exatas com as quais nosso método será chamado.
# 3) Durante a verificação, estamos validando o seguinte:
- O método mockDatabase.updateScores foi chamado.
- Os argumentos foram “student1” e 220 respectivamente.
- O método updateScores foi chamado 1 vez.
Agora vamos tentar mudar um pouco este código de teste e ver o que acontece:
Vou mudar o argumento na configuração simulada de 'student1' para anyString (Mockito fornece um matcher padrão chamado anyString ()) & 220 para anyInteger (Mockito fornece um matcher padrão chamado anyInt () e corresponde a qualquer valor inteiro)
@Test public void calculateSumAndStore_withValidInput_shouldCalculateAndUpdateResultInDb() { // Arrange studentScores = new StudentScoreUpdates(mockDatabase); int() scores = { 60, 70, 90 }; Mockito.doNothing().when(mockDatabase).updateScores(anyString(), anyInt()); // Act studentScores.calculateSumAndStore('student1', scores); // Assert Mockito.verify(mockDatabase, Mockito.times(1)).updateScores('student1', 220); }
Tente executar o teste novamente e o teste ainda deve estar verde.
(Agora, vamos tentar alterar a verificação / afirmações e alterar qualquer um dos argumentos.
Vamos mudar 220 para 230. Agora, a expectativa é que o teste falhe, pois este não é o argumento esperado com o qual o databaseUpdate deve ter sido chamado.
@Test public void calculateSumAndStore_withValidInput_shouldCalculateAndUpdateResultInDb() { // Arrange studentScores = new StudentScoreUpdates(mockDatabase); int() scores = { 60, 70, 90 }; Mockito.doNothing().when(mockDatabase).updateScores(anyString(), anyInt()); // Act studentScores.calculateSumAndStore('student1', scores); // Assert Mockito.verify(mockDatabase, Mockito.times(1)).updateScores('student1', 230); }
Depois de executar o teste, consulte os logs de erros conforme mostrado abaixo (menciona claramente que os argumentos reais não correspondem aos esperados).
O (s) argumento (s) são diferentes! Procurado:
mockDatabase.updateScores (“student1”, 230);
-> em com.mocking.sampleMocks.StudentScoreUpdatesUnitTests.calculateSumAndStore_withValidInput_shouldCalculateAndUpdateResultInDb (StudentScoreUpdatesUnitTests.java:37)
A invocação real tem argumentos diferentes:
mockDatabase.updateScores (“student1”, 220);
Código fonte
Interface - IDatabase.java
public interface IDatabase { public void updateScores(String studentId, int total); }
Classe em teste - StudentScoreUpdates.java
public class StudentScoreUpdates { public IDatabase databaseImpl; public StudentScoreUpdates(IDatabase databaseImpl) { this.databaseImpl = databaseImpl; } public void calculateSumAndStore(String studentId, int() scores) { int total = 0; for(int score : scores) { total = total + score; } // write total to DB databaseImpl.updateScores(studentId, total); } }
Classe de testes de unidade - StudentScoreUpdatesUnitTests.java
public class StudentScoreUpdatesUnitTests { @Mock public IDatabase mockDatabase; public StudentScoreUpdates studentScores; @BeforeEach public void beforeEach() { MockitoAnnotations.initMocks(this); } @Test public void calculateSumAndStore_withValidInput_shouldCalculateAndUpdateResultInDb() { // Arrange studentScores = new StudentScoreUpdates(mockDatabase); int() scores = {60,70,90}; Mockito.doNothing().when(mockDatabase).updateScores(anyString(), anyInt()); // Act studentScores.calculateSumAndStore('student1', scores); // Assert Mockito.verify(mockDatabase, Mockito.times(1)).updateScores('student1', 230); } }
Conclusão
O que vimos até agora é um exemplo muito básico e direto de configuração Mock usando o framework Mockito do Java.
Para quase 60-70% dos testes de unidade envolvendo simulações, os testes devem ter uma estrutura semelhante. Mockito fornece muita configuração / suporte avançado para necessidades extensas de mocking, injetando instâncias de mock usando injeção de dependência, fornece Spies para espionar uma chamada de método real e verificar as chamadas.
Nosso próximo tutorial explicará mais sobre o Conceito de Mocks e Spies no Mockito.
Leitura recomendada
- As 12 principais perguntas da entrevista de Mockito (Entrevista de Mocking Framework)
- Tutoriais detalhados do Eclipse para iniciantes
- Como configurar a estrutura de teste do Node.js: Tutorial do Node.js.
- Escrevendo testes de unidade com o Spock Framework
- As diferenças entre teste de unidade, teste de integração e teste funcional
- Melhores ferramentas de teste de software 2021 (QA Test Automation Tools)
- Tutorial de teste destrutivo e teste não destrutivo
- Teste Funcional Vs Teste Não Funcional