Olá Pessoal,
Hoje vou apresentar o Mockito que é uma API de Mock, que tem ganhando espaço a cada dia. No post, vou falar pra que serve aos Mocks, o que evitamos e farei “reutilização da informação” sobre o que são mocks. E para deixar tudo claro nada melhor que um exemplo feijão com arroz, para que você possa entender como usar. No próximo post veremos na pratica a criação de Mocks com Mockito.
Lets go…
Pra que serve o mockito?
Mockito é uma API desenvolvida pela Google, com o objetivo de simular um objeto real para uma classe especifica. Isso pode ajudar nos testes de unidade quando precisamos verificar a comunicação entre os objetos.
Por que usar Mock?
Usamos Mock quando temos classes que possuem dependencias, porém queremos testar apenas se uma classe está retornando o que estamos esperando.
E o que evitamos usando mock?
Evitamos de ter que criar objetos para todas as dependencias de uma classe. Ou seja, com o mockito vamos “enganar” a execução do programa, dizendo pra ele que o objeto a ser passado é de fato o objeto que ele espera.
Na pratica
Antes de apresentar os códigos, vamos precisar pegar o conceito do “negócio” e saber como os códigos trabalham.
O cenário é o seguinte:
- Class Cliente : um cliente ele possui alguns atributos como id, nome.
- Classe CarroAlugado: esta classe tem como objetivo de informar/representar qual carro está alugado e para quem está alugado (cliente). Então aqui já podemos ver que essa classe depende de um objeto da classe Cliente. Pois, um objeto da classe cliente que terá essas informações.
- Interface AlugarCarro: temos uma interface que aluga carro, como o procedimento de alugar carro é sempre o mesmo, de ter o nome de quem está alugando + o carro que foi alugado. Então se um cliente quiser alugar um carro terá que assinar um contrato com essa interface e informar pra ela o nome dele e o carro que deseja alugar.
E onde Mocks entram nessa história?
Mocs vão entrar no momento que vamos simular que um cliente c “Zezinhi” alugou um carro “Ferrari” e vamos ver se de fato a classe tem essa reserva feita.
Os códigos a seguir:
public interface AlugaCarro {
public void setNomeCliente(String nomeCliente);
public void setModeloCarro(String nomeCarro);
public String getNomeCliente();
public String getModeloCarro();
}
Classe Cliente implementando a Interface, pois um cliente está querendo alugar um carro.
public class Cliente implements AlugaCarro {
private String nomeCliente;
private String modeloCarro;
@Override
public void setNomeCliente(String nomeCliente) {
this.nomeCliente = nomeCliente;
}
@Override
public void setModeloCarro(String nomeCarro) {
modeloCarro = nomeCarro;
}
@Override
public String getNomeCliente() {
// TODO Auto-generated method stub
return nomeCliente;
}
@Override
public String getModeloCarro() {
// TODO Auto-generated method stub
return modeloCarro;
}
}
A classe CarroAlugado quer receber um objeto que foi instanciado contendo nome do cliente e o nome do carro alugado, e retornar esse objeto. Que nada mais é o Cliente que alugou o carro. Lembre-se o Cliente implements AlugaCarro, então temos o relacionamento HAS-A.
public class CarroAlugado {
private AlugaCarro alugaCarro;
public CarroAlugado(AlugaCarro alugaCarro) {
this.alugaCarro = alugaCarro;
}
public AlugaCarro getAlugaCarro() {
return alugaCarro; }
public void setAlugaCarro(AlugaCarro alugaCarro) {
this.alugaCarro = alugaCarro;
}
}
Na edição 49 da revista MundoJ tem um artigo que escrevi junto com o Alexandre Gazola sobre o assunto. E lá detalhamos mais, eu sou suspeito de recomendar essa edição :).
vou ficando por aqui, espero que tenham gostado do post.
abracos, see ya!!