A utilização de métodos estáticos, na maioria dos casos, deve ser evitada por dificultar os testes unitários e criar um alto acoplamento. Mas se você se deparar com um método estático e tiver que sobrescrever seu comportamento para implementar testes unitários utilizando a técnica Mock Objects, indico a ferramenta PowerMock.

Esse framework permite a criação de mocks de métodos marcados com static ou até mesmo final. O PowerMock é utilizado como uma extensão de outras ferramentas de mock, como o EasyMock e o Mockito.

Exemplo

O trecho de código abaixo retirado deste exemplo, demonstra como utilizar o PowerMock com o EasyMock:

import org.junit.Test;
import org.junit.runner.RunWith;
import org.powermock.core.classloader.annotations.PrepareForTest;
import org.powermock.modules.junit4.PowerMockRunner;
import org.powermock.reflect.Whitebox;
import samples.singleton.StaticService;

import static org.easymock.EasyMock.expect;
import static org.junit.Assert.*;
import static org.powermock.api.easymock.PowerMock.*;

@RunWith(PowerMockRunner.class)
@PrepareForTest( { StaticService.class })
public class MockStaticTest {

 @Test
 public void testMockStatic() throws Exception {
  mockStatic(StaticService.class);
  String expected = "Hello altered World";
  expect(StaticService.say("hello")).andReturn("Hello altered World");
  replay(StaticService.class);

  String actual = StaticService.say("hello");

  verify(StaticService.class);
  assertEquals("Expected and actual did not match", expected, actual);
 }
}

O método estático a ser “mockado” é o say da classe StaticService. Suponha que a implementação deste método retorna “Hello World”. O objetivo deste código de exemplo é sobrescrever o comportamento de say para retornar “Hello altered World” quando recebe “hello” como parâmetro.

A linha 12 define o runner do PowerMock para o JUnit 4 e a linha 13 informa quais as classes que devem ser preparadas para o teste. Entre as linhas 18 e 21 é definido o comportamento esperado para o metodo say, que é retornar “Hello altered World” quando receber “hello” como parâmetro. O método say é chamado na linha 23 e retornará o valor definido, o que é verificado nas linhas 25 e 26.

A utilização do PowerMock é praticamente igual à do EasyMock padrão, com excessão do runner, da annotation @PrepareForTest e da chamada do método mockStatic.

Por que eu preciso disso?

Um caso em que o PowerMock ajuda muito é quando foi utilizado o design pattern Singleton ou um Factory Method estático. Por exemplo, no código a seguir é chamado o método getInstance de ServicoAutenticacao.

public class LoginController {

 public void realizarLogin(String login, String senha) throws LoginInvalidoException {
  ServicoAutenticacao servicoAutenticacao = ServicoAutenticacao.getInstance();

  //faz algo...
 }
}

O problema é que para realizar os testes unitários você não deve utilizar a implementação real deste serviço, já que ele pode depender de recursos (banco de dados, LDAP, etc.) e é necessário sobrescrever seu comportamento para os testes. Com o PowerMock você sobrescreve o método estático para retornar uma implementação fake do serviço ou um mock object.

O ideal neste caso seria substituir o método estático por uma Injeção de Dependência, porém isso não é possível se você estiver utilizando uma API ou framework que tenha uma chamada desse tipo.

Instalação

A página Getting Started da wiki do projeto explica como adicionar a biblioteca em seu projeto, utilizando o Maven ou não.

Referências

• Site do projeto PowerMock
• Site do projeto EasyMock
• Site do projeto Mockito
• Testes com Mock Objects – Inprove It
• Mocking static methods in Java system classes

Foi anunciado hoje (12/01/12) o Android Design, um site que possui diversas instruções e dicas de design e experiência do usuário para o desenvolvimento de aplicações para o Android 4.0 (Ice Cream Sandwich).

A documentação é bem completa e está divida em Get Started, Style, Patterns e Building Blocks. Cada página possui imagens, textos explicativos e exemplos a serem seguidos.

Na minha opinião, este é um grande passo para a plataforma Android. A preocupação com design e UX nas aplicações para iOS atualmente é muito maior. Com a reformulação da UI no Ice Cream Sandwich e a criacão do Android Design, o Google demonstra que quer acabar com essa desvantagem em relação ao seu rival.

E você, o que achou do Android Design?

Para quem não conhece, o BDD descreve os comportamentos do sistema em uma linguagem compreendida por todos os envolvidos do projeto (cliente, desenvolvedores, equipe de QA, etc.) e possibilita automatizar os testes de aceitação em aplicações web. Considerada por muitos a evolução do TDD (Test Driven Development), essa metologia é útil para equipes que utilizam metodologias ágeis no desenvolvimento de aplicações web.

Se você ainda não conhece essa metodologia ou ainda não aplicou ela integrada com o Selenium, dê uma conferida no meu artigo. Aguardo seu feedback

Leia o artigo na versão digital da revista

Agradeço ao Eduardo Spínola pelo convite para escrever na Java Magazine.

A conferência aconteceu no último sábado (15/10/11) e contou com palestras muito interessantes sobre Android, Flex, .NET, Desenvolvimento de Jogos, HTML5, jQuery e também minha palestra sobre TDD.

Assista as gravações e compartilhe para que a próxima edição da #soudevcon seja ainda melhor e com mais participantes.

Abaixo os links das gravações:

• Desenvolvedor no controle utilizando TDD (código-fonte e slides aqui)
• Plataforma Android
• Aplicações Flex + .NET Plataform + ADO.NET Entity Framework
• Quero ser um desenvolvedor de Jogos
• Armazenamento local com WebStorage HTML5
• jQuery – Essencial

A descrição de cada palestra você pode conferir no site oficial do evento.

Atualizado em 19/10: A gravação da palestra agora também está disponível.

Slides da palestra:

Código-fonte: 
https://github.com/victorserta/exemplostdd/tree/master/controle_estoque_soudevcon

Gravação:
Clique para assistir

Curtiu a palestra ou tem alguma dúvida? Deixe seu comentário aqui e compartilhe no twitter.

Agradeço o feedback do pessoal no twitter após a palestra:

@jandersonfc: “excelente palestra so @victorserta sobre #tdd no #soudevcon #soudev … parabéns brother”

@diogorosanelli: “Palestra do Victor Serta sobre #TDD show de bola no #soudevcon Parabéns ! 8)”

@gilmarpalega: “Nota 10 para a palestra #TDD do @victorserta no #soudevcon #soudev”

@lincolnpomper: “Peguei só o final da palestra sobre #TDD do @victorserta no #soudevcon mas parece que foi ótima como sempre.

Hashtags: #soudev #soudevcon #tdd

Eu irei palestrar no evento falando sobre TDD. Dê uma conferida na descrição da minha palestra:

Desenvolvedor no controle utilizando TDD

Nessa palestra apresentarei o que é TDD (Test Driven Development) e seus conceitos de forma muito prática. Essa técnica ajuda a produção de softwares com mais qualidade e coloca o desenvolvedor realmente no controle do código. Assim você se livra das longas sessões de debug, códigos incompreensíveis e arquiteturas no estilo “matar uma formiga com um canhão”.

Agenda

Abaixo a grade com os horários de todas palestras que vão rolar no evento:

08:30 – 09:00 – Abertura da Conferência Soudev
09:00 – 10:15 – Desenvolvedor no controle utilizando TDD
10:15 – 11:30 – Git na prática
11:30 – 12:45 – Plataforma Android
14:00 – 15:15 – Aplicações Flex + .NET Plataform + ADO.NET Entity Framework
15:15 – 16:30 – Quero ser um desenvolvedor de Jogos
16:30 – 17:45 – Armazenamento local com WebStorage HTML5
17:45 – 19:00 – jQuery – Essencial

Participe acessando este link e ajude a divulgar pelo twitter com a hashtag #soudevcon.
Para mais informações, acesse o site do evento: http://conference.soudev.com.br.

Gravação da palestra:
http://experts.adobeconnect.com/p4jsu4pxctu/

Slides da palestra:

Código-fonte apresentado: 
https://github.com/victorserta/Palestra_Selenium_Flex

Tópicos da palestra:

• Por que testar?
• Testes no desenvolvimento ágil
• O que é Selenium?
• Ferramentas para utilizar Selenium com aplicações Flex
• sfapi: Selenium Flex API
• Flash Selenium
• FlexUISelenium
• FlexMonkium
• Exemplo integração contínua
• Exemplo testes como documentação

Ficou alguma dúvida ou tem algum comentário/crítica? Então poste um comentário aqui ou envie um tweet pra mim (@victorserta).

PS.: Obrigado ao @guisjlender, @samuelfac, @igorcosta, @MarcPires e @MrAndreatta pelo feedback no Twitter após a palestra. Agradeço também a RIACycle pela organização do evento e pela oportunidade de palestrar.

O Flex Mania 2011 é essa semana! O evento online tem como principais temas as tecnologias Adobe Flex e AIR. Serão mais de 30 palestras em 4 dias de evento (7 a 10 de Julho).

A minha palestra no evento será no sábado de manhã às 9:15 e falarei sobre testes de aplicações desenvolvidas em Flex com a ferramenta Selenium. Vou demonstrar de forma prática como utilizar essa ferramenta com Flex e como aplicar os conceitos no contexto de desenvolvimento ágil.

Se você tem alguma dúvida ou sugestão em relação ao assunto, comente aqui que eu respondo durante a palestra.

Mais detalhes sobre o evento no site http://www.flexmania.com.br

Neste post vou apresentar as principais ferramentas utilizadas com essa finalidade em Java, mas antes uma explicação inicial sobre o assunto. Dê uma olhada no código Java abaixo:

public class CaixaMercado {

 private CatalogoProdutos catalogoProdutos = new CatalogoProdutosBD();

 private List<Produto> itensCompraAtual;

 public void iniciarNovaCompra() {
  itensCompraAtual = new ArrayList<Produto>();
 }

 public void produtoPassadoNoLeitor(String codigoDeBarras) throws ProdutoInexistenteException {
  if (itensCompraAtual == null) {
   throw new IllegalStateException("Compra não foi iniciada.");
  }

  Produto produto = catalogoProdutos.buscarPeloCodigoBarras(codigoDeBarras);

  if (produto == null) {
   throw new ProdutoInexistenteException();
  }

  itensCompraAtual.add(produto);
 }

 public List<Produto> finalizarCompra() {
  // faz algo

  List<Produto> itensCompraAnterior = itensCompraAtual;
  itensCompraAtual = null;

  return itensCompraAnterior;
 }
}

Neste exemplo quando um objeto da classe CaixaMercado é instanciado, também é instanciado um objeto do tipo CatalogoProdutosBD (veja na linha 3). Isso torna a classe CaixaMercado dependente da implementação do catálogo lido a partir do banco de dados. Você pode pensar: “Mas nunca vou utilizar outra fonte de dados mesmo.”. E com relação aos testes unitários?  E se a classe CatalogoProdutosBD precisasse receber algum parâmetro específico?

Resolvendo “manualmente”

A opção mais simples para resolver este problema é injetar o catálogo de produtos no construtor da classe CaixaMercado. Dessa forma, a classe CaixaMercado fica totalmente desacoplada da implementação de CatalogoProdutos, pois não tem conhecimento se o produto será consultado a partir da base de dados ou arquivo texto, por exemplo. Neste caso, também poderia ser utilizado um método setter para a injeção.

public class CaixaMercado {

 private CatalogoProdutos catalogoProdutos;

 private List<Produto> itensCompraAtual;

 public CaixaMercado(CatalogoProdutos catalogoProdutos) {
  this.catalogoProdutos = catalogoProdutos;
 }

//...
}

Essa técnica pode ser aplicada para ligar diferentes componentes de sua aplicação com o objetivo diminuir o acoplamento entre eles. Para facilitar a utilização de DI, existem vários frameworks que auxiliam na injeção de objetos através de metadados, como XML e annotations. A seguir apresento as principais opções utilizadas na tecnologia Java.

Spring

O Spring é um framework de IoC (Inversão de Controle)  que utiliza a técnica de Injeção de Dependência. Para o código de exemplo, a configuração através de XML seria:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd">
<beans>
 <bean id="CatalogoProdutos" class="org.exemplo.di.CatalogoProdutosBD" />
 <bean id="CaixaMercado" class="org.exemplo.di.spring.CaixaMercado">
  <property name="catalogoProdutos" ref="CatalogoProdutos" />
 </bean>
</beans>

Nas últimas versões do Spring é possível utilizar apenas annotations no lugar do XML para realizar essa configuração, conforme mostra o código abaixo:

public class CaixaMercado {

 @Autowired
 private CatalogoProdutos catalogoProdutos;

 private List<Produto> itensCompraAtual;

 //...
}

@Component
public class CatalogoProdutosBD implements CatalogoProdutos {

 @Override
 public Produto buscarPeloCodigoBarras(String codigo) {
  //...
 }
}

O escopo das instâncias gerenciadas pelo Spring podem ser definidos por XML com o atributo scope ou através da annotation @Scope. Os valores possíveis são:

• singleton: Instância única por IoC container
• prototype: Nova instância em cada requisição
• request: Nova instância por requisição HTTP
• session: Nova instância por sessão HTTP
• globalSession: Nova instância por sessão HTTP global (utilizado com portlets)

O Spring também define as seguintes especializações da annonation @Component para identificar diferentes tipos de objetos:

• @Controller
• @Service
• @Repository

Como todo desenvolvedor Java deve saber, o Spring é muito mais do que isso. O objetivo aqui foi apresentar apenas como trabalhar com injeção de dependência com este framework.

Guice

Outra opção é o Guice (pronuncia-se “juice”), que é um framework de injeção de dependências desenvolvido pelo Google. De acordo com o site do projeto, o próprio Google o utiliza em aplicações de missão crítica desde 2006. Abaixo o mesmo exemplo utilizando o Guice:

public class CaixaMercado {

 @Inject
 private CatalogoProdutos catalogoProdutos;

 private List<Produto> itensCompraAtual;

 //...
}

Não é necessária nenhuma mudança na classe CatalogoProdutosBD em relação a implementação original. Entretanto, é necessário criar uma classe que define quais são as implementações a serem injetadas:

public class CaixaMercadoModule extends AbstractModule {

 @Override
 protected void configure() {
  bind(CatalogoProdutos.class).to(CatalogoProdutosBD.class);
 }

}

O Guice pode ser utilizado em projetos web tornando possível definir o escopo das instâncias dos tipos que são injetados. Para isso são disponibilizadas as seguintes annotations:

• @Singleton
• @SessionScoped
• @RequestScoped

Seam

O JBoss Seam  surgiu com o objetivo inicial de realizar uma melhor integração entre o JSF e EJB 3, porém atualmente é um framework muito completo e pode ser utilizado sem EJB ou até mesmo com o Apache Wicket no lugar do JSF, por exemplo. Até a versão 2.x utilizaríamos da seguinte maneira:

public class CaixaMercado {

 @In
 private CatalogoProdutos catalogoProdutos;

 private List<Produto> itensCompraAtual;

 //...
}

@Name("catalogoProdutos")
public class CatalogoProdutosBD implements CatalogoProdutos {

 @Override
 public Produto buscarPeloCodigoBarras(String codigo) {
  //...
 }
}

A partir do Seam foram propostas e aprovadas a JSR 330: Dependency Injection for Java e a JSR 299: Contexts and Dependency Injection for the Java EE platform. A implementação de referência da JSR 299 é o projeto Weld, que foi baseado no core do Seam. A versão 3 do Seam utiliza o Weld e adiciona funcionalidades especificas que não estão padronizadas.

JSR 330: Dependency Injection for Java

A JSR 330 padroniza as annotations para a injeção de dependências na linguagem Java. As últimas versões do Spring, Guice e Seam são compatíveis com este padrão. Veja abaixo como fica o exemplo:

public class CaixaMercado {
 @Inject
 private CatalogoProdutos catalogoProdutos;

 private List<Produto> itensCompraAtual;

 //...
}

@Named("catalogoProdutos")
public class CatalogoProdutosBD implements CatalogoProdutos {

 @Override
 public Produto buscarPeloCodigoBarras(String codigo) {
  //...
 }
}

As annotations criadas para injeção de dependências através da JSR 299 estão todas no pacote javax.inject.*. Essas annotations são:

• @Inject: Injeta um objeto em atributo, construtor ou método
• @Named: Qualificador de tipo a ser injetado através de uma string
• @Singleton: Instância única do tipo a ser injetado
• @Qualifier: Identifica annotation que qualifica tipo a ser injetado
• @Scope: Identifica annotation que define um tipo de escopo

Na prática as 2 últimas annotations (@Qualifier e @Scope) são utilizadas pelas implementações (Seam, Guice, etc.) ou quando se deseja realizar alguma customização específica.

JSR 299: CDI for the Java EE platform

Essa JSR descreve várias outras funcionalidades além da injeção de dependências. Para este post vou somente apresentar as annotations que definem os possíveis escopos dos objetos criados para serem injetados, que complementam as especificados pela JSR 330:

• @ApplicationScoped
• @SessionScoped
• @RequestScoped
• @ConversationScoped

EJB 3

Quem utiliza EJB 3 também tem disponível annotations para injeção de dependências. Essas annotations são:

• @EJB: Injeta um session bean
• @PersistenceContext: Injeta o EntityManager gerenciado
• @PersistenceUnit: Injeta o EntityManagerFactory
• @Resource: Injeta recurso disponível na árvore JNDI (Data Source, JMS, etc.)
• @WebServiceRef: Injeta referência para um webservice

Utilizando essas annotations, o container irá realizar o lookup dos objetos e injetá-los. Se fossemos utilizar EJB para o exemplo, poderíamos considerar a implementação de CaixaMercado como um Session Bean Stateful e a implementação do CatalogoProduto como Stateless. Abaixo o código:

@Local
public interface CaixaMercado {
 public void iniciarNovaCompra();
 public void produtoPassadoNoLeitor(String codigoDeBarras);
 public List<Produto> finalizarCompra();
}

@Stateful
public class CaixaMercadoBean implements CaixaMercado {

 @EJB
 private CatalogoProdutos catalogoProdutos;

 private List<Produto> itensCompraAtual;

 //...
}

@Local
public class CatalogoProdutos
 public Produto buscarPeloCodigoBarras(String codigo);
}

@Stateless
public class CatalogoProdutosBD implements CatalogoProdutos {

@Override
public Produto buscarPeloCodigoBarras(String codigo) {
//...
}
}

Lembrando que também é possível utilizar implementações da JSR 299 em conjunto com o EJB 3.

Outras opções

Abaixo outras opções de ferramentas que podem ser utilizadas para auxiliar a injeção de dependência:

• PicoContainer
• Apache Attic
• Apache HiveMind (descontinuado)

Se você souber de mais alguma me avisa que eu adiciono aqui

Conclusão

Nesse post descrevi o que é, por que e como utilizar o conceito Injeção de Dependência em Java. Cada ferramenta apresentada aqui possui muito mais funcionalidades para injeção de objetos e não se limitam a somente essa função. Escolha a(s) sua(s) e bons estudos!

Referências

• Inversion of Control Containers and the Dependency Injection pattern – Martin Fowler
• Spring Framework Reference: The IoC container
• Javadoc Spring 3.0.x
• Spring 3.0 and JSR 330: Using @Named
• Google Guice User’s Guide: Getting Started
• Javadoc Google Guice
• Seam 3 Reference Guide
• JSR 330 – Java Community Process
• Javadoc JSR 330
• JSR 299 – Java Community Process
• Javadoc JSR 299
• Dependency Injection in EJB 3
• Exemplo de cadastro com o JBoss Seam

Quer assistir palestras interessantes e ao mesmo tempo ajudar as vítimas das fortes chuvas que atingiram o Paraná? Este é o objetivo do evento IT Care-PR que contará com a presença de Roger Brinkley da Oracle.

Eu participarei do evento com a palestra TDD com Java, onde vou explicar os fundamentos da metodologia Test Driven Development com exemplos na linguagem Java.

Além de Java, o evento também terá palestras sobre .NET, Android, iOS (iPhone) e Scrum.

Quando: 14/05/2011
Onde: Universidade Positivo - Auditório 2 da Escola de Negócios (Bloco Amarelo)
Palestras: Clique aqui
Palestrantes: Clique aqui
Inscrição: Clique aqui
Entrada: Alimentos não-perecíveis, material de limpeza e água mineral