aqui no meu atual projeto estamos usando JUnit para realizar os testes unitárioas mas na minha opinião eles não estão ficando bons.
O principal motivo que eu acho isso é que se eu estou num fluxo de cadastro, e vou testar a terceira tela desse fluxo, como eu resolvo o problema das dependências de banco com os módulos anteriores? Aqui os JUnits estão sendo criados assumindo que as informações de banco necessárias jah estão inseridas, logo são verificadas hardcode no Junit. Mas se um dia essas informações forem removidas do banco, pronto, o Junit para de funcionar.
Alguem pode me dar algumas dicas pra fazer um bom Junit? Na internet eu acho bastante material, mas nenhum falando de criação de Junit quando existem dependências de alguns registros jah estarem inseridos na base.
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.
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…
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.
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
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.
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.
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…
