Facilitando testes de unidade no Java com Mockito

Mesmo sem conhecer Mocks, lanço um desafio. Continue lendo o artigo e ao final sentirá quanto absorveu do conteúdo. Certamente terá dificuldades. Faça o bookmark do post, volte aos seus estudos, pratique e retorne depois. Ao reler o texto, perceberá o quanto evoluiu, resultado direto de seus estudos.

Então vamos ao código. Temos uma classe FuncionarioDAO e um método buscarFuncionario. No nosso exemplo, para buscar o Funcionario, o sistema deve se comunicar com um mainframe por meio de uma interface Transacao. Mas perceba aqui que poderia ser uma interface EJB comunicando-se remotamente ou até mesmo uma transação simples JDBC. Essa transação mainframe retorna uma String contendo as informações do usuário, separada por colunas. Então o que devemos fazer é uma lógica para montar um Funcionario a partir dessa resposta. Começando pelos testes, teríamos o seguinte:

O grande problema é a interface Transacao. Como estamos testando a unidade, não queremos que um objeto real se comunique com o mainframe: seria lento e difícil de testar o resultado, além de testar mais de uma unidade. Esse assunto já foi bastante discutido em artigos do blog da Caelum que falam de testes, sua influência no design, no acoplamento e na velocidade do seu projeto. Perceba o uso da annotation @Mock, ela facilita a criação de mocks, deixando o código mais limpo.

A primeira linha do primeiro teste (when(transacao.executar("12345")).thenReturn(" ... "))define como queremos que o mock se comporte durante a chamada do método executar. O Mockito leva uma grande vantagem aqui sobre os outros frameworks por ser extremamente refactoring friendly. Para isso, usamos o método when. Já na primeira linha do segundo teste podemos emular um erro através do thenThrow, ou seja, caso não haja nenhum funcionario, o método deverá lançar uma exceção. Com isso isolamos o teste apenas à unidade em questão, sem que código de outras unidades sejam executados.

Podemos ainda verificar se durante a execução de buscarFuncionario o método do nosso mock foi acionado. Para isso usamos o método verify. O segundo argumento pode receber alguns outros métodos do Mockito como never, atMostOnce, alLeastOnce, times().

Há algumas pessoas que acham desnecessário verificar se o método do objeto mocado foi realmente invocado. Inclusive a própria documentação do mockito comenta a respeito. Porém o uso do verify evita que alguém retire essa linha do seu código, algo bem difícil de acontecer, mas por experiência própria, podemos esquecer algum assert.

Feito os testes, partimos então para a lógica.

Agora, ao rodar os testes, você obterá a green bar!.

Vamos imaginar um cenário que você esteja lidando com um sistema com design mais pobre, com muito uso de métodos estáticos, e seu design ficasse assim:

Há algumas formas de testar esse código, ou seja, mocar o comportamento estático. A primeira é manipulação de bytecode (finamente explicado pelo meu amigo André Breves). Entretanto, não me arriscaria a fazer isso na mão, já existem frameworks para tal finalidade e um deles é o PowerMock, que se integra facilmente com Mockito e JUnit. É muito útil principalmente quando o framework que você está usando lhe impõe invocações estáticas a ele. Exemplificando, mesmo tendo D.I, inevitavelmente, uma hora ou outra utilizando o Seam 2.2, você invocará Component.getInstance().

Mas é sempre bom lembrar que fazer um design mais orientado a interfaces e desacoplado de implementações concretas lhe dará uma maior flexibilidade tanto na programação do sistema quanto na construção de testes. A discussão sobre utilização de métodos estáticos já está batida na comunidade, vários argumentos, dentre eles a programação mais estruturada e menos O.O.

A segunda seria encapsular o TransacaoServiceLocator em uma outra classe e mockar essa classe, sem ter de fazer malabarismos.

A terceira forma seria extrair a chamada para um método e na classe FuncionarioDAOTest, na criação de FuncionarioDAO, poderíamos criar uma classe anônima e fazer o override do método buscarTransacao, retornando um mock.

Mas tudo isso é muito complicado, como o mockito te ajuda? Aí vêm os Spy Objects, a próposito, brilhantemente explicado aqui. Em suma, Spy Objects são objetos reais até que se prove o contrário. E provamos o contrário quando definimos algum comportamento para ele. Exemplificando:

Agora definimos que todos os métodos de FuncionarioDAO serão invocados normalmente, com exceção do método buscarTransacao, que teve o comportamento alterado. É importante reparar que eu usei doReturn ao invés do when.

Concluindo, o importante mesmo é saber lidar com as várias ferramentas que existem, tirando o maior proveito delas para construção de testes. Por exemplo, o meu framework não faz injeção de dependências por construtores, então já que eu não tenho construtores para receber os atributos, nos meus testes eu faço a injeção usando o Mirror, uma DSL que ajuda na manipulação da API reflection. Hoje mesmo já fui apresentando a uma outra ferramenta, fixture-factory. Indubitavelmente, conhecer o poder que cada ferramenta pode lhe oferecer e principalmente saber quando as utilizar são duas importantes tarefas de um arquiteto de software.

E quais ferramentas você utiliza para fazer os seus testes?

Créditos especiais ao companheiro de trabalho Taciano Tres,que me ajudou com ótimas referências e sempre me obriga a estar atualizado!