Escolar Documentos
Profissional Documentos
Cultura Documentos
O termo "Mock Objects" é utilizado para descrever um caso especial de objetos que imitam objetos reais para teste.
Esses Mock Objects atualmente podem ser criados através de frameworks que facilitam bastante a sua criação.
Praticamente todas as principais linguagens possuem frameworks disponíveis para a criação de Mock Objects.
Um mock pode ser bem inteligente. É possível "ensinar" o mock a reagir da maneira que queremos quando um
método for invocado, descobrir a quantidade de vezes que o método foi invocado e assim por diante.
Em um sistema de loja varejista um nota fiscal deve ser gerada para cada pedido efetuado. O valor da nota fiscal é
de 6% sobre o total do pedido. Para cada nota fiscal gerada pelo sistema deve salvar e enviar por email do cliente
uma cópia da nota.
Poderíamos criar um teste unitário para classe GeradorDeNotaFiscal, verificando se o objeto NotaFiscal possui os
valores esperados.
Entretanto, como verificar o comportamento interno do método? Como verificar se a nota foi salva e enviada por
email?
O comportamento do método gerar, depende do comportamento do método salvar e enviar das classes
NotaFiscalDAO e EnvioEmail respectivamente.
Neste cenário, a utilização de objetos Mocks possibilitam a checagem do comportamento interno de uma classe ou
método.
Vamos criar dois objetos Mocks, um para a classe NotaFiscalDAO e outro para EnvioEmail. Desta forma, saberemos
se os métodos salvar e enviar foram de fato executados dentro do fluxo do método gerar.
2. Adicione a biblioteca (.jar) do Mockito no projeto, também disponível na pasta da matéria no ftp.
Estrutura do Projeto
3. Cria uma classe de Teste JUnit no Projeto chamada GeradorDeNotaFiscalTeste e Implemente como o
exemplo abaixo:
Ao executar esta classe o teste não irá passar. Isto porque os objetos mocks nfDAO e email, não foram passados para
o método gerar, que continuou a utilizar suas instancias internas.
6. Considerações
Repare que por uma necessidade do teste, optamos por receber as dependências da classe pelo construtor. Isso é,
na verdade, uma boa prática quando se pensa em orientação a objetos.
Em primeiro lugar o desenvolvedor deixa as dependências da classe explícitas. Basta olhar seu construtor, e ver quais
classes são necessárias para que ela faça seu trabalho por completo. Em segundo lugar, ao receber a dependência
pelo construtor, a classe facilita sua extensão. Por meio de polimorfismo, o desenvolvedor pode, a qualquer
momento, optar por passar alguma classe filha da classe que é recebida (ou, no caso de uma interface, outra classe
a implementa), mudando/evoluindo seu comportamento.