Solucionado (ver solução)
Solucionado
(ver solução)
4
respostas

Testes Unitários de EJB's e DAO's

Olá Pessoal, tudo bem?

Sabem se com o Mockito, apresentado neste curso, consigo fazer testes unitários nos EJB's e DAO's do meu projeto? Caso tenha, conhecem alguma boa documentação pra eu estudar? Hoje tenho um projeto rodando no Wildfly 11, utilizando REST, e os services e dao's com EJB. Gostaria de saber também se é possível integrar os testes com o Rest Assured e o Mockito, pra eu não testar diretamente no meu banco. Obrigado.

4 respostas

Para fazer testes unitários o Mockito tem tudo que você precisa - com os MockitoAnnotations fica muito fácil injetar os mocks - basta declarar todos os objetos com a anotação @Mock, e o objeto em teste como @InjectMocks. Mas lembre-se de que nos testes unitários você está testando uma classe por vez - todos os objetos dos quais ela depende serão mockados, não podendo ser injetados do EJB ou CDI. O Rest Assured é bom para testes de integração na camada REST - mas você vai ter de ter o servidor rodando para rodar os testes - e mais, ele deve rodar em um ambiente controlado, onde cada teste sabe exatamente o que esperar de resposta, para que os testes sejam repetíveis.

Olá Leonardo,

Obrigado pelos esclarecimentos. Você sabe de alguma documentação onde eu possa ver exemplos práticos de como usar as anotações do Mockito nas classes DAO's?

De cabeça não conheço - encontrei uma boa aqui:

http://www.baeldung.com/mockito-annotations

Mas é muito fácil usar - basta usar a anotação "@RunWith(MockitoJUnitRunner.class)" na classe, colocar "@Mock" em cada objeto a ser mockado, e "@InjectMocks" na classe que vai receber os mocks (normalmente a classe em testes). A partir daí é só fazer o padrão em testes com mocks - ensinar os mocks a dar os retornos esperados em cada caso, executar a ação de teste e verificar os resultados.

Uma dica: DAO´s não são bons casos de testes unitários - eles somente encapsulam o acesso ao banco de dados. Se você chamar realmente o BD não é um teste unitário, já que está dependendo de entidades externas à classe em teste - e se você usar mocks, não vai estar testando nada de verdade - você vai ensinar o mock a retornar determinado resultado e testar se esse resultado foi encontrado - no fim das contas não te garante nada.

Se a intenção é testar o SQL sendo executado, melhor fazer testes de integração, acessando realmente o BD . Nesse caso, basta inserir no BD, dentro de uma transação, os dados do cenário em teste, executar a ação, verificar o resultado, e no fim, independentemente de sucesso ou erro, dar rollback na transação, para limpar o terreno para os próximos testes.

solução!

Obrigado pelos esclarecimentos Leonardo!

Quer mergulhar em tecnologia e aprendizagem?

Receba a newsletter que o nosso CEO escreve pessoalmente, com insights do mercado de trabalho, ciência e desenvolvimento de software