TDD. Se você é leitor da MundoJ ou alguma outra revista, em aplicações Java EE com JBoss Arquillian

Transcrição

1 capa_ TDD em aplicações Java EE com JBoss Arquillian Passo-a-passo completo para testar seus EJBs sem Mocks Gabriel Ozeas Bacharel em Ciência da Computação pela Universidade de Franca. Tem contato com Java há mais de 5 anos, possui as certificações SCJP, SCWCD, SCBCD, OCE-EJB, OCMJD, CSM. Trabalha atualmente como desenvolvedor e consultor na equipe de portais da 4Linux, ajudando outras equipes em projetos de órgãos públicos e privados. Ronaldo Florence ronaldo@rd.eti.br Bacharel em Ciências da Computação pela Faculdade Ruy Barbosa, sócio-diretor da empresa RD Tecnologia da Informação e trabalha com Java há 12 anos desenvolvendo aplicações corporativas. Criar uma suíte de testes para uma aplicação que depende de containers pode ser trabalhoso e cansativo. Testes de integração sempre foram difíceis de escrever e lentos de executar, mas isso mudou. Com o JBoss Arquillian testes de integração ficaram tão fáceis que viabilizou o desenvolvimento Java EE utilizando TDD. Neste artigo caminhamos passo-a-passo na criação de um EJB através do ciclo de TDD, mostrando como configurar o Arquillian e como tirar proveito da sua simplicidade na construção de testes de Integração. Se você é leitor da MundoJ ou alguma outra revista, blog ou fórum referente a desenvolvimento, já deve ter notado a quantidade de artigos e comentários sobre testes de software. O quanto eles nos ajudam a proteger a qualidade do nosso código do caos do trabalho em equipe, atualizações, desvio da especificação e outras questões tiradas da lista de problemas no desenvolvimento. Por estes motivos, a fama dos testes não é passageira, ela está mergulhando no dia-a-dia do processo de desenvolvimento das equipes junto às metodologias ágeis. E dentro do processo de desenvolvimento voltado a testes, os testes de integração sempre foram considerados um mal necessário. Eles são mais lentos que os testes de uni-

2 dade, demoram mais e geram erros muito mais complexos de se identificar, já que envolvem a interação entre componentes que podem estar em diferentes camadas e até escritos em diferentes tecnologias. Alguns projetos, especialmente os que tangem o mundo Java EE, como o JBoss Arquillian, JSFUnit, OpenEJB e Selenium, estão facilitando a implementação de testes de integração, diminuindo o esforço necessário para elaborar um bom arsenal de testes mais real. Vamos voltar nossa atenção ao JBoss Arquillian. Neste artigo, você vai passar por um passo-a-passo na criação de testes com o Arquillian, conhecendo os aspectos mais importantes desta ferramenta. Você também irá conhecer o projeto ShrinkWrap, que permite ao desenvolvedor montar pacotes em tempo de execução, focando somente nas classes que devem ser testadas. Está fora do escopo deste artigo a discussão se testes de unidade podem ou não ser substituídos por testes de integração com a utilização de uma ferramenta como o JBoss Arquillian, mas o fato é que com servidores minimalistas como o Glassfish Embedded e JBoss Embedded os teste de integração se tornaram mais rápidos, chegando a rodar em segundos. Unindo-se isso ao enriquecimento dos testes que o Arquillian traz, escrever um teste de integração ficou tão simples quanto escrever um teste de unidade. Arquillian Durante a implementação dos testes para sua aplicação, o uso de mocks e objetos que simulam o comportamento de outros componentes estão extensamente distribuídos pelo suíte de teste. O uso exaustivo deles pode distorcer o teste de integração a ponto de não conseguir avaliar todos os comportamentos do componente testado quando está interagindo com suas dependências, não reproduzindo exatamente as interações que acontecem em ambientes reais. Outro problema encontrado pelos desenvolvedores quando estão implementando testes que empregam recursos externos é a dependência entre testes e ferramentas de build como Maven, Gradle e Ant. Durante o desenvolvimento, é comum os testes de regressão serem executados pelas ferramentas de build, porque são, na maioria das vezes, elas que possuem a integração com os containers através de plugins. Todavia, isso impossibilita o desenvolvedor de utilizar sua IDE como o Eclipse para executar os testes, devido ela não respeitar as pré e pós-fases de testes de integração da ferramenta de build. Para o Arquillian, o ato de gerenciar a integração dos testes com o container em uma aplicação Java EE não deve ser árduo para você, desenvolvedor. Os testes não devem dar voltar e voltas tentando ajustar a infraestrutura para que o cenário faça sentido. O Arquillian prevê um trabalho maior na configuração inicial, livrando os testes de repetirem estes passos dentro de si mesmos. A Listagem 1 mostra um caso de teste para um bean de sessão chamado GerenciadorLivros que utiliza o Arquillian. Para seu funcionamento, ele espera quatro coisas de seu caso de teste: 1. Pelo menos um método anotado com no caso do JUnit. 2. Que o caso de teste seja indicado para executar com o Arquillian, utilizando a RunWith(Arquillian.class). 3. Um método que retorne uma classe que representa o pacote com as classes que serão instaladas no container. Este pacote é montado pelo projeto JBoss ShrinkWrap que será abordado nas próximas sessões. Este método deve ser estático e anotado 4. Por último, um container onde será instalada a aplicação, podendo ser desde um container embutido e leve como Tomcat, Jetty, até servidores de aplicação completos como JBoss e Glassfish. O Arquillian possui alguns adaptadores para a maioria dos containers, e tanto o adaptador quanto o container embutido podem ser declarados no pom.xml do Maven. Veremos mais a frente no artigo como configurar um container. Listagem 1. Teste com o mínimo necessário do public class GerenciadorLivrosIT private GerenciadorLivros livros; public void avaliarlivrosemnotadevetervalorinicial() throws Exception { livros.adicionarlivro(new Livro( Senhor dos Anéis, A Sociedade do Anel )); livros.avaliarlivro( , 9f); Livro persistido = livros.getlivroporisbn( ); assertequals(float.valueof(9f), new public static WebArchive createdeployment() throws Exception { return ShrinkWrap.create(WebArchive.class, teste.war ).addclasses(gerenciadorlivros.class, Livro.class); / 16

3 Configurando o ambiente Para fins deste artigo, utilizaremos a IDE Eclipse, em sua versão Indigo, com os plugins m2e Maven Integration for Eclipse e Maven Integration for WTP, para integração com Maven. Através do Maven configuraremos todas as dependências e servidores que precisamos para nosso teste (ver seção configurando o Arquillian). O nosso cenário de teste é uma simples aplicação JEE 6 com um módulo EJB, um projeto JAR simples para armazenarmos entidades e nosso persistence. xml e um módulo EAR para agrupar os dois. A nossa aplicação não possui uma camada de visão, ela é uma prestadora de serviços, e para nosso teste vai possuir apenas um serviço, um CRUD de Clientes. Vamos considerar ainda que nossa aplicação possua uma camada DAO, implementada através de uma interface IClienteDAO e um serviço ClienteDAO, que implementa essa interface utilizando a API JPA. Lembre-se que o Arquillian não se limita a testes na camada de negócios ou persistência, mas pode ser utilizado para realizar testes entre todas as camadas de uma aplicação, como será mostrado. Nós iremos desenvolver o serviço ClienteDAO utilizando TDD, porém no lugar de um teste de unidade utilizaremos um teste de integração com JBoss Arquillian. E executaremos os mesmos em um servidor Glassfish Embedded, através do Eclipse e do Maven inserindo dados em um banco HSQLDB in memory. Vamos então ver como configurar o JBoss Arquillian no nosso projeto. Montando os projetos Para montarmos nossa simulação vamos utilizar um archtype do Maven, disponível em: google.com/p/open-archetypes. Com o Maven disponível no seu path vá para o diretório que deseja criar os projetos e digite a seguinte linha: mvn archetype:generate -DarchetypeCatalog= open-archetypes.github.com/maven-repo/snapshots/ archetype-catalog.xml Após todo o processamento necessário, o Maven solicitará uma opção numérica, selecione a opção 3. Informe como groupid MundoJ, e como artifactid mundoj-arquillian, dê um Enter na opção version e package e confirme as propriedades com um Y. O Maven irá gerar toda a estrutura que precisamos e além, essa é uma excelente forma de começar rapidamente novos projetos. Ficamos então com a seguinte estrutura de diretório: mundoj-arquillian \_ mundoj-arquillian-ear \_ mundoj-arquillian-ejb \_ mundoj-arquillian-util \_ mundoj-arquillian-web Vamos excluir o projeto web e renomear o projeto util para jar ficando mundoj-arquillian-jar. Esse projeto jar será o local onde vamos criar nossa entidade, e o projeto ejb o local onde iremos criar o nosso DAO. O projeto EAR não será utilizado neste artigo, mas vamos deixá-lo para fins de simulação de uma estrutura de projeto realista. Para desenvolver testes queremos o conforto de nossa IDE, e para tanto basta importarmos os projetos gerados para o Eclipse. Para tanto basta abrir o Eclipse, e clicar em File->Import->Existing Maven Projects, selecionar o diretório-raiz onde foram gerados os projetos e pronto, eles são importados e configurados para dentro do Eclipse. Configurando o Arquillian JBoss Arquillian não depende de nenhuma ferramenta de build ou gerência de dependência, podendo ser utilizado adicionando diretamente seus JARs. Mas a maneira simples e recomendada pela comunidade do Arquillian é utilizando a gerência de dependências do Maven e importando as dependências transitivas dele. Mas você ainda pode utilizar com qualquer outra ferramenta de build que deseje. Para seguir este exemplo você deve ter configurado o Maven 3. Na Listagem 2 você pode observar as dependências utilizadas no projeto. Tivemos que configurar o repositório do JBoss, para que as versões mais recentes possam ser usadas. O artefato arquillian-bom é um POM com as dependências necessárias do Arquillian que você pode importar para seu projeto. Aqui estamos utilizando JUnit, então o Arquillian possui um artefato (arquillian-junit-container) para fazer sua integração com ele. Fora isso, o que falta é definir qual adaptador de container utilizaremos. Como dito antes, há uma vasta quantidade de adaptares para containers como JBoss, Glassfish, Tomcat, Jetty, OpenEJB, Google AppEngine, Weld, entre outros. Seguem os tipos de containers que o Arquillian dá suporte: Containers Remotos: containers que já estão iniciados e os adaptadores do Arquillian utilizarão um cliente para se comunicar com eles. Através desse cliente, o Arquillian irá adicionar a aplicação, realizar os testes e desinstalar a aplicação. Ótimo para testar em servidores de aplicação completos que demoram a serem iniciados, já que você pode executar todos os Test Cases sem reiniciar o servidor.

4 Containers Gerenciados: são os mesmos que os containers remotos, mas são iniciados pelo próprio Arquillian, que permite a você especificar a localização deles para que ele cuide de toda a tarefa de gerenciar e testar através dos clientes. Containers Embutidos: são containers que podem ser iniciados dentro do código da sua aplicação através de uma API. Normalmente iniciam mais rápido por conter somente os recursos essenciais. Utilizaremos aqui o Glassfish Embedded, devido sua facilidade de uso. O que precisamos é do artefato arquillian-glassfish-embedded-3.1 que faz a integração com o GlasshFish e o próprio Glassfish Embedded, aqui sendo a dependência glassfish-embedded-all. Quando se está trabalhando com outros containers, basicamente são estas duas últimas dependências que variam. Listagem 2. Dependências do Arquillian e Glassfish Embedded. <project...> <groupid>br.com.mundoj</groupid> <artifactid>hotel-arquiliano</artifactid> <version>1.0</version> <packaging>war</packaging> <name>hotel Arquiliano</name> <dependencies> <groupid>org.jboss.arquillian</groupid> <artifactid>arquillian-bom</artifactid> <version>1.0.0.final</version> <type>pom</type> <scope>test</scope> <groupid>org.jboss.arquillian.junit</groupid> <artifactid>arquillian-junit-container</artifactid> <version>1.0.0.final</version> <scope>test</scope> <groupid>org.jboss.arquillian.container</groupid> <artifactid>arquillian-glassfish-embedded-3.1 </artifactid> <version>1.0.0.cr3</version> <scope>test</scope> <groupid>org.glassfish.extras</groupid> <artifactid>glassfish-embedded-all</artifactid> <version>3.2-b06</version> <scope>test</scope> <groupid>junit</groupid> <artifactid>junit</artifactid> <version>4.10</version> <scope>test</scope>... </dependencies> <repositories> <repository> <id>jboss-public-repository-group</id> <name>jboss Public Maven Repository Group </name> <url> groups/public/</url> </repository> </repositories>... </project> Desenvolvendo o teste Com as dependências definidas, precisamos de um DAO (Data Access Object) para nosso cadastro de clientes. Seguindo as práticas do TDD, vamos então criar o primeiro teste. No pacote br.com.mundoj. arquillian.dao, adicionaremos a classe ClienteDAO- Test. Vamos modificá-la adicionando a RunWith, e parametrizando essa anotação com o Arquillian.class. Também vamos aproveitar a injeção de dependência para adicionar nossa implementação de IClienteDAO na classe de teste, utilizando a Vamos criar nosso primeiro método salvando- ClienteValido que irá testar a inserção de um cliente com sucesso. A classe fica como exibido na Listagem 3. Listagem 3. Testando persistência de uma instância válida de cliente. package br.com.mundoj.arquillian.dao; public class ClienteDAOTest private IClienteDAO public static JavaArchive criandopacote() { return ShrinkWrap.create(JavaArchive.class, test.jar ).addclass(clientedao.class).addclass(iclientedao.class).addclass(cliente.class).addasmanifestresource( test-persistence.xml, ArchivePaths.create( persistence.xml )); public void salvandoclientevalido() { Cliente cliente = new Cliente(); cliente.setnome( Mundo J Cliente ); / 16

5 cliente.setendereco( Intenet Brasil ); cliente.setcpf( ); cliente.settelefone( ); clientedao.save(cliente); asserttrue(cliente.getid()!= null); Cliente persistido = clientedao.findbyid(id); assertnotnull(persistido); assertequals(persistido.getid(), cliente.getid()); assertequals( Mundo J Cliente, persistido.getnome()); assertequals( Intenet Brasil, persistido.getendereco()); assertequals( , persistido.getcpf()); assertequals( , persistido.gettelefone()); Montando pacotes com JBoss ShrinkWrap ShrinkWrap é um projeto independente, mas que anda junto ao Arquillian. Seu propósito é facilitar a montagem de pacotes através de código. Ou seja, se sua aplicação precisa gerar algum EAR, WAR ou JAR em tempo de execução, pode utilizar o ShrinkWrap, que provê uma interface muito intuitiva para adicionar classes, pacotes, arquivos de configuração, bibliotecas ou qualquer outro tipo de recurso necessário. Depois disso, é possível exportá-lo para o sistema de arquivos ou transformá-lo em um fluxo de bytes. O foco do Arquillian é minimizar o esforço para testar, e nada mais simplista do que montar pacotes somente com as classes que estão no contexto do teste. Deve-se notar, olhando para a Listagem 4, que devemos incluir todas as classes que vão ser utilizadas no teste, no nosso caso incluímos a interface IClienteDAO, sua implementação ClienteDAO e a entidade Cliente. Porém, caso a entidade Cliente possuísse algum atributo de uma classe específica, ou o método a ser testado fizesse uso de alguma classe além da Cliente, essa classe teria que ser inserida no deployment também. Não inserir todas as classes gera exceções no servidor de aplicação e impede a execução do teste. Você também pode manter arquivos de configuração padrões da sua aplicação separados dos arquivos de configuração personalizados para os testes. Na Listagem 4, adicionamos um persistence.xml no pacote, sendo utilizado como fonte o test-persistence.xml achado no classpath. Ter a opção de escolher qual descritor empacotar durante os testes permite que você configure recursos para substituir aqueles em produção, como qual datasource utilizar ou o nível de log da camada de persistência, por exemplo. Listagem 4. Método public static JavaArchive criandopacote() { return ShrinkWrap.create(JavaArchive.class, test.jar ).addclass(clientedao.class).addclass(iclientedao.class).addclass(cliente.class).addasmanifestresource( test-persistence.xml, ArchivePaths.create( persistence.xml )); ShrinkWrap resolver Uma pausa no passo-a-passo para falarmos do ShrinkWrap Resolver. Com a API do ShrinkWrap, já é possível abranger os cenários de testes mais comuns. Porém, há ocasiões nas quais é necessário adicionar ao pacote algum projeto externo como o driver JDBC de banco de dados ou biblioteca de log. Para estes casos, existe o ShrinkWrap resolver. Ele é capaz de adicionar aos seus pacotes personalizados de tempo execução, dependências descritas no seu pom.xml. Para utilizá-lo você precisa de mais três dependências no seu POM: org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-api org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-api-maven org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-impl-maven. A Listagem 5 mostra como obter uma instância de MavenDepencyResolver e adicionar o artefato que deseja ao pacote. Na linha 1, é recuperado o pacote seguindo o padrão groupid:artifactid:versão e na linha 2, o artefato é adicionado ao pacote como uma biblioteca. Listagem 5. Recuperando e adicionando dependências do pom.xml ao pacote. // Adicionando dependencias do Maven MavenDependencyResolver resolver = DependencyResolvers.use( MavenDependencyResolver.class); MavenDependencyBuilder dominio = resolver.artifact( br.com.mundoj:carrinho-dominio:1.0 ); //1 carrinho.addaslibraries(dominio.resolveas( GenericArchive.class)); //2 Usando o ShrinkWrap e o ShrinkWrap resolver para construir pacotes personalizados, permite mandar para o servidor de aplicações ou containers

6 somente as classes que interessam para o teste, diminuindo significativamente o seu tempo de deploy. Fazendo o teste compilar Voltando ao passo-a-passo, a nossa classe de teste nem sequer compila, tudo bem, segundo o TDD ela não deveria compilar mesmo. Agora é hora de buscarmos a compilação dessa classe através dos passos mais simples possíveis. Primeiro, vamos criar nossa entidade Cliente, com os atributos que precisamos para que o nosso teste compile. Como falamos no início, nossa aplicação utilizará JPA para persistência, e queremos que nossos testes realizem verdadeiras inserções no banco, sem objetos Mock. Para tanto, a entidade Cliente, da Listagem 6, ficará no nosso módulo de classe de domínio. Listagem 6. Classe que representa um public class Cliente implements Serializable private Integer id; private String nome; private String telefone; private String cpf; private String endereco; private static final long serialversionuid = 1L; //construtores, getters e setters omitidos Com essa entidade demos o primeiro passo para compilar nosso teste. Agora vamos criar o DAO que fará a persistência dessa entidade em um banco de dados. Seguindo as boas práticas de design o DAO é um serviço, e como tal deve ter uma interface que representa esse serviço. As interfaces EJB são interfaces comuns com um adicional que é a o que denota se a interface é local ou remota. No nosso caso vamos criar uma interface local. Vamos adicionar a nela e o método que precisamos. Nesse momento é comum querermos criar todos os métodos da interface, mas devemos nos lembrar do TDD, devemos criar apenas os métodos para fazer com que nosso teste compile. Sendo assim vamos criar os métodos save e findbyid. A interface deve ficar como exibida na Listagem 7. Listagem 7. Interface public interface IClienteDAO { public void save(cliente cliente); public Cliente findbyid(integer id); A interface ainda não compila já que Cliente e IClienteDAO estão em módulos separados. Para corrigir isso basta adicionar a dependência descrita na Listagem 8 ao POM.XML do projeto EJB, clicar com botão direito no projeto EJB, clicar em Maven -> Update Project Dependencies. Depois basta pedir ao Eclipse para organizar seus imports e ele deve adicionar a classe Cliente à lista de imports da interface IClienteDAO. Listagem 8. Dependência do Projeto JAR. <groupid>mundoj</groupid> <artifactid>mundoj-arquillian-jar</artifactid> <version>1.0-snapshot</version> <type>jar</type> <scope>provided</scope> Com a interface e a entidade criadas, nosso teste já compila, demos mais um passo no ciclo TDD. Vamos então executar nosso teste. Para tanto basta abrir a classe de teste no Eclipse, e clicar com o botão direito e selecionar Run As.. -> JUnit Test. Se observarmos o console, veremos que o teste nem mesmo chega a ser executado. Isso ocorre porque o Arquillian ainda precisa de algumas configurações para saber o que e como executar. Seguindo o nosso ciclo TDD essa é a fase do fazer o que for preciso para o teste aparecer verde. Iniciamos então a parte de configurar o Arquillian. Configurando recursos e containers A adição de recursos dentro do container como datasources, fábrica de conexões e filas ainda é um Um bom lugar para utilizá-lo sem o ShrinkWrap é em testes de container de servlets embutidos como o Tomcat e Jetty, que possuem uma API menos trivial para adicionar as classes e arquivos de descrição necessários para o teste. O ShrinkWrap também possui outro subprojeto, que recebeu o nome de ShrinkWrap Descriptors, onde você pode criar arquivos descritores, como beans.xml, web.xml e ejb-jar. xml, utilizando uma API trivial. O projeto ainda está em alpha e com pouca documentação, mas você pode seguir os testes do projeto encontrado no Github como referência para aprender e colaborar com ele. / 16

7 pouco confusa dentro do Arquillian, pois variam muito de container para container. Por exemplo, no momento em que este artigo é escrito, o adaptador que permite adicionar recursos de forma mais simples é para Glassfish embutido. Os adaptadores para outros servidores de aplicações, como JBoss remoto e gerenciado, ainda não possuem formas práticas para configuração de recursos em suas instâncias. Enquanto isso, o JBoss 7.1 permite que você adicione recursos através de descritores dentro do próprio pacote, adicionando-os ao META-INF. O Glassfish espera um glassfish-resources.xml com a descrição dos recursos que devem ser criados Para fazer o teste funcionar precisamos informar o datasource através do glassfish-resources.xml, e vamos colocar esse arquivo dentro do nosso diretório src/test/resources do projeto EJB, onde ficarão todos os recursos de configuração que vamos utilizar. A Listagem 9 mostra um exemplo de configuração de um datasource no Glassfish embutido. Listagem 9. glassfish-resources.xml. <resources> <jdbc-connection-pool name= mundojpool datasource-classname= org.hsqldb.jdbc.jdbcdatasource res-type= javax.sql.datasource ping= true > <property name= User value= sa /> <property name= Password value= /> <property name= databasename value= jdbc:hsqldb:mem:mundoj /> <property name= driverclass value= org.hsqldb.jdbcdriver /> <property name= PortNumber value= 9001 /> <property name= servername value= localhost /> </jdbc-connection-pool> <jdbc-resource jndi-name= jdbc/mundoj pool-name= mundojpool ></jdbc-resource> </resources> Precisamos dizer ao Arquillian onde se encontra o arquivo glassfish-resources.xml, fazemos isso criando o arquivo de configuração arquillian.xml, e colocando-o no diretório src/test/resources do projeto EJB. Um exemplo do conteúdo do arquillian. xml está detalhado na Listagem 9. Ele é um descritor onde se pode configurar tanto o funcionamento do Arquillian como dos adaptadores do container. Ele permite especificar a localização dos arquivos de configuração dos adaptadores, qual protocolo utilizar para se comunicar com o container, portas do container, qual adaptador utilizar por padrão, entre outras coisas. Na Listagem 10, estamos dizendo em qual arquivo o Arquillian deve ler as configurações de recursos (datasources, filas de mensageria, configuração de segurança) para adicionar no Glassfish Embutido. Listagem 10. Arquillian.xml. <arquillian xmlns= xmlns:xsi= XMLSchema-instance xsi:schemalocation= arquillian xsd > <container qualifier= glassfish default= true > <configuration> <property name= sunresourcesxml > src/test/resources/glassfish-resources.xml </property> </configuration> </container> </arquillian> E para finalizar a nossa configuração de conexão ao banco de dados, criamos um arquivo test-persistence.xml, referenciado nas listagens anteriores, no nosso src/test/resources, esse arquivo vai definir a nossa persistence-unit, e configurar o eclipselink (ou hibernate, OpenJPA etc.) para criar o banco assim que a aplicação for ao ar. Essa configuração é necessária, pois utilizamos um banco em memória, o HSQLDB, e que assim que nosso teste acabar ele some, levando consigo o nosso Schema bem como os dados de teste. O uso dos chamados in-memory database tem sido bastante interessante nos testes de integração. Acaba-se com a dependência de qualquer banco externo, ao mesmo tempo em que tem um custo de processamento bem menor. Após essas configurações, que serão utilizadas em todos os testes daqui para frente, vamos escrever a classe que falta, a implementação do serviço DAO, ClienteDAO. No módulo EJB, crie uma nova classe que será um bean de sessão como a Listagem 11. Nele é injetado um EntittyManager utilizado para persistir e procurar clientes por ID, por enquanto. Listagem 11. public class ClienteDAO implements EntityManager public void save(cliente cliente) { public Cliente findbyid(integer id) { Cliente cliente = em.find(cliente.class, id); return cliente;

8 Agora nós executamos o teste novamente, e vemos o verde novamente ser exibido. Deve-se notar que nesse momento nós já inserimos um dado no banco de dados, esse dado não pode ser verificado porque o HSQLDB vive apenas no período de execução do teste. Vamos então validar se o dado foi realmente inserido. Adicionando funcionalidade ao DAO Vamos ampliar nosso teste com um segundo método, o delete, que vamos utilizar para remover clientes do banco de dados. Para testar o delete nós precisamos primeiro inserir um registro, verificar sua inserção e depois excluir o mesmo e confirmar sua exclusão. Para isso vamos adicionar mais um método na nossa classe de teste o método deletandocliente- PersistidoSucesso, que é exibido na Listagem 12. Listagem 12. Testando remoção de cliente com sucesso. public void deletandoclientepersistidosucesso(){ Cliente cliente = new Cliente( João José Maria ); clientedao.save(cliente); Long clienteid = cliente.getid(); clientedao.delete(cliente); assertnull(clientedao.findbyid(clienteid)); Como estamos no começo do ciclo, o nosso código ainda não compila, vamos buscar compilar o método, para tanto precisamos adicionar o delete na nossa interface de DAO, como mostra a Listagem 13. Listagem 13. Interface IClienteDAO com método public interface IClienteDAO { public void save(cliente cliente); public Cliente findbyid(integer id); public void delete(cliente cliente); Com a adição do novo método, nosso código compila, mas ele não retorna verde. Nesse caso, o método mais rápido de fazer um verde ser retornado é implementando devidamente o método delete. Vamos então alterar nossa classe ClienteDAO para adicionar o método como na Listagem 14. Listagem 14. Implementação do método public void delete(cliente cliente){ em.remove(cliente); Quando vamos executar o nosso teste, eis que o Eclipse nos exibe uma surpresa, o teste retorna vermelho. Ao que tudo parece a nossa implementação está perfeita, nosso teste certamente está correto, no entanto recebemos uma exceção da camada JPA nos informando que a entidade que tentamos remover não está no contexto de persistência. Não precisamos ficar alarmados, essa é uma das grandes vantagens dos testes de integração, se tivéssemos feito um mock da classes da JPA, provavelmente não teríamos esse erro. O erro ocorre porque o objeto que estamos removendo não está no nosso contexto de persistência, sendo assim devemos modificar a implementação do nosso método delete para garantir que, caso o objeto não seja gerenciado, ele passe a ser antes de executarmos sua exclusão. O método delete em sua versão final está na Listagem 15. Listagem 15. Método delete versão public void delete(cliente cliente){ cliente = em.find(cliente.class, cliente.getid()); if (cliente!= null) { em.remove(cliente); Ao executarmos o nosso teste novamente, a barra verde aparece e podemos respirar aliviados. Deve-se Quando o container é iniciado Uma peculiaridade não muito boa do Arquillian relacionada à camada de persistência é o fato de que o container é iniciado uma vez a cada Test Case, como o método anotado do JUnit. Isto faz com que os testes do TestCase compartilhem suas alterações, e que a alteração de um teste, se não desfeita nos refletirá nos outros testes. Então sempre se lembre de desfazer as alterações dos testes, para que elas não interfiram, fazendo com que os testes subsequentes que deveriam passar, não passem. O agrupamento de Test Cases em Test Suites não modificará este comportamento, sendo um ciclo de start/deploy/undeploy/stop para cada Test Case (deploy/undeploy em casos de containers remotos). / 16

9 notar como o ciclo TDD para desenvolver o método delete foi consideravelmente menor do que o primeiro ciclo, isso porque já tínhamos todo o processo de configuração do ambiente integrado que estamos testando, resolvido. Pode-se notar, também, como foi importante nos valermos do ciclo TDD para criação do método delete, que apresentou um erro extremamente comum em implementações DAO que utilizam JPA, caso fosse um teste de unidade dificilmente esse erro teria sido identificado. Concluímos o nosso segundo ciclo TDD, como se pode notar o processo se torna rápido e intuitivo à medida que reutilizamos configurações e classes já testadas. Encerramos assim o desenvolvimento do nosso DAO, ele possui um método save, um método findbyid e um método delete. É claro que um DAO na vida real poderia possuir uma complexidade muito superior ao aqui apresentado, porém o foco do artigo era apresentar a ferramenta JBoss Arquillian dentro de um ciclo TDD de desenvolvimento. Testando com Arquillian Persistence Extension Fugindo um pouco do passo-a-passo apresentado nas sessões anteriores, criar uma suíte de teste para a camada de persistência ou para outras camadas que interajam com ela pode ser trabalhoso durante o processo de teste. Você precisa gerenciar o que está sendo colocado no banco para não se perder, já que os testes podem ser isolados, mas o banco de dados é compartilhado entre eles. Para agilizar a escrita destes tipos de teste, o Arquillian possui uma extensão chamada Arquillian Persistence Extension que ajuda a minimizar o trabalho necessário para interação com o banco e propõe algumas anotações que vão auxiliar em isolar cada teste do TestCase. Para utilizar o Arquillian Persistence Extension, basta adicionar sua API e implementação como dependências do Maven, de acordo com a Listagem 16. Listagem 16. Dependências para o Arquillian Persistence Extension. <groupid>org.jboss.arquillian.extension</groupid> <artifactid>arquillian-persistence-api</artifactid> <version>1.0.0.alpha4</version> <groupid>org.jboss.arquillian.extension</groupid> <artifactid>arquillian-persistence-impl</artifactid> <version>1.0.0.alpha4</version> Como você pode ver, a versão mais recente é a 1.0.0Alpha4, lançada em abril, e possui algumas inconsistências que podem variar um pouco até sua versão final. Esta extensão faz grande uso do DBUnit, possibilitando que você especifique scripts que irão executar antes e depois de cada teste. Você também pode adicionar DataSets no formato YML, XML e JSON. A Listagem 17 mostra um exemplo de DataSet com XML. O DBUnit permite você adicionar dados a várias tabelas a partir de um mesmo DataSet. Aqui estamos separando em arquivo para cada entidade, assim podemos escolher quais DataSets persistiremos para satisfazer o teste em questão. Mais a frente, você verá como o Arquillian permite que você escolha qual DataSet usar, através de anotações. O arquivo clientes.xml descreve alguns clientes que serão persistidos. O arquivo quartos.xml também descreve alguns quartos que serão persistidos e que poderão ser alugados pelos clientes. Listagem 17. DataSets para iniciar os testes. <!-- src/test/resources/datasets/clientes.xml --> <dataset> <cliente id= 1 nome= João José telefone= cpf= endereco= Rua 7 de Setembro /> <cliente id= 2 nome= Maira José telefone= cpf= endereco= Rua 15 de Novembro /> <cliente id= 3 nome= Roberto José telefone= cpf= endereco= Rua 13 de Maio /> </dataset> <!-- src/test/resources/datasets/quartos.xml --> <dataset> <quarto id= 1 numero= 12A andar= 2 diaria= /> <quarto id= 2 numero= 13A andar= 2 diaria= /> <quarto id= 3 numero= 14A andar= 2 diaria= /> <quarto id= 4 numero= 15A andar= 2 diaria= /> </dataset> Aqui estão algumas das anotações oferecidas pelo Arquillian permite a você escolher quando e o tipo de estratégia utilizada para limpar as alterações do banco a cada teste. Você pode escolher entre limpá-lo antes de o teste iniciar ou quando ele finalizar (TestExecutionPhase. BEFORE ou TestExecutionPhase.AFTER, respectivamente). É possível especificar o que será apagado, com as opções de apagar todo o banco, somente as linhas inseridas ou somente as tabelas permite a você especificar datasets que serão adicionados ao banco antes do teste em permite a você espe-

10 cificar como as tabelas sendo testadas devem se encontrar no final do você também pode executar qualquer script em seu banco antes de iniciar o teste. A Listagem 18 mostra um pouco da utilização do Persistence Extension. Diferente do passo-a-passo onde era injetado um EJB no teste, aqui estamos injetando o EntityManager diretamente no teste. Assim você pode testar se está utilizando o mapeamento corretamente nas classes de entidade, sem ter que escrever mais código para isso. O método adicionandoreservavalida possui duas anotações extras. A especifica que utilizaremos os DataSets dos arquivos clientes.xml e permite indicar o DataSet em que algumas tabelas do banco de dados devem se parecer depois que o teste for executado. Ou seja, a tabela de reservas deve ter os mesmos dados que o DataSet de reservas. Na segunda linha da Listagem 18 indicamos como o Arquillian irá restaurar a base de dados depois que o teste for executado. A limpeza será executada depois que cada teste for executado e irá truncar somente as tabelas alteradas pelo teste. Listagem 18. DataSets para iniciar = TestExecutionPhase.AFTER, strategy = CleanupStrategy.USED_TABLES_ONLY) public class ReservaPersistenciaIT public static JavaArchive criandopacote() throws Exception { return ShrinkWrap.create(JavaArchive.class, hotel-dominio.jar ).addpackage(reserva.class.getpackage()).addasmanifestresource(emptyasset.instance, beans.xml ).addasmanifestresource( test-persistence.xml, persistence.xml = hotel-pu ) private EntityManager clientes.xml, quartos.xml reservas-esperadas.xml ) public void adicionandoreservavalida() throws Exception {... Realizando testes fora do container Para escrever testes funcionais, utilizar o Arquillian também ajuda a diminuir o esforço. Por exemplo, você pode utilizar o ShrinkWrap para montar os pacotes personalizados, excluindo os arquivos css, html, javascript e imagens que não são necessários para o teste. Como mostra a Listagem 19, a possui um atributo testable que, quando setado para false, faz com que os testes daquele TestCase sejam executados na JVM onde os testes do JUnit ou TestNG foram iniciados, como se fossem clientes do container. Neste exemplo estamos gerando um pacote WAR com o ShrinkWrap e precisamos testar se a interface Web realmente está funcional. Então, adicionamos as classes do pacote br.com.mundoj.hotel e a página JSP formulário.jsp. A partir disso, o método adicionando- Reserva utiliza o Selenium WebDriver para navegar até a página correta e observar se o título da página é realmente o que esperamos que seja. Assim, o Arquillian pode ser utilizado para um propósito bastante diferente do que foi apresentado até aqui, que são os testes funcionais. O Arquillian em conjunto com Selenium, HtmlUnit ou JSFUnit, torna-o muito flexível para testes de interface, mas não vamos entrar em detalhes de como utilizar o Selenium, pois estenderia muito o artigo. Listagem 19. Executando testes fora do public class ReservasServletIT = false) public static WebArchive criandopacote() throws Exception { WebArchive pacote = ShrinkWrap.create( WebArchive.class, hotel-web.war ); pacote.addpackages(true, br.com.mundoj.hotel ); pacote.addaswebresource(new File( src/main/webapp/formulario.jsp ), formulario.jsp ); return pacote; public void adicionandoreserva() throws Exception { WebDriver navegador = new HtmlUnitDriver(); navegador.manage().timeouts().implicitlywait(10, TimeUnit.SECONDS); navegador.get( ); String titulo = navegador.gettitle(); assertequals( Gerenciamento de Reservas, titulo); Em casos mais específicos você pode misturar a execução de testes dentro e fora do container no mesmo TestCase. Como na Listagem 20, basta retirar o parâmetro testable da e uti- / 16

11 Arquillian + Maven Profiles Um recurso muito interessante que pode ser aproveitado do Maven é a configuração de diferentes profiles. Você pode criar um profile para cada container que deseja testar, e nele adicionar as dependências necessárias para cada um. Com o Arquillian, você será capaz de escrever testes que não são dependentes de um container específico. Seus testes ainda irão funcionar na sua IDE, basta que você configure qual profile deseja executar nas configurações dela. Tome cuidado, pois o Arquillian não permite dois adaptadores no mesmo classpath. lizar a para cada teste que deva rodar fora do container. Novamente utilizamos o WebDriver para navegar através da aplicação pela interface Web. Listagem 20. Teste executando fora do public void listarreservasfeitas() throws Exception { WebDriver navegador = new HtmlUnitDriver(); navegador.manage().timeouts().implicitlywait(10, TimeUnit.SECONDS); navegador.get( hotel-web/reservas?acao=listar );... Observe que os recursos disponíveis para os testes que rodam dentro do container não estão disponíveis para os testes marcados Desta forma se você utilizar as para realizar alguma tarefa entre os testes, você não terá acesso aos recursos que estariam presentes via injeção de dependência, nem neles, nem nos próprios testes out container. Considerações finais O TDD mudou a forma de programar, trouxe segurança e provou ao longo da sua década de existência oficial que o custo de desenvolver teste é muito menor do que o custo de erros em códigos não testado. O JBoss Arquillian simplificou a tal nível os teste de integração, como mostramos neste artigo, que podemos passar a inserir testes de integração no ciclo TDD, com grandes ganhos de segurança e produtividade no desenvolvimento de aplicações JEE. Ele obriga a ter um trabalho extra no início da implementação da suíte de testes, mas minimiza muito o esforço durante a escrita dos testes, gerenciado o ciclo de vida dos testes e dos containers envolvidos. Como você viu, ele ajuda a gerenciar o ciclo de vida dos testes e do container, podendo ser utilizado em testes de integração e funcionais. Junto com outros projetos como ShrinkWrap, permite que foquemos nas classes que realmente precisam ser testadas. Alguns dos projetos apresentados aqui, como o Arquillian Persistence Extension e o ShrinkWrap Descriptors, ainda se encontram em versão alpha. Sendo assim, podemos esperar muito deles nos próximos meses. Alguns pontos do Arquillian ficaram fora do escopo deste artigo, como deploys múltiplos, testes de grid, Arquillian Drone, entre outras coisas. Mas sinta-se à vontade para consultar as referências, ou aguarde os artigos das próximas edições. Consulte o artigo Testes Automatizados, publicado na edição 47 da revista MundoJ, para uma referência adicional sobre ferramentas utilizadas em automatização de testes. /referências Test Driven Development: By Example, Kent Beck, Addison- Wesley Longman, 2002, ISBN , ISBN Reference+Guide, Guia de referência do Arquillian. Arquillian Persistence Extension Alpha4 Released. guia inicial oficial do Arquillian. Wiki ShrinkWrap. Mocks are a Mockery, post sobre a utilização de Mocks. tutorial sobre Arquillian Persistence. exemplos de utilização do Arquillian. /para saber mais