Artigos Java Java EE 6: Da configuração aos testes - Revista Java Magazine 107 - Parte 2
Demais posts desta série:
Java EE 6: Da configuração aos testes - Parte 1
Java EE 6: Da configuração aos testes - Parte 3
Artigo no estilo: Curso

Do que se trata o artigo:

Esse artigo demonstra como testar aplicações Java EE 6, como construir interfaces gráficas e como fazer a comunicação com o back-end desenvolvido na primeira parte desse artigo. Para o desenvolvimento dos testes será usado o framework Arquillian, enquanto que para a apresentação será usado o JSF 2/PrimeFaces e o CDI para integração com o back-end.

Em que situação o tema é útil:

O artigo apresenta ao leitor um conjunto de tecnologias que são comumente envolvidas em um projeto Java EE 6 e que trazem grandes benefícios, como automatização de tarefas, aumento de produtividade e melhoria de qualidade da aplicação.

Resumo DevMan:

O desenvolvimento de testes durante a implementação de um sistema é um assunto que ganhou muita importância nos últimos anos e não pode ser esquecido em nenhum projeto, ainda que este use Java EE e necessite de um framework externo para auxílio, como é o caso do Arquillian. Outros dois assuntos que merecem atenção especial são a usabilidade e o tempo de resposta de requisições, pois um sistema de difícil uso e lento pode espantar seus visitantes. Estes são alguns dos temas abordados neste artigo.

Na primeira parte do artigo foi criado o back-end da aplicação de exemplo, cujo objetivo é demostrar de forma prática o uso das tecnologias propostas, como Java EE 6 (CDI, EJB, JPA e JSF), PrimeFaces, Arquillian, Maven e JBoss. Para isso, começamos com uma introdução sobre cada uma dessas tecnologias, a fim de deixar o leitor mais familiarizado com o propósito de cada uma delas. Na sequência, começamos o desenvolvimento da aplicação propriamente dita, passando pela apresentação dos seus requisitos e do seu modelo, pela criação da base de dados e configuração do data source no JBoss, criação e configuração do projeto no Eclipse e no Maven, e a própria codificação. Durante esse processo, explicamos o código desenvolvido em todas as camadas, como modelo, regras de negócio e acesso a dados. Essa segunda parte do artigo dará ênfase aos testes, criação das interfaces e na integração com o back-end.

A criação de testes automatizados há até pouco tempo era considerado por muitos uma tarefa muito custosa e que não trazia ganhos reais. Com a maior popularização de metodologias ágeis, escrever testes automatizados não deixou de ser uma tarefa custosa, porém mostrou e continua mostrando que os ganhos obtidos pagam todo esse investimento. Entre esses ganhos podemos citar melhoria do design e do código da aplicação, segurança na execução de refatorações, classes de testes usadas para ajudar no entendimento do sistema e a possibilidade de se fazer uma bateria de testes de regressão com apenas um clique. Esses ganhos têm feito com que até mesmo os desenvolvedores mais reticentes passassem a adotar o desenvolvimento de testes, e podemos dizer que quem ainda não adotou, está realmente perdendo um recurso fantástico no processo de construção de software. Fora essa questão conceitual, existia ainda a questão técnica no que diz respeito a testes de aplicações Java EE. Muitos criticavam – e com razão – que criar testes para aplicações Java EE era uma tarefa árdua, causando muitas dores de cabeça. Porém, com a criação do Arquillian, testar aplicações Java EE ficou tão simples quanto testar aplicações Spring ou aplicações standalone, o que invalida este argumento usado por alguns desenvolvedores.

Quanto à camada de apresentação, temos percebido nos últimos tempos usuários cada vez mais exigentes no que diz respeito a aplicações ricas e interativas. Essa exigência trouxe novas complexidades no desenvolvimento e fez com que novas ferramentas surgissem para facilitar essa tarefa. Um exemplo destas ferramentas é o jQuery, uma biblioteca JavaScript que, além de simplificar a codificação de aplicações que usam Ajax, também disponibiliza um conjunto de componentes ricos prontos para serem utilizados. Para atender a essa necessidade, o próprio JSF evoluiu bastante em sua versão 2, trazendo recursos como suporte nativo a Ajax e uso de anotações ao invés de arquivos XML. Além disso, alguns frameworks trouxeram um conjunto de componentes para serem usados pelo JSF, como o PrimeFaces e o RichFaces. Nesse artigo iremos utilizar o PrimeFaces, um framework que faz uso do jQuery e que traz uma coleção bem extensa de componentes ricos prontos para serem utilizados na camada de apresentação, além de se integrar naturalmente ao JSF.

O artigo passará por todas essas etapas, mostrando de forma prática como utilizar cada uma dessas ferramentas. Ao final, teremos uma versão totalmente funcional da aplicação, desde os testes automatizados até a disponibilização de interfaces gráficas.

Testando a aplicação

Conforme apresentado na introdução da primeira parte do artigo, testar aplicações Java EE sempre foi uma tarefa penosa. Porém, com a criação do Arquillian, as coisas ficaram muito mais simples e rápidas, especialmente em um container como o JBoss AS 7, que vai ao ar em poucos segundos. Como os testes criados com o Arquillian são executados diretamente no container, podemos escrever testes funcionais reais, sem mocks. Isso faz com que os testes sejam mais eficientes e objetivos, já que todo o software acaba sendo testado em conjunto.

O Arquillian é um framework bastante flexível e oferece ao desenvolvedor três formas de execução:

· Managed: Forma que será utilizada no artigo. Neste cenário, o JBoss AS 7 está instalado na máquina do desenvolvedor, porém é o Arquillian que vai cuidar do seu ciclo de vida, fazendo o deploy do pacote de testes, o start do servidor, a execução do pacote de testes, o undeploy desse pacote e o stop do servidor;

· Remote: O servidor está instalado na máquina do desenvolvedor e deve estar no ar no momento da execução dos testes. O Arquillian apenas faz o deploy/undeploy e execução do pacote de testes;

· Embedded: Parecido com o Managed, porém usa um servidor embarcado para execução dos testes. Nesse caso, o servidor embedded para execução dos testes é baixado pelo próprio Maven e controlado totalmente pelo Arquillian.

Um exemplo real pode ser visto na classe TestClienteServices (Listagem 1), que deve ficar em src/test/java – diretório padrão do Maven para armazenar as classes de teste. Essa é uma classe semelhante a qualquer classe JUnit, porém com algumas modificações para que os testes sejam utilizados pelo Arquillian.

A anotação @RunWith(Arquillian.class) indica que os testes devem ser executados pelo Arquillian e não diretamente pelo JUnit. O interessante de uma classe de testes com Arquillian é que se deve utilizar as próprias anotações do Java EE para fazer a injeção de dependências, da mesma forma que é feito no código real da aplicação. Como pode ser visto no exemplo, a anotação @Inject é usada fazer a injeção de uma instância da interface ClienteServices e da classe utilitária DaoTest (veja a Listagem 2).

A classe DaoTest é um EJB Stateless utilitário usado para auxiliar na classe de testes e possui somente um método, que é responsável por apagar todos os registros de uma determinada entidade JPA.

Para que o Arquillian possa obter todos os recursos solicitados pelo desenvolvedor (como entity manager e EJBs), é necessário que os testes sejam executados diretamente no servidor de aplicações. Para isso, deve-se criar um pacote executável (JAR, WAR ou EAR) em runtime contendo tanto as classes de testes quanto as classes a serem testadas, além de outros recursos necessários, como por exemplo, um persistence.xml. Para a criação desse pacote, é necessário criar um método static, que deve retornar o tipo de empacotamento desejado e ser anotado com @Deployment. No momento da execução dos testes, o Arquillian lê essas configurações e, através do framework ShrinkWrap, cria o pacote com as classes e recursos configurados. No nosso exemplo, a configuração do pacote a ser criado está sendo definida da seguinte maneira:

1. ShrinkWrap.create(WebArchive.class, "testCliente.war"): indica que o pacote a ser criado será um Web Archive com o nome testCliente.war;

2. addClasses(...): indica todas as classes que devem ser empacotadas juntamente com a classe de teste. Existem outros métodos auxiliares, como addPackage();

3. addAsWebInfResource(EmptyAsset.INSTANCE, ArchivePaths.create("beans.xml")): cria um arquivo em branco chamado beans.xml para que o CDI funcione corretamente;

4. addAsResource("test-persistence.xml", "META-INF/persistence.xml"): copia o arquivo test-persistence.xml com o nome persistence.xml, para que a classe de teste aponte para o banco de testes;

...
Quer ler esse conteúdo completo? Tenha acesso completo