De que se trata o artigo:

Neste artigo será descrito como testes de unidade e integração podem ser construídos para aplicações Java baseadas na tecnologia EJB 3.0. Será utilizado o EJB3Unit, um framework de testes que abstrai a dependência de um container para a execução de componentes EJB.

Em que situação o tema útil:

Conjugar os benefícios advindos do desenvolvimento de aplicações que lançam mão da tecnologia EJB, com demandas de garantia de qualidade em prazos cada vez mais restritos constitui um contexto onde a utilização do EJB3Unit tem seu ponto forte.

Resumo DevMan:

A crescente necessidade por serviços advindos de aplicações corporativas tem demandado das equipes de desenvolvimento soluções de qualidade que agreguem valor às organizações em prazos cada vez mais restritos. A prática de testes ágeis surge como mecanismo de garantia desses requisitos. Porém, conjugar os benefícios de tecnologias para soluções corporativas, como o EJB 3.0, com a agilidade de garantia da qualidade constitui um desafio. Neste cenário, apresentaremos como o framework EJB3Unit pode ser usado para dar suporte às equipes de desenvolvimento nas atividades de testes unitários e de integração de componentes EJB 3. Nessa abordagem, os testes serão construídos sem a necessidade de um container EJB para execução.

O contínuo avanço do crescimento tecnológico tem encabeçado um aumento proporcional da expectativa dos usuários sobre os serviços de Tecnologia da Informação (TI). Somado a isso, organizações estão cada vez mais dependentes dos serviços corporativos de TI. Notadamente, estes continuam a abranger a maior parte do mercado [5].

Segundo Fowler et al. [7], aplicações corporativas, em geral, apresentam características específicas:

Dados persistentes: Precisam estar disponíveis entre múltiplas execuções do programa – de fato, normalmente precisam persistir por vários anos. Além disso, durante este tempo muitas alterações são esperadas tanto por parte dos programas que usam os dados quanto das estruturas para manipulação dos mesmos. Tudo isso para possibilitar o armazenamento de novas informações sem efeitos colaterais sobre as já existentes;

Grande quantidade de dados: Um sistema moderado terá mais de 1 GB de dados organizados em dezenas de milhões de registros. A gerência desses dados constitui parte importante do sistema;

Concorrência de acesso aos dados: Em geral, muitos usuários acessam os dados concorrentemente. Com uma multiplicidade ampla de acessos, é preciso assegurar que todos possam fazê-lo adequadamente, além de garantir que dois usuários não acessem os mesmos dados ao mesmo tempo de uma forma a comprometer o funcionamento seguro do sistema;

Interface com usuário: A grande quantidade de dados não raro demanda uma grande quantidade de telas diferentes para lidar com eles. Os usuários das aplicações corporativas vão desde os ocasionais àqueles que as usam com regularidade sem, contudo, ter conhecimento técnico aprofundado. Logo, os dados precisam ser apresentados de várias formas diferentes para atender a diferentes objetivos;

Interação com outras aplicações: Aplicações corporativas raramente vivem isoladas. Frequentemente elas precisam interagir com diversos outros sistemas, os quais foram construídos em épocas diferentes com diferentes tecnologias e até mesmo com mecanismos de colaboração diferentes: arquivos de dados em COBOL, CORBA, sistemas de mensagens, etc.;

Lógica de Negócio: Uma aplicação corporativa precisa automatizar um conjunto aleatório de condições que, via de regra, interagem umas com as outras de forma não-intuitiva. Naturalmente elas são uma tradução do negócio atendido pela aplicação. Contudo, essa representação do negócio precisa ser organizada de forma eficaz e, sobretudo, com a premissa de sofrer mudanças com o decorrer do tempo.

Sob a perspectiva das características supracitadas, portanto, o grau de complexidade inerente às aplicações corporativas tende a impactar no esforço de resposta das equipes de desenvolvimento. Contudo, à medida que se acirra a competição de mercado, desenvolvedores se vêm confrontados com demandas de desempenho e qualidade que se tornam cada vez mais críticas [5]:

Velocidade de entrega: Clientes, por não ficarem restritos a um único fornecedor, pressionam por entregas rápidas a fim de terem suas necessidades atendidas. Ademais, entregas para propósitos mais amplos podem angariar sucesso somente se foram liberadas no prazo correto, isto é, antes dos concorrentes de mercado;

Flexibilidade do produto: Como descrito na Tabela 1, 50% de todo custo envolvido no ciclo de vida de um software é gasto em atividades de manutenção. A vasta maioria das manutenções é devido a mudanças de requisitos. Logo, a redução dos custos implica no aumento da flexibilidade do software.

IBM Research Institute

Análise

17%

Codificação

8%

Testes

25%

Manutenção

50%

Tabela 1. Custos do ciclo de vida de uma aplicação.

Em virtude dessa necessidade de conjugar a complexidade de projetos de aplicações corporativas com a obtenção da qualidade num curto espaço de tempo, a prática de testes ágeis se apresenta como estratégia para o atendimento dessa dicotomia.

Nesse contexto, será descrito, a seguir, o framework EJB3Unit sob a perspectiva da construção de testes ágeis para aplicações desenvolvidas sobre a arquitetura de componentes Java Enterprise Edition (Java EE). Será utilizada uma pequena aplicação EJB a fim de se obter um melhor detalhamento do uso do framework.

EJBs e Testes Ágeis

Enterprise JavaBean (EJB) é uma arquitetura de componente do lado do servidor que simplifica o processo de construção de aplicações distribuídas da classe corporativa baseada em componentes Java. O EJB torna possível a escrita de aplicações seguras, confiáveis e escaláveis valendo-se de uma infraestrutura distribuída pré-escrita fornecida pela indústria. Foi projetado para suportar portabilidade e a capacidade de reutilização de aplicações entre serviços de middleware corporativos de qualquer fornecedor [8].

Aplicações construídas utilizando-se a arquitetura baseada em EJB requerem um servidor de aplicação para fornecer o ambiente de execução e prover serviços de infraestrutura padronizados para facilitar tanto o desenvolvimento como a implantação. A Figura 1 descreve a arquitetura Java EE da qual a especificação EJB é parte constituinte.

Apesar de o container EJB simplificar aspectos não-triviais de uma aplicação corporativa-distribuída, a execução de testes de software sobre esta plataforma, desde os estágios iniciais do processo de desenvolvimento, tende a se tornar uma atividade não-ágil. Evidência disto está na implementação dos testes de unidade que demandam uma abstração do container, ao passo que há a necessidade de emulação do mesmo a fim de se possibilitar a garantia da integração contínua.

Nesse contexto, as categorias propostas pelo quadrante de testes ágeis – Figura 2 – constituem uma possível divisão e priorização das atividades de testes a serem aplicadas na busca pela qualidade de uma aplicação corporativa. Na visão apresentada por esse quadrante, os testes estão agregados em quatro grandes grupos [6]:

Quadrante 1: Correspondem aos testes unitários e de componentes. Focados na arquitetura do sistema e no suporte à equipe são, essencialmente, de responsabilidade dos próprios desenvolvedores;

...

Quer ler esse conteúdo completo? Tenha acesso completo