JUnit decente! Como fazer?

A ideia é vc fazer testar cada classe separadamente, e com as dependecias vc usar um Mock Objecte como por exemplo o Easy Mock http://www.easymock.org/

Os mock object criam objetos falso e controlam o compartamento esperado q vc programou.

Acho q isso vai te ajudar.

Outra opção é você ter uma cópia do banco para testes. Então, você usa o setup do JUnit para refazer os cadastros básicos e o teardown para apagar todos os dados.

Essa técnica tem a vantagem de validar os seus SQLs, coisa que o EasyMock não faz. O problema é que os testes ficarão um pouco mais lentos.

Se o seu cadastro ficar lento, você pode ganhar tempo deixando os JUnits um pouco menos unitários e inicializando e finalizando o BD uma só vez para cada classe de teste. Para isso, use os anotations @BeforeClass e @AfterClass em dois métodos estáticos, que serão usados como se fosse o setup e o teardown para classe.

também acredito que @BeforeClass e @AfterClass seja boa opcao para o seu caso.
Nao é bom fazer testes confiando que determinados dados estejam no banco pois assim fica dificil para alguem que queira baixar seu projeto e executar os testes, pois nesse caso acredita-se que o banco esteja em branco.
O ideal quando se usa o banco de dados em testes unitáios é que ao terminar o teste, o banco esteja no mesmo estado que estava antes do teste. Por isso o que o ViniGodoy disse sobre cadastrar os dados no @BeforeClass e apagar no @AfterClass é uma boa solução.

Teste unitário não usa banco de dados. Se usa banco de dados pode ser teste de qualquer coisa menos teste unitário. Pra teste unitário, use Mock.

Você pode usar o banco de dados pra fazer teste de integração, teste de interface…

[]'s

Rodrigo C. A.

Se você quiser testar a integração do seu sistema com o banco de dados pode usar o DBUnit para deixar o seu banco de dados no estado desejado antes de cada teste…

Não concordo com o rodrigo.

A grande vantagem de usar um banco de dados é a possibilidade de validar os seus SQLs durante o JUnit. Tanto que frameworks como o DBUnit e métodos como o @BeforeClass e @AfterClass foram criados com essa finalidade.

Do ponto de vista teórico, talvez ele esteja certo. Mas já diz a máxima: “Na teoria, a teoria funciona na prática. Na prática, não.”

O JUnit ainda tem alguns casos extremamente dolorosos, como testes de aplicações multi-threads, ou mesmo quando mocks são muito complexos de ser montados.

Aqui mesmo, começamos a programar mocks para simular comportamentos de algumas centrais telefônicas. Os mocks começaram a praticamente se tornar um sistema a parte, tão complexos que não valiam o esforço. Era muito mais fácil e futuramente descobrimos que menos sujeito a erros, usar as centrais verdadeiras.

Não estou dizendo que os Mocks não são importantes, são e muito. E devem ser usados na maioria dos casos. Só estou lembrando que existe um trade-off entre programar e manter um Mock e a facilidade de uso que ele traz.

ViniGodoy,

O Rodrigo não invalidou a idéia de criar testes usando o banco de dados, ele só afirmou que este tipo de teste com o jUnit não pode ser chamado de teste de unidade, o que é correto.

Veja, nada impede que se use o jUnit para fazer testes de integração com banco de dados, e estes são bem úteis, como você mesmo já sabe

Isso mesmo que eu quis dizer…

O Mock não existe pra simular um banco de dados ou uma central telêfonica, existe pra simular comportamento de classes. Por exemplo, não dá pra usar Mock pra testar classes DAO, não faz sentido, assim como normalmente não faz sentido fazer teste unitário de classe DAO. Mas faz sentido vc usar Mock que simula o comportamento das suas classes DAO pra fazer testes unitários das suas classes de BO.

Se o Mock está dando tanto trabalho, normalmente é pq ou ele está sendo usado no lugar errado ou a sua classe está fazendo muita coisa, então vale a pena dar uma refatorada. Realmente não dá pra usar Mock se a sua classe tiver milhares de dependências, e a boa prática diz que isso não deve acontecer.

[]'s

Rodrigo C. A.

Mas acho que vale ressaltar o que você disse:

Ou seja, normalmente não esperamos que um Mock seja complexo, mas isso pode acontecer, como foi nosso caso.

Aliás, tem muita discussão sobre usar ou não mocks para simular sistemas, fazer ou não JUnits para testar DAOs.

Na verdade, muita discussão parte de radicalismos, como soou a frase que eu disse que discordava - ou mesmo por brigas em cima de uma definição, que muitas vezes varia de autor para autor e que não é o foco principal do problema.

Creio que interpretei mal, nesse caso me desculpe. Afinal, aqui no texto não vemos nem entonação, nem os gestos de quem escreve.

Como eu falei, os Mocks são importantes. Use sempre que puder. Mesmo aqui onde trabalho o uso deles é muito comum, mesmo que nós tenhamos nossas exceções.

Valeu pela ajuda pessoal!

entendi bem o conceito, antes eu chamava tudo de teste unitário, e tbm muito legal as dicas passadas!

Valeu mesmo!

Voces sao felizes…
Eu nao consigo fazer seguer 1 teste =/
so na mao mesmo =/

Em que momento você tem dificuldade? Talvez possamos ajudá-lo…

Nao consigo entender o JUnit , gostaria de encontrar um lugar pra eu ler sobre o mesmo.
So que o dificil eh encontrar algo bom em portugues.

Tente começar com este artigo. Espero que ajude

Obs.: procurando no google por “junit site:.br” você vai encontrar mais coisas. E se você tem dificuldade com inglês, tente melhorar isso logo porque na área de informática ele vai ser fundamental…