Mock it with MockitoUm framework para a construção de testes unitários melhores

Quem sou eu?

● Renan Uchôa,

○ estudante de Engenharia de Software pela Universidade Federal do Pampa,

○ e Desenvolvedor Java pela uMov.me Tecnologia S.A.

Testes unitários

● Testes unitários servem para verificar comportamentos de unidade em um sistema.

● Cada teste deve ser independente e atômico o suficiente para não depender de outras unidades que não estiverem sendo testadas

Testes unitários

Sabemos que existe uma diferença entre testes de caixa-preta e caixa-branca.

Testes unitários

Testes de caixa-preta verificam as saídas de um sistema com base nas entradas inputadas, sem um prévio conhecimento sobre a estrutura do programa.

Testes de caixa-branca verificam comportamentos internos da estrutura do software para serem abordados nos casos de teste.

Testes unitários

E que os testes unitários se encaixam no conceito de testes de caixa-branca…

… pois permitem ao desenvolvedor construir testes diretamente baseados no código-fonte e nos comportamentos apresentados pelas unidades do software.

Testes unitários

Porém apesar de todos os recursos disponíveis com o JUnit e na linguagem Java, construir testes realmente úteis ainda é um desafio.

Testes baseados apenas em retorno de métodos não são suficientes para cobrir o código.

Falta interagir com o método de maneira mais livre.

Como assim?

● E todas as decisões tomadas no código?● E os comportamentos implícitos no teste?● E todo o processo realizado até devolver o

resultado do método?

○ Será que nada disso é relevante para o teste?

● E se o retorno do método não me disser exatamente o que ele fez?

● E como testar um método sem retorno?

Dúvidas, dúvidas, dúvidas...

Mockito: simpler and better mocking

Mockito permite:● ter maior flexibilidade na hora de testar

cada comportamento;● isolar a unidade testada do restante do

código;● manter os testes legíveis e simples

Keep It Simple, Stupid...

Problema

Eu quero testar um comportamento que inativa um determinado usuário do sistema após a terceira tentativa de informar a senha.

Porém:● Não quero que o teste unitário se preocupe

com questões de acesso ao banco de dados;● Quero verificar apenas se o status foi

alterado e se o método de salvar no banco de dados foi chamado;

Sugestão

Trabalhar com Mockito pode ajudar a resolver esse problema.

Primeiramente é preciso baixar a biblioteca do framework em Java através de um .jar disponível através do link http://code.google.com/p/mockito/

E não esqueça de importá-la em seu projeto.

Resolução

Resolução

Passos:● Importar os métodos estáticos da biblioteca para

dentro da classe de testes;

● "Mockar" a classe UserDao, para simular a interação com o banco de dados;

● Chamar o método login() que será testado a partir da classe UserService;

● Usar o verify() do Mockito para verificar se método login() chama o update() na terceira vez que a senha estiver incorreta.

Vantagens

Desta maneira eu garanto que o meu código invocará o acesso ao banco de dados quando necessário,…

… porém os meus testes não sofrerão com as instabilidades do banco de dados, pois não dependem disso para funcionarem.

… mas

Assim fica fácil

Com isso manter uma suíte de testes unitários fica muito mais seguro e tranquilo.

Mockito

O mockito é utilizado para sobrescrever comportamentos dependentes que fogem ao escopo do teste implementado.

Não faz sentido permitir que problemas envolvidos com a classe UserDao afetem os testes realizados sobre a classe UserService.

Usando o Mockito, todos os métodos da classe UserDao são sobrescritos e retornam 'null'

Mockito

Com um "mock" em mãos, podemos verificar quantas vezes um determinado método foi invocado, manipular o comportamento informando um retorno "fake" para simular o funcionamento normal da classe, capturar um determinado objeto enviado por parâmetro, e etc.

Verify

Usando o método verify(), é possível verificar quantas vezes um determinado método "mockado" foi chamado durante o teste.

Isso é possível através dos métodos times(), never(), only(), atLeast(), atMost(), calls(), atLeastOnce(), com os respectivos parâmetros.

Ex.: verify(dao, never()).update(any(User.class));

Verify

Veja no exemplo abaixo…

● Construímos uma lista com 5 usuários

● Invocamos um serviço que deve cadasrtrar todos os usuários listados

● verificamos se o método save foi chamado 5 vezes passando qualquer instância da classe 'User'

when().thenReturn()

O método when() permite simular retornos de métodos ou lançamentos de exceção.

Dado que eu não quero que um método seja executado, porém eu dependo de um retorno para que o método testado continue funcionando…

Então eu informo qual objeto deve ser retornado quando o método for invocado.

when().thenReturn()

Dado que o método save() será invocado pelo service.register()

Quando isso acontecer, ele deve apenas retornar o mesmo objeto passado por parâmetro

Sem realizar operações sobre o banco de dados…

any(),…

Existem vários matcher que podem ser usados para inferir sobre os parâmetros passados nos métodos…

any(class), anyLong(), anyString(), indicando que será esperado qualquer parâmetro de um determinado tipo…

Também é possível dizer o valor exato que será esperado através do eq()

e muito mais…

Para os curiosos, existem também alternativas para capturar argumentos em chamadas de métodos, usando o ArgumentCaptor…

… fazer verificações em objetos concretos não mockados, através do spy()…

e utilizar vários matchers úteis como isNull(), same(), startsWith(), endsWith(), contains(), isA(class), doNothing(), doThrow(),…

Use mockito nos seus testes,

… e deixe a brincadeira acontecer