Olá. Estou em um projeto em início e que vai utilizar Struts 1.3 :oops:
Alguem teria alguns exemplos de testes unitário para essa versão ?
Eu não uso essa versão do struts a anos e preciso de coisas que me ajudem a testar actions, fowards, etc.
Se for com versões mais atuais do JUnit será melhor ainda.
Edit:
Lembrei de outra questão.
Eu consigo testar, com o struts 1.3, sem precisar subir o servidor WebSphere ?
Obrigado
Olha TDD não tem nada haver com testes unitários, por incrível que pareça! rsrsrsrs
Acredito que você deseja realizar testes de aceitação e [ur=http://blog.caelum.com.br/testes-de-aceitacao-com-o-selenium/l]aqui[/url] tem uma boa introdução ao Seleniun com JUnit
Não amigo. Oq eu qro é fazer teste unitário pra testar meus métodos.
Eu qro fazer os testes automatizados antes de implementar por completo.
Selenium eu conheço e não é isso oq quero.
[quote=rogeriopaguilar]Tem o strutstestcase:
http://strutstestcase.sourceforge.net/
[/quote]
Eu fiz umas pesquisas antes de postar aqui e encontrei ele, mas não sabia se era recomendado, até por utilizar uma versão antiga do JUnit.
Acho que deve ter algo mais novo e mais recomendado, mas não sei…
Obrigado !
[quote=fdiaz2011]Não amigo. Oq eu qro é fazer teste unitário pra testar meus métodos.
Eu qro fazer os testes automatizados antes de implementar por completo.
Selenium eu conheço e não é isso oq quero.
[/quote]
De novo testes unitários não tem nada haver com TDD. Acredito então que você queira testar a “lógica do negócio” para isso é só usar JUnit e no máximo você vai precisar de Mocks para algumas classes. Talvez você esteja tendo problemas pois está colocando as as regras de negócio na camada de apresentação então para testar essas regras teria que usar Selenium ou algo similar. Se você não está fazendo isso não terá problemas pois as regras de negócios são independentes do framework adotado.
Eu não estou tendo problemas pq o projeto ainda nem começou rsrrsrsrs
E sim, qro testar as regras de negócio antes de implementá-las.
Escreva o teste, escreva o codigo que passe no teste e refatore.
Eu não tenho experiencia.
Nunca montei uma suite de testes pro Struts e não sei se terei problema.
Já montei pro Spring.
Tb não sei se conseguiria executar os testes com o struts sem precisar subir o websphere, antes.
[quote=fdiaz2011]Eu não estou tendo problemas pq o projeto ainda nem começou rsrrsrsrs
E sim, qro testar as regras de negócio antes de implementá-las.
Escreva o teste, escreva o codigo que passe no teste e refatore.
Eu não tenho experiencia.
Nunca montei uma suite de testes pro Struts e não sei se terei problema.
Já montei pro Spring.
Tb não sei se conseguiria executar os testes com o struts sem precisar subir o websphere, antes.[/quote]
Cara para testar as regras de negocio da aplicação você não precisa de ambiente algum! Realizo testes de unidade em todas as minhas classes de negócio fora de qualquer ambiente. Somente carrego o ambiente para os testes de integração e aceitação.
Você já usou TDD efetivamente?
Não tenho experiencia.
Eu já utilizei, mas bem pouco pq tinha alguns problemas.
Inclusive o problema q citei q na epoca precisava subir o JBoss pra que tudo funcionasse, mas acho q era devido a utilização de EJB e sem subir o servidor ele não injetava.
Era algo desse tipo.
[quote=fdiaz2011]Não tenho experiencia.
Eu já utilizei, mas bem pouco pq tinha alguns problemas.
Inclusive o problema q citei q na epoca precisava subir o JBoss pra que tudo funcionasse, mas acho q era devido a utilização de EJB e sem subir o servidor ele não injetava.
Era algo desse tipo.
[/quote]
Ai que tá, testes unitários não é a mesma coisa que TDD. Uma exigência de TDD é que os testes sejam rápidos (não que você não possa utilizar TDD para testes de aceitação e integração) de forma que carregar um ambiente não é o ideal para isso.
Como você está iniciando recomendo a leitura do livro do Kent Beck - Desenvolvimento Guiado por Testes. Foi com esse livro que eu realmente entendi o que é TDD.
A medida que você for se aprofundando, vai ver que vai precisar de Stubs ou hoje em dia de Mocks problemas de acoplamento.
O grande problema de testar o struts 1 é que ele não foi feito para ser testado. Você vai precisar de algumas ferramentas para te ajudar, sem as quais isso vai ficar impráticavel. Tem um framework o qual não lembro o nome que possui implementações de mocks para muitas classes antigas, incluindo as do struts 1, se você tiver paciência pra procurar vai valer a pena.
Não se preocupe tanto com tdd se o que você quer é que seu código seja testado. Você já está familiarizado com testes automatizados?
[quote=von.juliano]O grande problema de testar o struts 1 é que ele não foi feito para ser testado. Você vai precisar de algumas ferramentas para te ajudar, sem as quais isso vai ficar impráticavel. Tem um framework o qual não lembro o nome que possui implementações de mocks para muitas classes antigas, incluindo as do struts 1, se você tiver paciência pra procurar vai valer a pena.
Não se preocupe tanto com tdd se o que você quer é que seu código seja testado. Você já está familiarizado com testes automatizados?[/quote]
Opa !
Não seria esse ?
http://strutstestcase.sourceforge.net/
Eu já fiz testes automatizados sim.
Já trabalhei em sistema com Spring 3 q tinha teste sim e eu mesmo que implementei com JUnit e mockito.
Em um outro sistema q trabalhei não funcionava bem pq tinha q subir o servidor pra aproveitar coisas do ejb e ai os testes acabaram ficando de lado.
Não tenho a experiencia q gostaria, mas não sou totalmente leigo.
Só não consigo entender o que as regras de negócio tem haver com o Struts? Sempre que usei TDD nunca precisei me preocupar durante o desenvolvimento do dominio da aplicação com a camada de apresentação! No que struts afeta o dominio para que não seja possível realizar os teste usando somente JUnit?
[quote=fdiaz2011]Não seria esse ?
http://strutstestcase.sourceforge.net/ [/quote]
Não, o que eu usei era basicamente classes já implementados para facilitar os testes (tipo ActionMapping e ActionFoward) e não tinha ligação direta com o junit. Quebrava um bom galho.
[quote=fdiaz2011]Eu já fiz testes automatizados sim.
Já trabalhei em sistema com Spring 3 q tinha teste sim e eu mesmo que implementei com JUnit e mockito.
Em um outro sistema q trabalhei não funcionava bem pq tinha q subir o servidor pra aproveitar coisas do ejb e ai os testes acabaram ficando de lado.
Não tenho a experiencia q gostaria, mas não sou totalmente leigo. [/quote]
Esse negócio de precisar subir o servidor não é legal, não faça uso disso!
Eu crio também os controllers da aplicação também com tdd, e usando o struts 1 é esse o problema que ele vai ter. Não há problema com as regras de negócio.
Simples, o código do Struts 1 é intestável.
[quote=von.juliano]
Eu crio também os controllers da aplicação também com tdd, e usando o struts 1 é esse o problema que ele vai ter. Não há problema com as regras de negócio.[/quote]
Ok, mas se é só para testar a camada de apresentação, é possível fazer o mesmo com a utilização do Seleniun e JUnit, não? Embora seja lento para os padrões de TDD seria obtido os mesmos resultados!
Não, os controllers são testados com teste de unidade. Selenium é outra história.
Não, os controllers são testados com teste de unidade. Selenium é outra história.[/quote]
Mas qual a finalidade dos controllers nesses casos? Poderia dar um exemplo simples?
O Controller também tem comportamento, de modo que também deve ser testado. Veja um exemplo simples nesse link.