Convivendo e melhorando seu relacionamento com código legado utilizando PowerMock

Transcrição

1 Marcio Garcia Mangar bacharel em Ciência da Computação. Trabalha com Java desde Já trabalhou em empresas de pequeno e grande porte bem como startups no Brasil e Austrália desenvolvendo, migrando e integrando sistemas em Java e Ruby on Rails. Possui certificações SCJP, SCWCD, SCBCD, SCEA I e CSM. Atualmente é consultor independente, e mantém seus dois blogs: mangar.com.br e Convivendo e melhorando seu relacionamento com código legado utilizando PowerMock Neste artigo, vamos mostrar algumas técnicas para um convívio pacífico entre as gerações de código e ainda mostrar uma ferramenta utilizada para testar código até então intestável, a fim de proteger as funcionalidades já implementadas e readequar o código legado em um mais moderno e bem desenhado. á 15 anos surgia uma das mais populares e revolucionárias linguagens de programação. Por todo este tempo muitas aplicações foram construídas utilizando as mais diversas técnicas e bibliotecas. TDD surgiu juntamente com XP em meados de Ou seja, primeiro nos preocupamos em desenvolver, depois em desenvolver corretamente. Nada mais natural. No entanto, 15 anos depois ainda temos que conviver e muitas vezes integrar nossas aplicações com código legado dos anos 90. Neste artigo apresentaremos soluções de como integrar código legado e ainda assim fazer bom uso de técnicas de teste, como TDD. Também mostraremos como utilizar a ferramenta PowerMock que fará praticamente todo o trabalho sujo de testar o código legadointestável e nossos exemplos. Como consumidores, garantia é algo que todos exigimos. Imagine se fosse possível comprar um automóvel novo, e no contrato ti- fabricante cairia em descrédito, você não levaria o carro para casa e ainda faria propaganda negativa a respeito do fabricante. Transporte este exemplo para o mundo de desenvolvimento de software. Um empregador em plena consciência contrataria algum fornecedor de serviços em que no contrato constasse: Software sem garantia? Garantia de um produto não está restrito em apenas um aspecto. Mas em se tratando de desenvolvimento de software um dos pilares para se alcançar um software de qualidade é um código limpo e testado. Mas para se alcançar tal cenário, com código limpo e testado alguns percalços devem ser transpostos. O primeiro é a escrita de um código testável. Se um código é escrito sem a preocupação com a implementação de testes, este será um código muito difícil de ser garantido. Códigos intestáveis são frequentemente encontrados em sistemas 48

2 legados, desenvolvidos a alguns anos atrás sem ao menos ter testes unitários implementados, que hoje como desenvolvedores nos vimos em situação de pânico quando é necessária uma manutenção em algum ponto realmente crítico do software. Neste artigo apresentaremos técnicas e ferramentas para aprimorar o código legado com segurança, implementando testes unitários neste código antes de fazermos o refactoring para uma versão legível e testável do código legado. refactoring das funcionalidades, tenhamos conhecimento do comportamento prévio bem definido e testado de tal classe ou método. Na figura 1 é mostrada a mecânica a ser seguida no refactoring de um código legado. Legibilidade de Código Código testável é algo que deveria estar na linha de frente do backlog técnico de qualquer projeto de desenvolvimento de software. E não apenas na forma de percentual de cobertura do código, mas também na forma de legibilidade de código. Um código ilegível, sem qualquer dúvida, te levará a além de uma equipe desmotivada com performance sofrível também a um código intestável. E esta combinação altamente explosiva contribuirá muito para problemas inesperados no projeto, em especial a não-geração do valor esperado para o cliente. Figura 1. Mecânica do refactoring. Pontos de atenção Algumas práticas conduzem a um código não muito expressivo e ilegível e com isso um código de difícil implementação de testes e algumas vezes até mesmo intestável: construtor. Estes são alguns exemplos de más práticas que devem ser evitadas no desenvolvimento de qualquer aplicação. Se trechos de código utilizando algumas das práticas citadas existem no seu projeto, a primeira ação é substituí-las por convenções de código mais legíveis. No entanto, algumas vezes, por motivações diversas, como compra de uma determinada biblioteca ou utilização de uma biblioteca de código cujo o código-fonte não esteja mais disponível, será necessário o convívio com tais códigos. Uma boa iniciativa é reduzir a disseminação deste código dentro do seu projeto. A criação de pontos de integração (seams, em inglês) reduz significativamente a dependência de tais códigos. Mecânica do Refactoring Lembre-se: estamos lidando com um código legado, no qual podemos encontrar implementações bizarras, como classes extremamente longas, com algo em torno de 200 linhas, com vários níveis de abstração entre os métodos. Como um bom desenvolvedor você deve deixar a classe melhor mais legível, testável etc. do que quando você a pegou. Para conseguirmos tal feito sem que nenhuma funcionalidade deixe de funcionar corretamente, é essencial que antes de fazermos o PowerMock PowerMock é um complemento aos frameworks que geram o Mockito. Com ambos a integração é bastante natural. Não há necessidade de nenhum tipo de adaptação para a integração. O framework é distribuído sobre a licença Apache License 2.0. O código-fonte está disponível no Google Code em: google.com/p/powermock/. Os principais mantenedores são Jan Kronquist e Johan Haleby que trabalham na empresa sueca Jayway. A motivação para a utilização do framework é resolver problemas relacionados à testabilidade de código legado ou de terceiros. Códigos difíceis de testar ou mesmo impossíveis passam a ter suas chances utilizando o PowerMock. utilizando EasyMock e Mockito. Neste artigo, abordaremos a utilização integrada entre PowerMock e Mockito. Funcionamento do framework O PowerMock é um framework que estende outras bibliotecas, como Mockito e EasyMock, incluindo funcionalidades mais avançadas, tais como: Para tais feitos, o framework faz uso extensivo de manipulação de bytecode através de um classloader próprio. Para a manipulação de bytecode, ele faz uso da biblioteca Javassist ( org/javassist). 49

3 Mesmo utilizando um classloader próprio, o framework é pouco intrusivo e de fácil utilização. Se você possui conhecimentos básicos de EasyMock ou Mockito, à primeira vista, terá a impressão de que está utilizando apenas um framework. Integração com JUnit Neste artigo utilizaremos JUnit para os testes de unidade juntamente com Mockito e o PowerMock para a criação dos mock objects. A integração com JUnit é muito simples, basta incluir duas anotações em seu código de é uma anotação do JUnit. Esta define qual será o Runner a ser executado pelo JUnit, por padrão, quando não informado nenhum é utilizado o próprio Runner da versão do JUnit que você está utilizando (configurada no pom.xml). Em nossa implementação de testes utilizando o PowerMock será necessário redefinir o Runner, para que seja utilizado o runner do Mockito com JUnit, definido pela classe é uma anotação que faz parte do PowerMock. Esta informa ao classloader do framework quais serão as classes que possivelmente sofrerão manipulação de bytecode. Como parâmetro, esta anotação recebe uma classe ou um array de classes. Agora que já estamos acertados quanto ao fluxo que iremos utilizar na readequação do código legado (figura 1) e no ferramental que iremos utilizar na tarefa de implementação dos testes vamos percorrer os problemas que facilmente serão encontrados em código legado. O primeiro exemplo será a implementação de testes em código utilizando Service Locator com Singleton e Inicialização Estática de Objetos Service Locator e Singleton Nos tempos em que não se falava em Injeção de Dependência, os Service Locators eram a grande onda. Utilizar este Design Pattern era sinal de que sua aplicação fazia uso da mais avançada e excepcional tecnologia em que poderia se ter contato no mundo Java: EJB 2.X. As mais avançadas implementações deste Pattern sugeririam inclusive a instanciação única e cache dos recursos adquiridos. Isso quer dizer, o Service Locator era um Singleton e um controlador de Cache, infringia duas vezes o princípio da Responsabilidade Iremos testar três pontos em um cliente que fará uso do nosso ServiceLocator: Na Listagem 1 você encontrará um trecho do nosso Cliente (SL- Client.java) e na Listagem 2 um trecho do ServiceLocator, nada que possamos nos orgulhar de ter implementado, mas ainda assim um ServiceLocator válido. Listagem 1. Cliente do ServiceLocator: SLClient.java. public class SLClient { private static String JNDI_LOCATION = not loaded ; static { JndiLocationsLoader loader = new JndiLocationsLoader(); SLClient.JNDI_LOCATION = loader.getfirstjndilocation(); public void executearemotemethod() { ServicoDeExclusao servico = (ServicoDeExclusao) ServiceLocator.getInstance(SLClient.JNDI_LOCATION).lookup( ServicoDeExclusao.class); servico.delete( some object to be excluded ); Listagem 2. ServiceLocator public class ServiceLocator { private String jndi; private static ServiceLocator instance; private ServiceLocator() { public static ServiceLocator getinstance(string jndi) { if (ServiceLocator.instance == null) { ServiceLocator.instance = new ServiceLocator(); instance.jndi = jndi; return ServiceLocator.instance; public Object lookup(class<?> classname) { System.out.println( Locate Class: + classname.getname() + jndi); return null; Inicializamos nossa classe de teste com as duas anotações já comentadas Respectivamente informando que vamos utilizar o Runner do PowerMock e a classe a ser manipulada será a ServiceLocator.class. A Listagem 3 mostra esta inicialização. Mais adiante temos as declarações e as inicializações dos mock-objects utilizando a do próprio Mockito (org.mockito.mock). Utilizando esta anotação torna-se desnecessário a inicialização dos objetos mock, por exemplo, dentro do método public void setup() { PowerMockito.mockStatic(ServiceLocator.class); setup: neste ponto começam as alterações específicas para o PowerMock. 50

4 Na primeira linha nada de novo, estamos apenas orientando um objeto do tipo ServiceLocator a quando chamado o método lookup com qualquer que seja o parâmetro, este deverá retornar outro objeto recém-mocado chamado servicodeexclusao. Adiante, utilizando o PowerMock, informamos que a classe Ser- setup, voltamos a utilizar o Mockito para definir o resultado da chamada ao método getinstance, que é um método estático da classe ServiceLocator. Um ponto interessante a ser notado é que a variável servicodeexclusao não é uma variável de instância e muito menos injetada na classe cliente. Esta é carregada no escopo do método através de uma chamada a um método estático do ServiceLocator. Para testar o método executearemotemethod seria necessário simular todo o comportamento dos métodos: getinstance e lookup da classe ServiceLocator. Certamente seria muito trabalhoso. Outra má prática duplamente e propositalmente implementada neste exemplo é a utilização de métodos void. Tendo como foco a testabilidade, uma implementação como esta é inviável de ser testada sem nenhuma readequação. Uma funcionalidade já manjada é a utilização dos métodos verify() para este propósito, já que não é possível verificar através de Asserts o retorno dos métodos ao menos conseguiremos verificar se a chamada ao serviço em nosso caso o método delete() foi feita. Listagem 4. Saída produzida pela execução da classe de teste: SLClient_Test Execução da Inicialização Estática de SLClient. Constructor de Base Client Chamada a um WS informando que algum cliente está ativo.. mj.teste. servicelocator.client.slclient Construtor de StClient Chamada a um WS informando que o cliente Cliente está ativo.. mj.teste. servicelocator.client.slclient execução de executedeletemethod Construtores A classe SLClient é subclasse de BaseClient, que por sua vez ao ser instanciada efetua uma chamada fictícia a um WebService solicitando o registro da mesma. Mais detalhes podem ser vistos no código-fonte completo. Este é apenas um exemplo de tarefas complexas e dependentes de recursos externos como conexão com a web, que podem estar definidos dentro do construtor. Algumas vezes é interessante quando não essencial suprimir algum construtor para que você possa prosseguir com os testes da classe. Para suprimir um construtor com PowerMock basta seguir os passos: 1) inclua a classe na e 2) Suprima o construtor. A Listagem 5 mostra como suprimir o construtor padrão da classe SLClient. Listagem 3. Teste do public class SLClient_Test ServicoDeExclusao ServiceLocator public void setup() { when(servicelocator.lookup((class<?>)any())).thenreturn(servicodeexclusao); PowerMockito.mockStatic(ServiceLocator.class); when(servicelocator.getinstance(anystring())).thenreturn(servicelocator); public void executearemotemethod_test() { SLClient client = new SLClient(); client.executearemotemethod(); Listagem 5. Cancelando a execução dos Construtores SL- BaseClient.class) public class SLClient_MockConstrutor_Test { public void setup() { PowerMock.suppress(PowerMock.constructor(SLClient.class)); //... Se a classe tiver mais de um construtor você pode definir qual dos construtores poderá ser suprimido apenas informando os tipos dos parâmetros na chamada do método PowerMock.constructor(). Este é um exemplo caso a classe SLClient além do construtor padrão também tivesse um construtor com uma String como parâmetro. verify(servicodeexclusao).delete(anyobject()); PowerMock.suppress(PowerMock.constructor(SLClient.class, String.class)); Métodos Desabilitando recursos Na Listagem 4 trazemos a saída em console da execução da classe teste SLClient_Test. Menos raros, mas ainda comuns, são os casos em que pode ser necessário desabilitar a execução de alguns métodos. conhecida chamada PowerMock.suppress alterando o parâmetro de 51

5 PowerMock.constructor para PowerMock.method. A segunda é efetuando um PartialMock, onde apenas os métodos declarados serão substituídos. Ambas as implementações obterão o mesmo resultado com a diferença de que utilizando createpartialmock o construtor é substituído, ou seja, ele não é executado. A não ser que seja trocado o método createpartialmock por createpartialmockandinvokedefaultconstructor. Dessa forma fica mais fácil acompanhar o que acontece quando algum recurso é substituído, mesmo apenas tendo o console. em que a equipe de testes do Google escreveu sobre qual o mínimo e o máximo a ser testado em: com/2008/02/in-movie-amadeus-austrian-emperor.html. Se você optou por escolher o primeiro lado, os que acham que testando o método público também estará testando os métodos privados associados a ele, a Listagem 7 é para você. A implementação segue o mesmo modelo de métodos públicos, adicionando duas chamadas: Listagem 6. Cancelando a execução de métodos e utilizando PartialMock para substituir apenas métodos { ServiceLocator.class, SLClient.class ) public class SLClient_Method_Test { //... public void desabilita_metodo_suppress_test() { PowerMock.suppress(PowerMock.method(SLClient.class, getinitializedfromconstructor )); SLClient client = new SLClient(); String a = client.getinitializedfromconstructor(); assertnull(a); client.executedeletemethod(); verify(servicodeexclusao).delete(anyobject()); public void partial_mock_test() { SLClient client = PowerMock.createPartialMock(SLClient.class, getinitializedfromconstructor ); String a = client.getinitializedfromconstructor(); assertnull(a); client.executedeletemethod(); verify(servicodeexclusao).delete(anyobject()); Métodos privados Chegamos a um ponto muito delicado: os métodos privados. Alguns dizem que testar métodos privados é desperdício de tempo, uma vez que os métodos públicos que fazem uso dos métodos privados já são testados e com isso os privados já o são. Outros rebatem dizendo que é muito trabalhoso implementar e manter testes de métodos públicos incluindo as verificações necessárias requeridas. Para este exemplo fizemos uma pequena alteração na classe SL- Client.java. Introduzimos um método privado (iscliente) retornando um booleano. A partir deste retorno é que o serviço de exclusão (service.delete()) do cliente é chamado (Listagem 8). Antes de escolher um lado nesta batalha, dê uma olhada no artigo Listagem 7. Substituição de métodos privados. SLCliente_Method_Test.java. public void notaclient_false_test() throws Exception { SLClient client = PowerMock.createPartialMock(SLClient.class, iscliente ); boolean expectedresult = false; PowerMock.expectPrivate(client, iscliente, cliente 1 ). andreturn(expectedresult); PowerMock.replay(client); client.executedeletemethod(); verifyzerointeractions(servicodeexclusao); Listagem 8. Inclusão do método privado iscliente e utilização do mesmo. SLCliente.java. public void executedeletemethod() { System.out.println( execução de executedeletemethod ); ServicoDeExclusao servico = (ServicoDeExclusao) ServiceLocator. getinstance(slclient.jndi_location_1).lookup(servicodeexclusao.class); String cliente = cliente 1 ; if (iscliente(cliente)) { servico.delete(cliente); else { System.out.println( nothing to do ); private Boolean iscliente(object o) { return o!= null; Utilizando o PowerMock, você também pode chamar métodos privados de fora das classes. Não tão simples quanto se estivesse utilizando Groovy, mas ainda assim possível. A Listagem 9 mostra como fazer. Na Listagem 9, todo o conteúdo do método iscliente foi ignorado, e quando chamado retornará o valor true, ou seja, este é um cliente. Foi introduzida uma nova funcionalidade do framework PowerMock, a classe Whitebox, que será descrita em detalhes mais adiante. 52

6 Listagem 9. Chamada de métodos privados. SLCliente_Method_Test.java public void calling_private_method_test() throws Exception { SLClient client = PowerMock.createPartialMock(SLClient.class, iscliente ); boolean expectedresult = true; PowerMock.expectPrivate(client, iscliente, cliente 1 ). andreturn(expectedresult); PowerMock.replay(client); boolean result = Whitebox.invokeMethod(client, iscliente, cliente 1 ); asserttrue(result); Inicializadores estáticos A motivação para implementação de inicializadores estáticos de classe é a de assegurar que determinado bloco seja executado sempre que esta classe seja inicializada não importando qual construtor utilizado, caso esta tenha mais de um. As motivações para a não utilização variam em torno da quebra de OO e a dificuldade quanto aos testes desta classe. Existe mais de uma alternativa para a não utilização de inicializadores estáticos, a mais simples é incluir todas as chamadas necessárias à inicialização da classe no construtor da classe. Caso a classe possua mais de um construtor e estes possuam uma inicialização em comum, uma alternativa é criar um método de inicialização comum e também sempre usar encadeamento de construtores, quando possível. Alternativas mais elaboradas passam por criação de um Proxy, utilizando InvocationHandler (veja um exemplo da criação de um Proxy nos links de referência deste artigo). Uma solução também poderia ser a utilização do design pattern Builder. Enfim, alternativas para a não utilização de um bloco estático na inicialização de uma classe existem e passam das mais triviais para as mais elaboradas, cabe a você escolher uma. Se estiver na dúvida de qual seria a melhor a ser utilizada, eu sugiro fazer uma prova de conceito de cada alternativa, assim você terá uma real experiência das implementações e do esforço de cada uma diante de seu projeto. Em nosso exemplo, vamos desabilitar a inicialização estática de uma classe. Utilizaremos um construtor padrão para isso, mas um construtor diferente pode ser utilizado sem nenhum tipo de alteração. Para isso, será necessária a inclusão de uma anotação no nível da Atenção para o parâmetro dessa anotação! Esta recebe uma String e não uma classe. A justificativa para tal é de que se for passada uma classe esta será carregada no classloader e inviabilizará a desabilitação do bloco estático. Como tratamos de uma readequação do sistema, o ponto negativo nesta abordagem é que as chances de alterarmos não apenas classes e métodos, mas também a localização de pacotes é muito alta. Se essa alteração ocorrer teremos um erro em tempo de execução dos testes. Para o pessoal que está acostumado a lidar com linguagens dinâmicas como Groovy e Ruby isso não será exatamente um problema. Estamos utilizando como base para a implementação do código de teste a classe SLClient.java. Na Listagem 10 é apresentada a implementação do teste suprimindo a execução do bloco de inicialização estático. Repare que na saída do console, na Listagem 16, não consta o texto informando que passou pelo inicializador estático. Compare as saídas nas Listagens 4 e 11. Na Listagem 11 o texto: Execução da Inicialização Estática de SLClient. não é exibido. Listagem 10. Suprimindo a inicialização estática SLClient_ mj.teste.servicelocator.client.slclient ) public class SLClient_StaticInitializer_Test { public void staticinitialization_suppressed_test() throws Exception { SLClient client = new SLClient(); assertnotnull(client); Listagem 11. Saída produzida pela execução da classe de teste: SLClient_StaticInitializer_Test. Constructor de Base Client Chamada a um WS informando que algum cliente está ativo.. mj.teste.servicelocator.client.slclient Construtor de StClient Chamada a um WS informando que o cliente Cliente está ativo.. mj.teste.servicelocator.client.slclient objetos O PowerMock possui uma classe chamada Whitebox, que é a responsável por fazer o "serviço sujo" de burlar o encapsulamento. Ou seja, literalmente desconsidera toda a modelagem (ou a falta dela) do sistema. Há quem defenda que a utilização de Whitebox é comparada à execução de um projeto utilizando o Maven com a diretiva -DskipTests, isso é jogo sujo! Mas a verdade é que usando Whitebox é possível criar uma classe utilizando o construtor privado da mesma, poderíamos, por exemplo, suprimir a funcionalidade de um singleton. Também é possível chamar um método privado, como mostrado anteriormente. A Listagem 18 faz todo este trabalho sujo. Na Listagem 12 é apresentado o código da nossa classe Cliente. Ela não está tão ruim, mas ainda assim a classe contém o cálculo de idade que é feito baseado no conteúdo da variável yearborn. Queremos externalizar o método privado calculateage(), mas este método está intimamente ligado à classe, fazendo uso da variável de instância yearborn. Portanto, precisamos assegurar que o comportamento deste método esteja 100% testado para depois implementar em outra classe, onde o cálculo de idade pode ser reutilizado para outras localidades do código. 53

7 public class ClientVO { private static String DEFAULT_NAME = NOME PADRAO ; private String name; private String address; private Integer yearborn; private Integer age; public ClientVO(String name, String address, Integer yearborn) { this.setname(name); this.setaddress(address); unused ) private ClientVO() { private int calculateage() { int age = 0; try { Calendar cal = Calendar.getInstance(); int thisyear = cal.get(calendar.year); age = thisyear - this.yearborn; catch (Exception e) { // this is absurd! System.err.println( Ups, erro aqui ); return age; public String getname() { if (name!= null) { return this.name; else { return ClientVO.DEFAULT_NAME; //outros gets e sets O primeiro passo é configurar o calendário para que, quando questionado quanto ao ano atual, este responda que é 2060, sempre. Esta configuração está feita no método setup().estamos fazendo utilização do método mockstatic() junto com when(). O primeiro teste é apenas para nos certificarmos que tudo está OK, que o cálculo de idade está sendo feito quando a classe é criada utilizando o único construtor disponível. O segundo método de teste (privconstructor_privmethod_test()) faz uso da Whitebox para chamar o construtor padrão (invoke- Constructor()) e o método calculateage(invokemethod()). Note que ambos são métodos privados e ainda assim a classe Whitebox é capaz de invocar estes métodos. Como o construtor padrão não idade e atualizar o campo age, este tem seu valor zerado. O último método de teste, privconstructor_changestate_test(), além de instanciar a classe através do construtor privado e chamar o método privado calculateage(), também altera o valor de um campo privado yearborn, através da chamada: Whitebox.setInternalState(). Com este campo preenchido, o resultado da chamada ao método calculateage() deverá ser diferente de zero. - { Calendar.class, ClientVO.class ) public class ClientVO_PrivateConstructor_Test Calendar public void setup() { when(cal.get(calendar.year)).thenreturn(integer.valueof(2060)); PowerMockito.mockStatic(Calendar.class); when(calendar.getinstance()).thenreturn(cal); public void fine_test() throws Exception { final String name = nome ; final String address = endereco ; final Integer yearborn = 2000; ClientVO client = new ClientVO(name, address, yearborn); asserttrue(60 == client.getage().longvalue()); public void privconstructor_privmethod_test() throws Exception { ClientVO client = Whitebox.invokeConstructor(ClientVO.class); Integer age = Whitebox.invokeMethod(client, calculateage ); asserttrue(0 == age); public void privconstructor_changestate_test() throws Exception { ClientVO client = Whitebox.invokeConstructor(ClientVO.class); Integer age = Whitebox.getInternalState(client, age ); assertnull(age); Whitebox.setInternalState(client, yearborn, 2000); asserttrue(2000 == client.getyearborn()); age = Whitebox.invokeMethod(client, calculateage ); asserttrue(60 == age); Algumas vezes a implementação de um único teste nos leva à escrita de algumas dezenas de códigos para a configuração de um ambiente. 54

8 Durante todos os exemplos deste artigo, utilizamos um artifício muito útil do JUnit que é a Uma rápida explicação sobre esta funcionalidade. Antes de executar o conteúdo do teste anotado com, o JUnit executará o código dentro do método anotado Muito útil para configurações genéricas dentro do mesmo cenário de teste, ou mesmo para manter o código de teste livre de configurações. Tomando o nosso último código como exemplo, Listagem 13, vamos fazer algumas modificações a fim de generalizarmos a configuração do cenário de testes. Para os três testes na Listagem 13, é necessário que sempre que o ano, solicitado através da classe Calendar, responda com o valor Na implementação anterior colocamos este comportamento dentro do método setup(), anotado No entanto, gostaríamos de externalizar cada um dos métodos de teste. Seja porque o código de teste ficou muito extenso, ou o objetivo dos testes não esteja vinculado, não faz mais sentido mantê-los na mesma classe. Mesmo assim, precisamos de um comportamento único da classe Calendar. Existem várias opções de solução para este problema. Com Java puro, herança seria o mais indicado, ou então a implementação de um método utilitário que exportasse a data desejada. Nossa solução será utilizando MockPolicy, uma funcionalidade do Powermock. MockPolicies são implementações genéricas que serão inseridas na classe referenciada pela Como parâmetro, a anotação recebe um array de objetos que implementem a interface PowerMockPolicy. Os métodos que devem ser implementados applyclassloading- Policy e applyinterceptionpolicy serão invocados sempre antes do método anotado com, funciona de forma similar Na Listagem 14 você pode ver a implementação de um MockPolicy para o nosso último exemplo, a simulação da classe Calendar e na Listagem 15 você confere a utilização desta Policy. ApplyClassiLoadingPolicy ApplyInterceptionPolicy Informa ao classloader do PowerMock quais classes devem ser modificadas. Neste método devem ser informadas as classes que deveriam constar Efetivamente altera o comportamento das classes informadas no método anterior (applyclassloadingpolicy) Listagem 14. Implementação do MockPolicy public class CalendarYear2kPolicy implements PowerMockPolicy public void applyclassloadingpolicy(mockpolicyclassloadingsettings settings) { settings.addfullyqualifiednamesofclassestoloadbymockclassloader( public void applyinterceptionpolicy(mockpolicyinterceptionsettings settings) { Calendar cal = Calendar.getInstance(); cal.set(calendar.year, 2060); final Method getinstance = Whitebox.getMethod(Calendar.class, getinstance ); settings.stubmethod(getinstance, cal); Listagem 15. Utilização do MockPolicy para a public class ClientVO_MockPolicy_Fine_Test { public void fine_test() throws Exception { final String name = nome ; final String address = endereco ; final Integer yearborn = 2000; ClientVO client = new ClientVO(name, address, yearborn); asserttrue(60 == client.getage().longvalue()); Para Saber Mais Evolução do Design através de Testes e o TDD Edição 41 Autor: Lucas Souza e Paulo Silveira Automação de Testes de Aceitação com Cucumber e JRuby Edição 40 Autor: Demetrius Nunes Automatização de testes de persistência com FIT, DBUnit e HSQLDB Edição 38 Autor: Alexandre Gazola Testes de Unidade Avançados com o JMock 2 Edição 31 Autor: Eduardo Guerra Testes unitários para camadas de negócios no mundo real Edição 23 55

9 Considerações finais Manter ou estender um código desenvolvido nos primórdios da linguagem Java pode ser algo muito difícil, tanto para o desenvolvedor quanto para a empresa, principalmente considerando a alta rotatividade pela insatisfação do programador em lidar com código estagnado ou mesmo quanto ao retrabalho em desenvolver funcionalidades disponíveis em versões mais recentes de frameworks ou bibliotecas de desenvolvimento. Utilizando técnicas de refactoring, com responsabilidade, testando sempre antes de aprimorar determinada funcionalidade, é uma alternativa atraente na batalha de manter o código sempre atualizado, pronto para a utilização dos melhores e mais modernos frameworks e com o mínimo impacto no produto final. Referências Livros Web - austrian-emperor.html html Mock objects são objetos que simulam comportamento de objetos reais. Frequentemente utilizados no desenvolvimento de testes ou quando existe integração entre sistemas e um deles ainda não está disponível para tal integração. Mock Objects possuem características programáveis, como: Lei de Demeter A Lei de Demeter é um caso prático de baixo acoplamento. O conceito básico é de que dado um objeto, o mínimo necessário de conhecimento sobre sua estrutura e propriedades deve ser conhecido. Minha mãe já dizia: Não fale com estranhos. E é exatamente isso que diz a Lei de Demeter. A um objeto só é permitido acessar recursos de objetos conhecidos. Ou seja, objetos declarados dentro da própria classe ou do próprio método. 1. Exemplo de código falando com estranhos Estado estado = cadastrodepessoa.getendereco().getcidade(). getestado(); 2. Exemplo de código sem falar com estranhos Estado estado = cadastrodepessoa.getestado(); 56 Esta afirmação é polêmica. De qualquer forma um Singleton não trata apenas de um assunto, ele trata no mínimo de dois. E esta duplicidade de papéis já é o suficiente para considerá-lo algo não adequado no desenvolvimento de sistemas. Alguns outros motivadores a serem considerados: Isto é uma verdade, assim como qualquer variável estática um começam a aparecer quando surge a necessidade de instalar o software desenvolvido com alguns singletons em um ambiente com cluster. O sistema terá o mesmo comportamento, na aplicação, e isto pode não ser o adequado. Ligação forte entre as classes. Um dos princípios da testabilidade é o baixo acoplamento entre as classes. O baixo acoplamento permite que os objetos sejam mockados de acordo com o cenário que se deseja testar. Utilizando um singleton você está ligando fortemente à implementação da classe com o comportamento do Singleton. Não é impossível, mas ao menos muito mais trabalhoso de implementar e manter os testes de classes dependentes de Singleton. Existem vantagens e desvantagens em se aplicar a Lei de Demeter. Uma grande vantagem é que o código fica menos dependente da estrutura interna, mais legível e com isso manutenível. Uma desvantagem é que algumas vezes é necessário escrever mais código apenas para externalizar algumas funcionalidades Wrappers como feito no exemplo. Princípio da Responsabilidade Única O conceito da Responsabilidade Única prega que cada objeto deve ter apenas uma responsabilidade e que esta responsabilidade deve estar completamente encapsulada na classe. Todos os serviços devem estar alinhados com a responsabilidade daquela classe. Este termo foi introduzido por Robert Martin Uncle Bob