Como testar meu DAO?

Virtual Machine Man Membro desde: 07/07/2008 13:10:41 Mensagens: 606 Offline

Estou começando um projeto e gostaria de aplicar TDD.

Dentro do meu modelo, consigo testar tranquilamente com JUnit, mas quando chego no meu DAO não sei como testar.

Como posso fazer para testar os métodos do meu DAO?
Por exemplo, tenho um método específico que vai buscar todos as entidades que foram criadas nos últimos 10 dias. Gostaria de testar este método.

Dei uma olhada no HibernateMock, ele é realmente a melhor opção? Existem outras opções?

GUJ Ranger Membro desde: 12/02/2009 08:40:06 Mensagens: 783 Offline

É simples: você só deve ter dados de mentirinha que correspondam a sua regra, assim você vai conferindo se eles estão sendo retornado pelos métodos do DAO.

Por exemplo, eu não faço mais isso, mas antes eu constumava fazer algo do tipo:

hard coded mesmo, era chato para métodos mais específicos, como esse seu.

Agora sobre o Hibernate mock, eu também gostaria de saber, por isso estou respondendo #up.

OBS: Com TDD você escreve teste antes de qq código (só não sei se o pessoal faz isso na prática e tals)

This message was edited 1 time. Last update was at 12/04/2011 22:27:34

Nykolas Lima wrote:
Como posso fazer para testar os métodos do meu DAO?

Aqui usamos hsqldb ou entao o mysql mesmo com rollback ao final do teste.
No caso so hsqldb ele cria toda a estrutura do banco usando hibernate.
Depois disso inserimos alguns valores no banco e finalmente executamos uma busca.

Nykolas Lima wrote:
Por exemplo, tenho um método específico que vai buscar todos as entidades que foram criadas nos últimos 10 dias. Gostaria de testar este método.

Algo do tipo:

Apenas para dar uma ideia do que voce pode testar e em que direcao voce pode ir.
Boa sorte!

Cara,

Eu costumo testar DAOs usando o DBUnit. Com ele, você garante que seu banco de dados de teste estará sempre em um estado conhecido na hora de executar os testes, e você não precisa ficar se preocupando em dar rollback no final dos testes.

pango wrote:
Cara,
Eu costumo testar DAOs usando o DBUnit.

Nao sou muito fa do DBUnit, odeio ter que ficar criando uma porrada de XML.

pango wrote:
Com ele, você garante que seu banco de dados de teste estará sempre em um estado conhecido na hora de executar os testes, e você não precisa ficar se preocupando em dar rollback no final dos testes.

Voce pode garantir o mesmo com HSQLDB - e sem a porrada de XML.
Na verdade o DBUnit usa HSQLDB e alimenta o banco atraves dos arquivos XML, nos fazemos isso via codigo.
Foi o que eu entendi do "GetStarted" do DBUnit ( li a alguns anos atras bem por cima, nao tenho 100% de certeza.

)

Pra deixar claro, executamos "rollback" apenas quando testamos contra mysql.

Eu uso o Hibernate com uma propriedade no arquivo de configuração para limpar o banco toda vez que criar uma nova session factory. Então, no @BeforeClass ou @Before de cada teste crio uma nova session factory. Para garantir que o banco estará limpo e os testes consistentes. Então, faço a inserção dos dados via código semelhante a maneira que o keller mencionou.

keller wrote:

pango wrote:
Cara,
Eu costumo testar DAOs usando o DBUnit.

Nao sou muito fa do DBUnit, odeio ter que ficar criando uma porrada de XML.

pango wrote:
Com ele, você garante que seu banco de dados de teste estará sempre em um estado conhecido na hora de executar os testes, e você não precisa ficar se preocupando em dar rollback no final dos testes.

Voce pode garantir o mesmo com HSQLDB - e sem a porrada de XML.
Na verdade o DBUnit usa HSQLDB e alimenta o banco atraves dos arquivos XML, nos fazemos isso via codigo.
Foi o que eu entendi do "GetStarted" do DBUnit ( li a alguns anos atras bem por cima, nao tenho 100% de certeza. )

Pra deixar claro, executamos "rollback" apenas quando testamos contra mysql.

Keller,

Você tem razão no que diz, mas eu acho que você consegue uma legibilidade muito maior do estado do banco de dados olhando um XML do que olhando uma pancada de linhas de código com statements.

Ah, e você pode usar o DBUnit com qualquer banco, não somente o HSQLDB.

This message was edited 2 times. Last update was at 13/04/2011 20:38:26

Segue minha observação..
Cuidado ao usar testes em bancos de dados quando for fazer TDD, principalmente se for teste de unidade.. imagine vc roda um junit e esquece que esta apontando para a base de produção e simplesmente ele insere, apaga, altera um dado de produção..
Eu não costumo usar testes de dados de bancosdedados, pois não faz sentido para mim. principalmente se tiver usando um framework de persistência como hibernate, se quiser testar baixe o código do framework e execute o testes do próprio framework e não crie um na sua aplicação.
Lembrando que muita gente usa Teste unitarios de um jeito errado(testa select, dados, coisas sem logica, criação de arquivos..) quando vc poderia fazer o mesmo simplesmente com um objeto fake('Mock') e + uma ponto de teste de unidade(JUnit,...) é q nunca deve fazer chamada externas (IO, Banco de Dados ... )

Virtual Machine Man Membro desde: 07/07/2008 13:10:41 Mensagens: 606 Offline

Valeu pelas respostas, vou dar uma olhada em como testar com hsql. E com HibernateMock, alguém já teve experiência com ele?

Priuli wrote:Segue minha observação..
Cuidado ao usar testes em bancos de dados quando for fazer TDD, principalmente se for teste de unidade.. imagine vc roda um junit e esquece que esta apontando para a base de produção e simplesmente ele insere, apaga, altera um dado de produção..
Eu não costumo usar testes de dados de bancosdedados, pois não faz sentido para mim. principalmente se tiver usando um framework de persistência como hibernate, se quiser testar baixe o código do framework e execute o testes do próprio framework e não crie um na sua aplicação.
Lembrando que muita gente usa TDD de um jeito errado(testa select, dados, coisas sem logica, criação de arquivos..) quando vc poderia fazer o mesmo simplesmente com um objeto fake('Mock') e + uma ponto de teste de unidade(JUnit,...) é q nunca deve fazer chamada externas (IO, Banco de Dados ... )

Eu não estou testando inserts ou findByIds da vida....são métodos específicos da aplicação que buscam dados para uma determinada regra de negócio, como por exemplo as entidades criadas nos 10 últimos dias.

Priuli wrote:Lembrando que muita gente usa TDD de um jeito errado(testa select, dados, coisas sem logica, criação de arquivos..) quando vc poderia fazer o mesmo simplesmente com um objeto fake('Mock') e + uma ponto de teste de unidade(JUnit,...) é q nunca deve fazer chamada externas (IO, Banco de Dados ... )

Priuli,

Discordo de você. Eu acho que devemos, sim, testar se nosso método está retornando corretamente os clientes cadastrados em uma certa data, ou se o arquivo que estamos gerando está seguindo o leiaute especificado.

Para testar código relacionado a Banco de Dados eu uso o DBUnit, como disse. Já para testar geração de arquivos, eu costumo fazer o seguinte: usando o FileUtils da commons-io, comparo o conteúdo do arquivo gerado pela minha aplicação com o de outro arquivo que criei "na mão".

Pode parecer um pouco trabalhoso, mas você não imagina a quantidade de bugs que já peguei desta forma...

This message was edited 2 times. Last update was at 13/04/2011 20:42:24

pango wrote:

Priuli,

Discordo de você. Eu acho que devemos, sim, testar se nosso método está retornando corretamente os clientes cadastrados em uma certa data, ou se o arquivo que estamos gerando está seguindo o leiaute especificado.

Para testar código relacionado a Banco de Dados eu uso o DBUnit, como disse. Já para testar geração de arquivos, eu costumo fazer o seguinte: usando o FileUtils da commons-io, comparo o conteúdo do arquivo gerado pela minha aplicação com o de outro arquivo que criei "na mão".

Pode parecer um pouco trabalhoso, mas você não imagina a quantidade de bugs que já peguei desta forma...

Existem diversas ferramentas para testes e tipos de testes diferentes o que eu escrevi foi de ñ usar chamada IO em teste de unidade das suas classes java(JUnit).. se vc criar em outra estrutura(DBUnit) fora do JUnit é diferente e até aceito, pois em alguns momentos precisamos testar outras ações, integrações.... mas para a maioria das situações eu ñ preciso fazer pois eu consigo testar(individualmente) 100% das minhas classes com teste de unidade sem realizar chamadas de e/s(io). Segue um exemplo dado por vc: naqueles arquivos que tem layout eu testo o layout(texto do arquivo) e não testo a escrita(em disco) do arquivo em si, eu trabalho o design das classes para que eu consiga testar tudo antes da chamada externa(IO), esta forma de teste requer bastante uso de refactoring durante e após a implementação da classe a ser testada e do teste. a diferença que eu consigo prever muitas coisas sem chamadas externas que agiliza os testes!!

This message was edited 1 time. Last update was at 13/04/2011 11:07:36

Nykolas Lima wrote:Valeu pelas respostas, vou dar uma olhada em como testar com hsql. E com HibernateMock, alguém já teve experiência com ele?

Eu não estou testando inserts ou findByIds da vida....são métodos específicos da aplicação que buscam dados para uma determinada regra de negócio, como por exemplo as entidades criadas nos 10 últimos dias.

ñ disse que estava, queria so deixa meu ponto de vista a todos.
O legal dos testes é q quanto mais vc usa mais vc consegue perceber o que poderia melhorar e aplicar no teste, ñ importa a forma que vc vai fazer sempre tem vantagem contra os bugs, o que é possivel fazer é melhorar a qualidade,simplicidade e segurança de executar seus testes e suas classes que serãotestadas.

Priuli wrote:
imagine vc roda um junit e esquece que esta apontando para a base de produção e simplesmente ele insere, apaga, altera um dado de produção..

Voce nao deveria nem pensar em uma situacao dessas, isso nao deve existir de maneira alguma.

Priuli wrote:
Eu não costumo usar testes de dados de bancosdedados, pois não faz sentido para mim. principalmente se tiver usando um framework de persistência como hibernate, se quiser testar baixe o código do framework e execute o testes do próprio framework e não crie um na sua aplicação.

Faz sentido testar pois voce tera operacoes em cascada para update/delete e integridades para inserts.
Voce pode testar se seu mapeamento esta correto e se as cascadas estao de acordo com suas expectativas.

Quanto a select's imagine a situacao aonde voce tem que buscar as atividades dessa semana,
voce pode testar se a data da atividade esta dentro da semana.

Priuli wrote:
Lembrando que muita gente usa TDD de um jeito errado(testa select, dados, coisas sem logica, criação de arquivos..) quando vc poderia fazer o mesmo simplesmente com um objeto fake('Mock') e + uma ponto de teste de unidade(JUnit,...) é q nunca deve fazer chamada externas (IO, Banco de Dados ... )

TDD e' uma metodologia: red -> green -> refactor - e nao diz nada sobre o que voce testa ou como testa.
http://en.wikipedia.org/wiki/Test-driven_development

Priuli wrote:
Existem diversas ferramentas para testes e tipos de testes diferentes o que eu escrevi foi de ñ usar chamada IO em teste de unidade das suas classes java(JUnit).. se vc criar em outra estrutura(DBUnit) fora do JUnit é diferente e até aceito, pois em alguns momentos precisamos testar outras ações, integrações.... mas para a maioria das situações eu ñ preciso fazer pois eu consigo testar(individualmente) 100% das minhas classes com teste de unidade sem realizar chamadas de e/s(io).

Uhmn.. aceita DBUnit mas nao JUnit?

dbunit.sf.net wrote:
DbUnit is a JUnit extension (also usable with Ant) targeted at database-driven projects that, among other things, puts your database into a known state between test runs. This is an excellent way to avoid the myriad of problems that can occur when one test case corrupts the database and causes subsequent tests to fail or exacerbate the damage.

E como ja tinha sido citado acima.

Priuli wrote:
requer bastante uso de refactoring antes de fazer o codigo.

magia negra total, refactoring antes mesmo do codigo! estou impressionado!
tem uma galera do GUJ que apavora total! High5!

JavaEvangelist Membro desde: 27/12/2007 19:31:45 Mensagens: 373 Offline

Seguindo as colocações do Keller, eu ñ costumo utilizar o DBUnit pois ñ sou muito a favor. eu sou a favor do uso do JUnit e ñ sou muito fã do dbunit mas ñ to dizendo q nunca vou usar ou q alguém ñ deva usar e sim que eu evito de usar o dbunit. Já o junit eu uso sempre
Sobre a Magia Negra rs queria dizer que durante e após a implementação das classes(lógica) e dos testes sempre faço refactor a fim de retirar o acoplamento, estruturando minhas classes para que eu consiga testar tudo sem chamadas de e/s.. Explicando já que o Ke. levou ao pé dá letra, sem nenhum o bom senso e sim TDD é uma metodologia e pode aplicar de vários formas, eu aborto muito no conceito de teste de unidade(que deveria ter citado no texto e ñ ter colocado como TDD com escrevi, passou despercebido) e cabo sempre argumentando neste sentido + claro, temos varias abordagem anyway..

Notícias, artigos e o maior fórum brasileiro sobre Java