Olá, gostaria de saber como posso implementar testes em uma aplicação j2ee de forma fácil, rápida e eficiente.
Um abraço, obrigado. 
Marcio,
Aconselho a compra esse livro (link abaixo). Ele aborda um capítulo inteiro sobre testes com JEE (nos tópicos contam: JPA, EJB, JTA, JNDI,MDBs, entre outros). E é claro que o livro tem muita coisa boa. Garanto que você vai gostar do TESTNG.
Atualmente uso o Jboss Microcontainer / Embeddable EJB3 como ambiente para testes automatizados. O ruim é que é lento. Um único teste pode demorar até 20 segundos para rodar (precisa da infra EJB). Irrita bastante.
Pq demora tanto? Ele sobe o servidor para cada teste que faz?
Exatamente! Quer saber a verdade? Tô quase migrando tudo para o Spring só por conta dessa chateação com os testes. Só não faço isso porque sei que essa infra-estrutura toda ajuda a fazer testes mais integrados com o Jbpm.
Tem uma outra alternativa que é injetar o entityManager (modo local) na mão, mas não é viável para todos os testes e você precisa ficar gerando setEntityManager(manager) em tudo quanto é lugar para fazer um teste automatizado de integração.
Acho que só para iniciar o EntityManager são uns 10 segundos.
Mas que tipo de testes vc quer? Caixa branca, caixa preta?
[quote=rodrigoy]Exatamente! Quer saber a verdade? Tô quase migrando tudo para o Spring só por conta dessa chateação com os testes. Só não faço isso porque sei que essa infra-estrutura toda ajuda a fazer testes mais integrados com o Jbpm.
Tem uma outra alternativa que é injetar o entityManager (modo local) na mão, mas não é viável para todos os testes e você precisa ficar gerando setEntityManager(manager) em tudo quanto é lugar para fazer um teste automatizado de integração.
Acho que só para iniciar o EntityManager são uns 10 segundos.
[/quote]
Hmmm…
eu tb fazia fazia testes setanto os EntityManagers e os códigos dos JUnits ficavam mbastante confusos, principalmante quanto um componente dependia de outro. Até pensava que o JBoss Microcontainer pudesse me ajudar a deixar os testes mais bonitos, mas depois do que vc falou…
Que tal usar uma instância de JBoss com Maven/Continuum fazendo deploys/testes de cada componente?
Que diferença faz? A infra-estrutura tem que estar lá de qualquer jeito!
[quote=Taz]
eu tb fazia fazia testes setanto os EntityManagers e os códigos dos JUnits ficavam mbastante confusos, principalmante quanto um componente dependia de outro. Até pensava que o JBoss Microcontainer pudesse me ajudar a deixar os testes mais bonitos, mas depois do que vc falou…[/quote]
Realmente ficam mais bonitos, mas ao custo de 10-20 segundos para cada rodada de teste. Nesse quesito o pessoal da Jboss está deixando a desejar. O pior no meu cenário é que uso o Seam, e o Seam depende de infra-estrutura EJB. Isso fere muito a estratégia TDD. Teste unitário é até fácil, pois tudo é POJO, mas teste de integração está penando.
Não conhecia essa ferramenta, interessante, mas de qualquer forma ela não ajuda diretamente no problema que é o ciclo TDD (escrever um teste, falhar, passar, escrever um teste, falhar, passar - isso costuma ocorrer umas 10 vezes por hora, perco então uns 150 a 200 segundos por hora, sentí saudades do Spring, nesse aspecto).
O Maven é uma ferramenta de automação / controle de repositórios e o Continuum é uma ferramenta para integração contínua (equivalente ao Cruise Control, porém melhor integrado com Maven). Realmente, eles ajudariam na automação e padronizão dos projetos, mas não na redução do tempo gasto nos ciclos.
Como vc faz!? Vc aplica testes unitários + testes de integração a cada ciclo?
[quote=Taz]
Como vc faz!? Vc aplica testes unitários + testes de integração a cada ciclo?[/quote]
TDD não é teste, é desenvolvimento, vc deve saber isso, certo?
Estou adotando uma tática mais focada em TDD exatamente porque está demorando muito colocar servidor no ar e navegar na aplicação para testar/debuggar os casos de uso. Minha aplicação é baseada no Jbpm, então, para testar determinadas partes da aplicação preciso literalmente camelar dentro dela pra chegar aonde eu quero. Por exemplo, para conseguir testar um pedido de compra preciso:
- Criar uma Lista de Materiais (LM)
- Aprovar a LM
- Criar uma Autorização de Fornecimento (AF), baseada na LM
- Emitir a AF
- Criar o Pedido de Compra (PC) baseado na AF.
(é um sistema de gerenciamento de projetos de engenharia).
Esses passos demoram bastante, e toda hora preciso repetí-los para testar o Pedido de Compra. Certas alterações necessitam reiniciar o servidor (como uma mudança de assinatura de método, como exemplo).
Com o TDD, posso fazer testes por fora do servidor de aplicações: faço classes de testes concentrados nas minhas façades para chegar ao passo 5, aí são mais classes de testes para fazer o Pedido de Compra funcionar (uso o TestNG). Depois que está OK integro com a página XHTML. O passo “adicionar um teste” pode ser um teste unitário também. Muitas vezes aplico isso quando tenho uma busca mais complexa no meu repositório/DAO. Testes unitários também são aplicados em comportamentos das entidades usando Mocks.
Uma das características que não dava muita importância no TDD mas agora estou dando é exatamente perder menos tempo com debugging. Para falar a verdade, nesse meu último caso de uso não precisei de nenhum “breakpoint” para colocá-lo no ar. Debugar dentro de servidor de aplicação é um trabalho frustrante. HotDeploy tem muitas limitações.
(talvez essa experiência vire artigo)
O pior mesmo é que agora que estou aprendendo mais a fundo o Rails, vejo que uma infraestrutura mais simples ajuda muito o desenvolvimento. O TDD é mais fácil pois o ciclo fica mais rápido. É mais rápido ter feedback. No Java, volta e meia precisamos reiniciar servidor. No meu Pet Project no Rails faz quase 1 semana que o server está no ar. É só dar refresh no browser, mesmo quando altero o banco de dados.
Entendi, vc está testando o processo (testes de integração), daí a demora.
Já vi duas abordagens para o seu caso:
-
fazer como vc fez.
-
preparar uma base com o estado do passo 4, para testar o passo 5. Acho que esta não funcionaria pq vc tb precisa que estado do seu processo (Jbpm) tb esteja no passo 4. Mais fácil 1).
Olá Rodrigo …
Usando TDD, é possível modelar como deve ser o comportamento de suas “Unit of Works” com base somente nos unitários, correto? Não bastaria você utilizar um Selenium da vida para os testes de integração/aceitação depois de aplicado os unitários e feito o código funcional?
Eu deixei de utilizar o JBossMicrocontainer por alguns bugs eternos do Jira, que impediam que modelasse a estrutura de meu projeto da forma que eu gostaria.
[quote=rodrigoy]
Que diferença faz? A infra-estrutura tem que estar lá de qualquer jeito![/quote]
Depende do caso… De qualquer maneira, existem ferramentas diferentes para cada tipo de teste, que possuem esquemas para montar a “infra-estrutura” de forma diferentes.
http://www.faqs.org/faqs/software-eng/testing-faq/section-13.html
[quote=Taz]
- preparar uma base com o estado do passo 4, para testar o passo 5. Acho que esta não funcionaria pq vc tb precisa que estado do seu processo (Jbpm) tb esteja no passo 4. Mais fácil 1).[/quote]
Exatamente! Esse é o problema. Até daria para montar esse estado, mas o banco do JBPM é complexo. Alguém conhece uma ferramenta que “chupinha” o banco e gera os inserts?
Eu utilizarei o selenium para gravar os testes de aceitação e regressão, mas não para integração. Acho os scripts de gravação muito ruins de manter. Prefiro fazer os testes de integração concentrando o máximo que der no código. Dá uma segurança maior e ganho tempo no debugging.
É… tô passando por isso também… fórum é para essas coisas. O pior é que o que a gente quer de fato é ridículo. É só montar um EntityManager RESOURCE_LOCAL e injetá-lo juntamente com os @EJB e @In que surgirem pelo caminho. Injetar na mão dá uma estrutura boa para o projeto, mas dá muito trabalho trabalho e é bem irritante!
Como você está fazendo testes aí? Só testes unitários com Mocks?
Rodrigo,
não sei a complexidade dos seus dados, mas o DbUnit nesse caso não te ajudaria a criar o estado da base necessario?
[]´s
[quote=jgbt][
Rodrigo,
não sei a complexidade dos seus dados, mas o DbUnit nesse caso não te ajudaria a criar o estado da base necessario?
[]´s
[/quote]
Pode ser uma opção. Atualmente tenho usado o dump do TransferTool do HSQLDB. O efeito é o mesmo. De qualquer forma, não sei se o DbUnit vai conseguir exportar estado do Jbpm. Talvez isso seja uma opção, ao menos para restaurar estado.
[quote=rodrigoy][quote=jgbt][
Rodrigo,
não sei a complexidade dos seus dados, mas o DbUnit nesse caso não te ajudaria a criar o estado da base necessario?
[]´s
[/quote]
Pode ser uma opção. Atualmente tenho usado o dump do TransferTool do HSQLDB. O efeito é o mesmo. De qualquer forma, não sei se o DbUnit vai conseguir exportar estado do Jbpm. Talvez isso seja uma opção, ao menos para restaurar estado.
[/quote]
Vou dar um pitaco. 
Não sei sua aplicação está componentizada, mas, se estiver, vc pode fazer o seguinte:
Início Ciclo
Fazer até passar
Testes unitários com o componente sendo alterado e com a base preparada para cada teste (DBUnit).
Fim Fazer
Fazer até passar
Testes de integração com Selenium (será que a manutenção dos scripts é realmente complicada!? Pode ser que vc codifique bem menos scripts em comparação com os códigos do TestNG).
Fim Fazer
Atualizar repositório
Fim Ciclo
Que acha?
Estamos em processo de desenvolvimento do ambiente de testes com o Seam, Rodrigo. Atualmente, pra valer mesmo, apenas jUnit4.3, EasyMock e DBUnit estão bem definidos (que na verdade já era definido antes).
Desconsiderei o TestNG (que seria a escolha mais obvia por sua integraçao com o Seam), pq sua escolha seria atrelada aos testes de integração com o JbossMC, o que não estou fazendo por conta dos Bugs que citei. Portanto não teria ganho nenhum e optei por continuar com o JUnit.
Estou avaliando executar integração Contínua com o Cruise Control, com algum plugin Fit para Wiki e aceitação (possívelmente o Fitnesse) mas ainda não esta no ambiente.
O Selenium vai entrar no plano de testes com a interface do usuário, estabelecendo o final da integração.
Meu sprint esta cheio, e até agora a integração não esta pronta no ambiente por falta de tempo e dedicação… pelo menos ainda resta os unitários …