BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Artigos Testes com Arquillian: Direto da fonte, com Dan Allen

Testes com Arquillian: Direto da fonte, com Dan Allen

Favoritos

O Arquillian é uma plataforma de testes funcionais e de integração, que pode ser usada para testar a camada de negócio em Java. Com o objetivo principal de tornar os testes de integração (e os funcionais) tão simples quanto escrever testes unitários, o Arquillian traz os testes para o ambiente de execução, o que libera o desenvolvedor do gerenciamento do ambiente de execução.

O Arquillian suporta a integração com containers Java EE como JBoss AS e Glassfish e containers de servlets como o Tomcat e o Jetty, além de suportar a execução de testes em serviços de cloud. É possível gerar aplicações para uma variedade de plataformas, incluindo Java EE 5 e 6, ambientes de servlets, OSGi, Embedded EJB e CDI standalone.

A equipe do Arquillian anunciou a liberação da versão 1.0.0.Final em abril e desde então tem trabalhando em várias melhorias. Algumas das funcionalidades incluem:

  • Orquestração de múltiplas publicações, através de múltiplos containers e controladores de domínio, em um mesmo teste;
  • Um novo esquema de configuração que suporta múltiplas configurações por container;
  • Avaliação similar à da Expression Language (EL) em propriedades; possibilidade de sobrescrever configurações via propriedades do Java;
  • Ordenação explícita de métodos de testes;
  • Controle detalhado sobre o ciclo de vida do container.

O InfoQ.com conversou com Dan Allen, contribuidor do Arquillian e engenheiro da Red Hat, sobre as funcionalidades do framework de testes, sua abordagem diferente de outras estratégias e futuras versões.

InfoQ: Em quais tipos de testes (unitário, de integração, funcional, desempenho, segurança) o Arquillian pode ajudar?

Dan Allen: O Arquillian chega aonde os testes unitários não alcançam; fornece uma plataforma para cobrir o restante dos tipos de testes possíveis. Assim que se inicia a integração dos componentes dentro do ambiente de execução, seja embarcado ou standalone, precisa-se de um serviço para controlar esse ambiente de execução. O foco principal do Arquillian é colocar os testes dentro do ambiente de execução e delegar para as extensões tarefas como: integração dos componentes; invocação dos serviços; navegação de páginas web; mensuração de características de desempenho; cobertura de código; execução de testes no cloud; entre outros. O Arquillian é um mecanismo de automatização de testes.

O Arquillian mostra como pequenas partes de testes unitários funcionam num contexto geral de testes; também demonstram como são inadequados o JUnit e o TestNG trabalhando sozinhos. É necessário estender uma classe base para um tipo de teste e outra classe base para outro tipo. O Arquillian organiza em um fluxo único diferentes serviços de testes (como Selenium, DBUnit e JaCoCo).

Se estiver sendo usado um modelo de programação como o CDI (ou Spring), é possível decidir usar o Arquillian para testar as unidades dentro de um serviço de container embarcado. Isso remover as diferenças entre os testes unitários e de integração. Mas isso é bom, porque permite focar no objetivo do teste e não em como é classificado.

InfoQ: Quais são os subprojetos do framework Arquillian?

Dan: O Arquillian não tem subprojetos em si. É organizado como um grafo de módulos, conectados com a plataforma principal. Esse agrupamento permite que as integrações venham de dentro ou de fora do próprio Arquillian. Na verdade, preferimos que os projetos hospedem suas próprias extensões do Arquillian, pois isso garante uma integração maior e permanece em sincronia com as versões desse projeto.

Há atualmente cinco tipos de módulos:

  • Adaptador de container;
  • Enriquecedor de testes (test enricher);
  • Executor de testes;
  • Extensão;
  • Suporte de ferramentas.

O Arquillian também se integra com os três módulos do ShrinkWrap: arquivos, descritores e resolvers.

Os adaptadores de container são os tipos de módulos mais comuns no Arquillian porque incluímos o suporte para todos os maiores containers Java (servidores) e no futuro alguns não Java. O projeto atualmente hospeda adaptadores para 12 containers diferentes, incluindo JBoss AS, GlassFish, Apache Tomcat, Jetty, WebLogic Server, Websphere AS; além de dois provedores de cloud: OpenShift e CloudBees. Há três estilos de gerenciamento (embarcado, gerenciado e remoto) para cada adaptador, cobrindo várias versões.

O outro módulo fundamental é o Arquillian Drone e o seu companheiro, o Arquillian Graphene. Essas extensões eliminam problemas de configuração e gerenciamento do Selenium, WebDriver e outros drivers de navegadores. Com o Drone, basta injetar a API do browser no teste e enviar os comandos para ela. Ao juntar a publicação com o controle do navegador, pode-se literalmente testar de ponta a ponta. O OpenShift anunciou a integração com o SauceLabs, que permite executar os testes do Arquillian através de plataformas dos navegadores dentro do Jenkins em execução na nuvem.

Uma extensão similar ao Drone é a extensão Android, que instala uma aplicação no dispositivo e controla a interface de usuário do Android, ao invés do navegador.

Dois módulos que estão surgindo e que acompanhamos de perto são a extensão Arquillian Persistence, que fornece controle declarativo e extensões para o DBUnit; e a extensão Arquillian Spring, que permite atualizar o framework de testes do Spring com o Arquillian e ganhar acesso a todas as extensões do Arquillian, especialmente o Drone. O Arquillian Spring está sendo desenvolvido como projeto "Summer of Code" do Google.

Por fim, o plugin para JBoss Forge do Arquillian é um módulo que fornece um ponto de entrada para a plataforma. Não há maneira mais simples de configurar o Arquillian no seu projeto: basta um comando e está tudo pronto.

InfoQ: Práticas de testes como BDD e TDD influenciaram o design do framework Arquillian?

Dan: Eu diria Práticas de testes como BDD, TDD e ATDD tiveram influência sobre o público-alvo e como o Arquillian foi projetado.

Queremos que desenvolvedores possam testar facilmente, efetivamente e com frequência. Desenvolvedores podem escrever uma bateria de testes unitários ou testes de integração que usam um ambiente de execução embarcado ou simulado (comportamento do carregamento de classes, visibilidade, sistema de arquivos), e depois descobrir que um suposição errada invalida tudo em que já se trabalhou. É necessário testar coisas reais,o que era assustador até agora, porque significava empacotar e publicar o projeto inteiro. Mas, ao deixar as micropublicações com o ShrinkWrap, é possível criar testes de integração focados, que servem como pontos de checagem ao longo do desenvolvimento.

Costumo dizer que o Arquillian é um ambiente de aprendizado em que é possível testar suas suposições ou entender o framework no ambiente de execução "verdadeiro", logo no início do processo de desenvolvimento. Chega a ser espantoso a rapidez que se aprende dessa maneira.

O Arquillian também suporta essas práticas de teste, por possuir integração com os frameworks de BDD e ATDD como o Spock, JBehave e Thucydides. Essa será a maior área de crescimento no próximo ano.

InfoQ: Já que o Arquillian fornece suporte para testar aplicações dentro do container, há algum risco dessa abordagem levar os desenvolvedores a não prestar atenção a práticas de design, como baixo acoplamento, isolamento e modularidade?

Dan: É verdade que o Arquillian coloca seus códigos de teste no container, permitindo se despreocupar com práticas de design, mas isso é contrabalançado pelo ShrinkWrap. Ao escrever códigos de teste, o desenvolvedor tem que conscientemente decidir o que colocar no arquivo de teste, o qual se tornará o microcosmo do teste (e por isso torna-se o escopo da visibilidade do classpath). Alguns desenvolvedores acham isso tedioso no inicio, mas logo reconhecem que fornecerá alto nível de isolamento para estudar de perto dependências entre classes e bibliotecas.

A possibilidade dos desenvolvedores de executar os testes num container de serviços embarcado, tal como o Weld Embedded, encoraja-os a evitar o acoplamento com o recurso do container, exceto na camada de fronteira. E embora seja possível usar o container embarcado durante o desenvolvimento, os desenvolvedores ganham a paz de espírito de saber que os testes estão sendo executados num container "de verdade", integrado continuamente.

Em resumo, o Arquillian e o ShrinkWrap se contrabalançam, mantendo o equilíbrio entre feedback e design de qualidade.

InfoQ: Quais são as limitações do Arquillian?

Dan: O gerencimento do classpath e a carência da modularidade no Java. Desenvolvedores muitas vezes encontram esses problemas ao escrever códigos de teste que executam dentro do container. As ferramentas Java (de build e IDEs) e ambientes de execução (servidores de aplicações) frequentemente descuidam do classpath ou não possuem outra opção. Como resultado, o desenvolvedor começa a encontrar problemas muito estranhos em tempo execução, que atribuem ao Arquillian ou ao ShrinkWrap. Mas na realidade a culpa é da ausência de modularidade no Java. Essa limitação é especialmente clara ao usar containers embarcados. Escrevi sobre esse problema recentemente no blog do Arquillian. Felizmente, a solução alternativa é bastante simples: usar um container gerenciado que executa em uma VM separada.

Outra limitação é a de usabilidade. Ainda é um pouco incômodo para os desenvolvedores trocar entre os diferentes adaptadores de containers, parte porque isso requer o uso de perfis de classpath, parte porque a configuração para seleção de containers não é inteligente o suficiente. Por enquanto, esses são alguns detalhes do Arquillian que o desenvolvedor precisa conhecer. Se os desenvolvedores lerem os guias do Arquillian, irão começar no caminho certo e não ficarão emperrado nessas questões.

InfoQ: O que está previsto para o futuro em funcionalidades e melhorias?

Dan: O que não está? O Arquillian segue uma cultura da inovação e imaginação. Para se ter uma ideia do que pensamos para o futuro, veja as ideias de projetos que a equipe propôs no programa Google Summer of Code 2012. Essa lista apresenta uma boa noção de para onde vamos. Aqui estão alguns itens:

  • Spring beans e teste de MVC;
  • Comparação visual automática de telas do navegador a partir de um teste;
  • Automatização testes de JavaScript;
  • Testes de persistência mais poderosos;
  • Redeploy à quente de classes e recursos, usando o JRebel;
  • Controle facilitado sobre a montagem da publicação melhorando os descritores e resolvers do ShrinkWrap;
  • Suporte a servidores não Java, como o Apache HTTPD;
  • Usabilidade.

O leitor interessado pode verificar os guias, que foram criados exclusivamente para levá-los de um workspace vazio até a primeira barra verde com o Arquillian.


Sobre o entrevistado

Dan Allen é um defensor do código aberto, catalisador da comunidade, autor e palestrante. Atua como engenheiro de software na Red Hat, servindo como ligação com a comunidade JBoss. Contribui com diversos projetos da comunidade JBoss, incluindo o Arquillian, ShrinkWrap, Seam 3 /DeltaSpike e JBoss Forge, além de participar do JCP em nome da Red Hat. Dan é autor do Seam em Ação (Manning, 2008), escreve para o developerWorks da IBM, e para a revista NFJS e JAXenter. Palestrante reconhecido internacionalmente, está presente nas maiores conferências de software, incluindo JavaOne, Devoxx, NFJS, JAX e Jazoon.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

BT