Testando com Mocks de forma fácil

Criação de testes unitários com Spring e EasyMock

GIULIANO MORAIS / CONSTANTINO CRONEMBERGER
Faça com que o trio EasyMock, Spring e JUnit ajude a criar testes unitários de forma
rápida e fácil.

Os testes unitários deixaram de ser novidade há um bom tempo, e hoje estão cada vez mais presentes
no dia-a-dia das empresas de desenvolvimento de software. Esse grande envolvimento e aceitação das
empresas com o teste unitário têm dois principais fatores: Qualidade de Software e JUnit.
Por que JUnit ? O JUnit foi a ferramenta que faltava para pôr em prática a realidade de construir
e executar testes unitários. Ficou fácil notar como as metodologias ágeis ganharam um grande impulso
e força após o JUnit tornar viáveis algumas das lições divulgadas por essas metodologias.
Vamos fazer um paralelo com outros setores da indústria onde os testes de qualidade já estão
presentes e postos em prática há muito tempo. Tomemos como exemplos uma fábrica de pneus.
Imagine você, se para cada pneu produzido nessa fábrica fosse necessário colocá-lo em um veículo
com motorista e fazê-lo rodar por alguns quilômetros simplesmente para testar o pneu? Seria exagero,
sem contar alguns desperdícios como um motorista disponível, combustível, o trabalho de colocar e
tirar cada pneu do carro, etc.
Foi nesse ponto que indústria de fabricação de pneus (entre outras) evoluiu e aprimorou os
testes de qualidade. Vejamos, a borracha que será usada na fabricação e vulcanização do pneu é
avaliada e deve estar dentro de um padrão de aceitação exigido pela indústria. O processo de
vulcanização é monitorado, e por fim as unidades produzidas são testadas e avaliadas nos quesitos de
elasticidade, torção, resistência, e na fase final o pneu é submetido a uma esteira onde percorre um
curto trecho em um ambiente muito similar a uma estrada ou avenida.
A disciplina da Engenharia de Software procura trazer os mesmos métodos “industriais” à
produção de software. O apelo das metodologias ágeis é disponibilizar ferramentas simples e
pragmáticas, focadas em obter excelentes níveis de qualidade.
Voltando ao paralelo, iremos falar nesse artigo sobre como construir e executar testes unitários
sem a necessidade de ter as partes colaboradoras sempre disponíveis. É como se estivéssemos falando,
no caso do pneu, de como testá-lo sem a colaboração do veículo.
Nossa intenção aqui não é abordar profundamente JUnit ou qualquer metodologia, pois iremos
nos focar na realização de testes através de objetos “de mentira”.

Exemplo: Banco Central

Usaremos como exemplo uma operação de transferência de valores entre contas de diferentes
instituições financeiras, onde queremos testar a lógica de transferência em si, e não a disponibilidade e
o acesso a essas instituições financeiras, as quais chamaremos a partir de agora de bancos.
Nosso código exemplo é um sistema de um banco que pode realizar operações de transferência
de valores entre uma conta nesse banco (conta local) e uma conta pertencente a outro banco, como uma
TED, por exemplo.
 Figura 1. Diagrama de Classes do projeto exemplo.

Veja o diagrama de classes apresentado na Figura 1. A interface Banco é ponto de partida dessa
transação de transferência, através do método transferenciaInterbancaria(), cuja assinatura
é:

void transferenciaInterbancaria (ContaLocal origem, Conta destino, BigDecimal valor)

A conta de origem, aqui representada pela classe ContaLocal, é uma conta totalmente acessível
pelo Banco onde está sendo iniciada esse transação; porém, a conta de destino, representada pela
classe Conta, pode pertencer a outro banco, fora do domínio do banco iniciador.
É nesse momento que o Banco pede uma ajuda para a interface BancoCentral para poder
realizar a transação com outra instituição. O BancoCentral tem a responsabilidade de contatar o
banco da conta de destino e solicitar o completamento da transação. Para não perder o foco, o método
transferir() do BancoCentral foi implementado de forma bem simplificada.
Agora que entendemos um pouco das principais classes desse sistema, vamos começar falando
do teste unitário testTransferenciaInterbancariaForItau() (veja Listagem 1).
Queremos simplesmente testar o método transferencia() na classe Banco, afinal estamos
falando de teste unitário e não de integração, porém o que vemos no código do
testTransferenciaInterbancariaForItau() é um grande esforço para preparar um contato
com o Banco Central (ou um servidor que tenha a mesma interface). É justamente isso que queremos
evitar, queremos testar o Banco e não o BancoCentral. Sem contar ainda que durante a execução
de nossos testes pode não haver garantia de que sempre teremos acesso ao Banco Central durante o
desenvolvimento e geração de builds diários.
Quando pensamos em utilizar o recurso real, percebemos que isso torna-se praticamente
impossível, afinal não teremos os servidores do Banco Central à nossa disposição durante o
desenvolvimento do projeto para as transações de teste.
Objetos “de mentira”
Chegou o momento de falarmos dos objetos “de mentira”. Queremos um objeto desse tipo para
o Banco Central, a fim de permitir que o nosso teste do Banco consiga ser realizado sem imaginar
que o que ele está usando de fato é um BancoCentral de “mentirinha”.
Tais objetos serão chamados a partir de agora de Mocks1.
Faremos uso da biblioteca EasyMock para auxiliar na geração de mocks.

Existem ainda alternativas ao EasyMock que poderiam ser usadas da mesma forma,
como o Mockito fornecido pelo Google. Veja o quadro “Outras opções para “Mockar””

Iremos agora reescrever o teste utilizando o EasyMock conforme a Listagem 2.

O import static da classe EasyMock torna disponíveis os seus métodos para serem
usados dentro do teste. Dessa forma o código fica um pouco mais simples e limpo, por exemplo,
poderemos usar a forma expect(...) ao invés de EasyMock.expect(...).
A linha 4 está fazendo com que um objeto “de mentira” do tipo BancoCentral seja criado.
Perceba ainda que o parâmetro do método createMock() é uma classe. O EasyMock, através do
recurso de Proxy dinâmico do Java consegue criar um objeto da classe especificada. É aqui que está
acontecendo a “mágica” da criação de um Banco Central “de mentira”.
Na linha 15, com os métodos expect() e andReturn(), estamos definindo o
comportamento esperado para o Mock. É como se estivéssemos ensinando o Mock a responder
determinada pergunta, melhor dizendo, estamos dizendo qual retorno esperamos quando um
determinado método for executado no Mock e quais os parâmetros são esperados.
Terminada a fase de aprendizado do Mock, na linha 17 vemos a execução do método
replay(bcMock). Esse é mais um método da classe EasyMock, que encerra a fase de definição
do comportamento do Mock, deixando-o “no ponto” para interagir de forma satisfatória nos testes.
Com esse código visto até aqui, estamos estabelecendo uma regra que quando o Mock for
acionado com os mesmos parâmetros definidos na linha do expect(), o mesmo retorno será sempre
respondido, nesse caso o valor booleano true.
O resto do nosso novo método de teste é praticamente igual à versão sem o EasyMock, exceto
pelo fato de nesse método o BancoCentral ser um objeto “de mentira”. Já na linha 20 estamos
passando uma referência desse Mock para um objeto Banco, que não está sabendo de nada, para ele
tudo está dentro da normalidade, afinal que ele precisa é de um objeto que implemente a interface
BancoCentral.
O teste unitário da classe Banco agora está pronto para ser executado sem termos que ficar nos
preocupando com classes acessórias e questões de infra-estrutura, pois trocamos tudo isso por um
objeto “me mentira” que após ser bem treinado, não irá comprometer a qualidade do nosso teste. Note
que não precisamos mais chamar os métodos connect() ou identify(), uma vez que não há mais
conexão real.

Até aqui usamos só um pouquinho da rica biblioteca do EasyMock. Muitos recursos são
oferecidos, como restrições, geração de comportamento para lançamento de exceções, etc. Como o
objetivo desse artigo não é cobrir profundamente a biblioteca, deixo aqui a dica para o leitor ler mais
sobre o assunto na própria documentação do EasyMock (veja Links) e na Edição 37.

Geração automática de testes

1
Em inglês, imitação, mas com um sentido pejorativo – um plágio obviamente fajuto, ridículo, sem pretensão de se passar
pela coisa real.
 Agora que conhecemos o teste unitário antes e depois, você pode estar imaginando: Por que não
fizemos o teste usando o EasyMock logo na primeira vez? Realmente isso seria mais fácil do que
passar pelas duas iterações que mostramos, porém na prática não é sempre que escrevemos os testes
unitários já pensando no conceito de Mock. Muitas vezes temos que dar manutenção em sistemas já
existentes e com testes já prontos, e podemos perceber que muito pouco desses testes são refeitos
usando Mocks, afinal, o custo para reescrever muitos testes pode ser alto. Além disso, são raros os
projetos onde há tempo e orçamento disponíveis para investir nessa reestruturação, sem contar a
complexidade que seria ter que avaliar e entender teste por teste para melhorá-los com Mocks quando
necessário.
Quando criamos os Mocks manualmente, existe sempre um trabalho minucioso a ser feito, é a
parte das chamadas do expect() e andReturn(), onde devem ser informados os valores
esperados de entrada e os valores de saída, que no exemplo da Listagem 2 então entre as linhas 6 e 15.
Nesse exemplo, para conseguirmos montar o código precisaríamos de alguma forma conhecer os
valores contidos nos objetos no momento da chamada do método transferir(), e isso geralmente
poderia ser obtido através de uma sessão de debug ou geração de logs. De qualquer forma, depois de
identificados os valores, ainda temos que escrever o código para a criação das chamadas e dos objetos
com os valores usados nas mesmas.
Com um pouco de conhecimento de Spring e de AOP conseguimos facilmente criar um
mecanismo capaz de capturar os valores usados nas chamadas ao se executar o teste unitário original, e
gerar uma nova versão do mesmo fazendo uso de Mocks.
A idéia é bastante simples, basta executar os testes originais existentes (sem mocks) para obter
os parâmetros e os retornos das chamadas de todos os objetos que serão transformados em Mocks. Com
essa informação basta gerar o código Java para a criação dos Mocks e das chamadas dos métodos
expect(), andReturn() e replay(). Estamos, portanto, substituindo o trabalho que teríamos
para identificação dos valores de entrada e saída dos testes existentes por uma forma automática de
captura. Não precisaremos mais de logs ou sessões de debug.

Acompanhando a idéia, a implementação é simples também.

São dois os principais aspectos:

• Interceptors do Spring para capturar os parâmetros e os valores de retorno;

• Geração das chamadas do EasyMock baseadas nos valores obtidos na interceptação;

No Spring, um interceptor é uma classe que implementa a interface MethodInterceptor

(Listagem 3) implementando o seu método invoke(). Veja o esqueleto do interceptor na Listagem
3. Este método recebe como parâmetro um objeto que contem informações sobre qual a
instância foi chamada (linha 8), método chamado (linha 10) e os parâmetros passados (linha 12).
Com estas informações já é possível fazer a declaração dos Mocks e seus parâmetros. Logo
após o método interceptado é chamado, conforme a linha 14, e o valor de retorno é capturado e usado
para complementar a chamada do método expect() (linha 17). Finalmente, todas as possíveis
exceções são capturadas para uma possível chamada do método andThrow() do EasyMock. Na
Listagem 4 é possível avaliar um exemplo de código gerado.
Deixamos o trabalho de criação dos VOs para o método generateArguments(),
conforme exibido na linha 12 da Listagem 5. É importante lembrar que os VOs utilizados devem
obrigatoriamente possuir os métodos getters e setters, pois a extração dos atributos de cada VO é feita
através da classe BeanUtils do Spring (dentro da classe DefaultReferenceGenerator).
Na Listagem 5 vemos claramente um tratamento específico para vários tipos de parâmetros,
desde os simples, que não precisam de declaração até os que devem ser declarados e populados
previamente. Podemos chamar de parâmetros simples os objetos do tipo String, e os wrappers para
tipos primitivos como Float, Integer, etc ou até mesmo objetos que podem ser construídos apenas
chamando o construtor já passando parâmetros para os atributos quando necessário, ou seja, sem
necessidade de usar setters. Esses objetos dão origem a parâmetros imediatos. A interface
ImmediateArgumentGenerator (linha 22), é usada para gerar o código de criação desse
último tipo de objeto. Um exemplo de classe que usa esse tipo de geração é a
java.math.BigDecimal pois podemos criar uma instância do mesmo com um simples construtor
do tipo new BigDecimal(“10.00”). Estes são exemplos de argumentos simples:
EasyMock.expect(classe.metodo(“Roberto Carlos”, new BigDecimal("10.50"))).andReturn(true);

É interessante notar que os objetos de retorno são tratados pelo gerador da mesma forma que os
parâmetros (linha 16 da Listagem 5).
Agora falaremos dos parâmetros não simples (que precisam ter variáveis declaradas e
populadas). Exemplos dessas classes são java.util.Date e classes de Collections. O método para
tratar esses casos é o prepareReference() (código disponível para download no site da revista).
Esse método inicialmente identifica se o parâmetro já não foi gerado antes, e em seguida, se for o caso,
gera a declaração de uma variável de nome único com a chamada do construtor correspondente. Como
nem todas as classes têm o construtor sem parâmetros, foi criada a interface
ConstructorGenerator utilizada para casos específicos, como o java.sql.Date por
exemplo que sempre espera um long como parâmetro. Finalmente chegou o momento de popular os
valores no objeto, e isso é possível com a ajuda da interface ReferenceGenerator, conforme
definição na Listagem 6.
O método handleClass() é usado para filtrar o tipo de classe que é tratada por essa
instância de ReferenceGenerator, enquanto o método prepareSetupData() retorna uma
lista de pares nome-objeto, que é a lista dos métodos a serem chamados para montar o parâmetro e os
respectivos valores passados para aqueles métodos. Por exemplo, no caso de uma lista, o método
chamado é sempre o add(). Já para um VO simples os métodos serão os vários setters. Para cada
nome de método é gerada uma chamada passando como parâmetro um objeto criado pelo método
generateArguments() já discutido anteriormente.
Um cuidado especial foi tomado para os casos em que existe circularidade ou quando um dado
elemento aparece mais de uma vez. Para isso usamos um mapa onde são armazenadas todas as
referências já processadas. Note pela Listagem 4, que primeiro são feitas todas as declarações, e
somente depois todos os campos são populados, evitando assim problemas caso haja alguma
interdependência ou circularidade entre os VOs.
Para fazer a geração das chamadas ao objeto que será testado além da preparação dos Mocks, é
ainda necessário interceptar as chamadas a este objeto (linha 26 da Listagem 2). Aproveitando que já
foi criado um interceptor para os Mocks, optamos por usar o mesmo interceptor também para este outro
fim. A diferença se dá no fato de que a primeira chamada interceptada é considerada como sendo a
chamada da classe que está sendo testada, portanto não é gerado código para a criação de Mock e sim
uma nova instância da própria classe de implementação (linha 19 da listagem 2). Foram criados
também os métodos startMethod() e finishMethod(), que podem ser usados para separar o
código gerado em métodos, fazendo com que novas declarações de Mocks sejam criadas para cada
método. Esses métodos devem ser chamados no começo e no fim de cada método do teste original (ver
BancoImplTest.java no código fornecido com o artigo para mais detalhes).
Com todas as classes prontas para a geração dos novos testes, basta agora configurar o Spring
para interceptar as chamadas. No exemplo desse artigo temos o XML da Listagem 7, fazendo com que
os beans bancoCentral e banco sejam interceptados (linhas 19 e 20).
Perceba que o bean sistemaLocal não será interceptado (linha 12) uma vez que faz parte do
próprio sistema, portanto não terá um Mock gerado. Analisando o código entre as linhas 31 e 50, há a
configuração do gerador, onde podemos notar as várias classes mencionadas no decorrer do artigo
(immediateArgumentHandlers, constructorHandlers e referenceHandlers).
É através dessas configurações do gerador que podemos adicionar tratamento específico para qualquer
classe que não tenha sido tratada originalmente neste artigo, o que torna o gerador bastante flexível e
fácil de estender.
Obviamente o gerador não resolve todos os problemas. No final do processo, quando o código
criado pelo gerador está disponível, ainda pode ser necessário adequar as validações que são feitas nos
testes originais para funcionar com os Mocks. Isso ocorre porque o Interceptor não intercepta as
chamadas para os métodos de assert do JUnit e outras classes que possam ser usadas nos casos de teste.
Por exemplo, existem casos onde os testes validam se houve alguma mudança no banco de dados. Com
o uso de Mocks não há como fazer essa verificação porque o banco de dados nem está sendo usado.
Para o caso específico de testes envolvendo DAOs, pode-se simplesmente remover essas validações,
uma vez que quando os mocks forem gerados, será gerado um expect() para o método do DAO que
seria o responsável por atualizar o banco de dados; assim, a validação fica por conta do próprio
EasyMock.
Além da necessidade de acertar as validações também é necessário completar a classe uma vez
que o gerador gera apenas os métodos, fazer os imports e fazer a injeção dos mocks gerados na classe
de implementação sendo testada, como na linha 20 da listagem 2.

Além da geração de testes a partir da execução de testes já existentes, também é possível gerar
testes a partir da execução de código em qualquer outra situação, bastando para isso configurar a
interceptação das chamadas. Um bom exemplo prático seria o caso de ser encontrado um bug no
sistema durante os testes manuais no ambiente de homologação, bastando configurar o gerador para
capturar as chamadas durante esse teste, e automaticamente teremos gerado código com Mocks para
reproduzir exatamente o que aconteceu durante o teste onde surgiu o bug. Dessa forma, agora fica mais
fácil corrigir o bug na própria máquina do desenvolvedor sem a necessidade de fazer debug remoto ou
ter acesso direto ao ambiente de homologação.

Conclusões
A popularização do JUnit e das metodologias ágeis estão fazendo com que os desenvolvedores
invistam cada vez mais parte do seu tempo na criação e manutenção de testes unitários.
A proposta desse artigo não foi entrar em detalhes do JUnit, e nem mesmo do EasyMock. O
nosso grande objetivo aqui foi apresentar ao leitor, mais uma vez, que juntando as peças disponíveis
(JUnit e EasyMock) com uma pitada de criatividade e principalmente necessidade, conseguimos
escrever com pouca quantidade de código um gerador de testes unitários que se apóia na utilização de
objetos “de mentira”. Assim, concentramos o teste no que realmente deve ser testado, sem perder o
foco com objetos acessórios e de infra-estrutura como foi apresentado no exemplo.
Quando colocamos todos essas partes para trabalharem juntas, temos à nossa disposição uma
ferramenta de grande valor que se encaixa facilmente em projetos antigos e novos, sendo aplicada
dentro de metodologias ágeis as quais sempre priorizam a qualidade de software, utilizando testes
unitários como ferramenta central.
Utilizamos o EasyMock por ser um projeto que se torna cada vez mais popular além de ter um
solução bem interessante e de fácil implementação.
Esperamos que esse artigo sirva de exemplo para você criar cada vez mais testes no seu projeto
e, quando valer a pena, refatorar testes já existentes usando o gerador aqui proposto. Uma ferramenta
comercial que também pode ajudar a criar testes é o Jtest da Parasoft, em especial com o pacote
opcional do Jtest Tracer que faz algo similar ao gerador aqui apresentado (veja Links).

Listagem 1. Teste unitário que utiliza o Banco Central

1 public void testTransferenciaInterbancariaForItau() {

 2 BancoCentral bc = new BancoCentralImpl();
3 try {
4 bc.connect();
5 String autorizacao = bc.identify("id:Itau");
6 } catch (ConexaoFalhouException cfe) {
7 // tratamento da excecao aqui
8 }
9
10 Banco banco = new BancoImpl("Itau", "341");
11 banco.setInstituicaoReguladora(bc);
12
13 ContaLocal origem = new ContaLocal("1234", "4321");
14 Conta destino = new Conta("256", "5234", "98765");
15 BigDecimal valor = new BigDecimal("10.50").setScale(2);
16
17 assertTrue(banco.transferenciaInterbancaria(origem, destino, valor));
18 }

Listagem 2. Teste unitário utilizando o EasyMock

0 import static org.easymock.EasyMock.*;
1 @Test
2 public void testTransferenciaInterbancariaForItau() throws Exception {
3
4 BancoCentral bcMock = createMock(BancoCentralImpl.class);
5
6 Conta conta = new Conta();
7 Conta conta2 = new Conta();
8 conta2.setAgencia("5234");
9 conta2.setBanco("256");
10 conta2.setConta("98765");
11 conta.setAgencia("1234");
12 conta.setBanco("123");
13 conta.setConta("4321");
14
15 expect(bcMock.transferir(conta, conta2, new BigDecimal("10.50"))).andReturn(true);
16
17 replay(bcMock);
18
19 Banco banco = new BancoImpl("Itau", "341");
20 banco.setInstituicaoReguladora(bcMock); // estamos passando o objeto falso para o Banco
21
22 ContaLocal origem = new ContaLocal("1234", "4321");
23 Conta destino = new Conta("256", "5234", "98765");
24 BigDecimal valor = new BigDecimal("10.50").setScale(2);
25
26 assertTrue(banco.transferenciaInterbancaria(origem, destino, valor));
27 verify(bcMock);
28 }

Listagem 3. Esqueleto do Interceptor

1 public class EasyMockBuilderInterceptor implements MethodInterceptor,
EasyMockBuilderInterceptorMBean {
2 ...
3 public Object invoke(MethodInvocation invocation) throws Throwable {
4
5 String beanName = getBaseName(invocation.getThis());
6
7 String declaringClass = invocation.getMethod().getDeclaringClass().getName();
8 String objClassName = invocation.getThis().getClass().getName();
9 ...
10 boolean voidReturnType = invocation.getMethod().getReturnType() == void.class;
11 ...
12 String arguments = generateArguments(invocation.getArguments(),declaracoes,referencias);
13 ...
14 Object obj = invocation.proceed();
15 ...
16 String returnObject = generateArguments(new Object[] {obj},declaracoes,referencias);
17 chamadaStr.append(".andReturn(" + returnObject +");");
18 ...
19 } catch (Throwable ex) {
20 ...
21 }
22 }
23 }

Listagem 4. Exemplo de código gerado

1 gov.bcb.Conta conta = new gov.bcb.Conta();
2 gov.bcb.Conta conta2 = new gov.bcb.Conta();
3 conta2.setAgencia("5234");
4 conta2.setBanco("256");
5 conta2.setConta("98765");
6 conta.setAgencia("1234");
7 conta.setBanco("123");
8 conta.setConta("4321");
9
10 EasyMock.expect(bancoCentralImpl.transferir(conta, conta2, new
BigDecimal("10.50"))).andReturn(true);

Listagem 5. Método generateArguments

1 private String generateArguments(Object[] arguments, Map<String,String[]> declaracoes,
Map<Object,String> referencias) {
2 StringBuilder sb = new StringBuilder();
3
4 if (arguments != null) {
5 for (Object obj: arguments) {
6 if (obj == null) {
7 sb.append("null,");
8 } else if (obj instanceof String) {
9 String str = (String)obj;
10 str = prepareString(str);
11 sb.append('"').append(str).append("\",");
12 } else if (ClassUtils.isPrimitiveWrapper(obj.getClass())) {
13 if (obj instanceof Long) {
14 sb.append(obj).append("L,");
15 } else if (obj instanceof Float) {
16 sb.append(obj).append("F,");
17 } else {
18 sb.append(obj).append(",");
19 }
20 } else {
21 boolean processado = false;
22 for (ImmediateArgumentGenerator iag: immediateArgumentHandlers) {
23 if (iag.handleClass(obj)) {
24 processado = true;
25 sb.append(iag.generateArgument(obj)).append(',');
26 }
27 }
28
29 if (!processado) {
30 String nome = prepareReference(declaracoes,obj,referencias);
31 sb.append(nome).append(",");
32 }
33 }
34 }
35 }
36
37 // remove a última virgula se houver alguma
38 if (sb.length() > 0) {
39 sb.setLength(sb.length()-1);
40 }
41
42 return sb.toString();
43 }

Listagem 6. Interface ReferenceGenerator

public interface ReferenceGenerator {

public boolean handleClass(Object obj);

/**
 * @param obj objeto de onde sairá os valores usados para a gera
* @return retorna uma lista de Srtings para a inicialização do objeto
* já declarado anteriormente.
*/
public List<NameObjectEntry> prepareSetupData(Object obj);
}

Listagem 7. Configuração do Spring: applicationContext.xml

1 <beans>
2 <!-- A classe a ser testada, ou classe de entrada, deve ser interceptada.
3 O interceptador trata de forma diferenciada a primeira chamada. -->
4 <bean id="banco" class="com.negocio.BancoImpl">
5 <property name="bcb" ref="bancoCentral"/>
6 <property name="local" ref="sistemaLocal"/>
7 </bean>
8
9 <bean id="bancoCentral" class="gov.bcb.BancoCentralImpl"/>
10
11 <!-- SistemaLocal não terá mocks gerados pois faz parte do próprio sistema -->
12 <bean id="sistemaLocal" class="com.negocio.SistemaLocalImpl">
13 <property name="codigoBanco" value="123"/>
14 </bean>
15
16 <bean class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator">
17 <property name="beanNames">
18 <list>
19 <value>bancoCentral</value>
20 <value>banco</value>
21 </list>
22 </property>
23 <property name="interceptorNames">
24 <list>
25 <value>easyMockInterceptor</value>
26 </list>
27 </property>
28 </bean>
29
30
31 <bean id="easyMockInterceptor" class="org.generator.EasyMockBuilderInterceptor">
32 <property name="immediateArgumentHandlers">
33 <list>
34 <bean class="org.generator.BigDecimalGenerator"/>
35 </list>
36 </property>
37 <property name="constructorHandlers">
38 <list>
39 <bean class="org.generator.DateConstructorGenerator"/>
40 </list>
41 </property>
42 <property name="referenceHandlers">
43 <list>
44 <bean class="org.generator.DateReferenceGenerator"/>
45 <bean class="org.generator.CollectionReferenceGenerator"/>
46 </list>
47 </property>
48 </bean>
49 </beans>

Outras opções para “Mockar”

code.google.com/p/mockito
Biblioteca de mocks similar ao EasyMock, mais simples e intuitiva.
jmock.org
Outra biblioteca para criação de mocks em Java.

mocklib.sourceforge.net
Biblioteca de mocks com previsão de suporte para outras linguagens.

code.google.com/p/turtlemock
Outra biblioteca do Google que promete facilitar os testes.

Links
easymock.org
Site do EasyMock, de onde se pode fazer o download e acessar a documentação.

parasoft.com/jsp/products/home.jsp?product=Jtest
Ferramenta comercial para geração automática de testes.