Problema com Testes Unitários

oi

eu tenho uma dúvida e uma sugestão

:arrow: porque o método testBuscarTodosUsuarios() espera 100 usuários? acho que no teste você não tem que esperar um número de usuários mas sim talvez apenas testar se a lista de usuários trazida não é nula

:arrow: porque você cria transação nos testes? acho que esse controle tem que ficar em outro lugar, de preferência nos métodos que rodam em um contexto transacional, ou então em outro lugar mais apropriado

além disso, qual o erro está acontecendo??

eu acho que se rodando os testes individualmente está dando certo e no suite não então pode ser que talvez a ordem de execução dos testes seja o problema, outra coisa que eu acho que pode ser problema é na hora de fechar a abrir transações, como eu falei, acho que isso não deve ser responsabilidade dos testes…

abs

E ai Andre,

bom eu estou engatinhando ainda em escrever bons testes unitarios. Nem sei se realmente eh necessario esse nivel de detalhe que estou implementando nos testes unitarios. Mas como eu tenho uma base de testes isolada, e todos as manipulacoes que os demais testes unitarios venham a fazer nos dados da base de testes sao desfeitos (rollback), entao estou usando esse nivel de detalhe para aumentar a precisao dos testes.

Esse lance da transacao esta sendo usado por 2 motivos:

1. a classe que esta sendo testada, automaticamente cria uma transacao
2. para poder ser possivel dar um rollback nas eventuais alteracoes nos dados que os testes unitarios venham a fazer.

Entretanto, acho que ja descobri o problema. Como o pessoal aqui implementou o gerenciamento da Session do Hibernate na mão, to desconfiado que a mesma Session está sendo reutilizada entre os testes unitarios e, por isso, essas inconsistencias qdo eu rodo a suite dos testes.

Mas valeu, se tiver alguma outra sugestao ai para melhorar os testes unitarios, fique a vontade.

Abraco

oi Marcos

Olha como nós estamos usando aqui, não sei se é a melhor prática mas vamos lá

:arrow: a classe de teste não é responsável por trabalhar com transação e nem com controle de sessão do hibernate, estamos usando um service locator para buscar essas coisas, também não usamos setup usamos um getConfigTestCase1 do service locator para trazer tudo que precisamos…

:arrow: a seqüência de testes é feita assim: primeiro eu testo as situações que dão erro usando como entrada dados que simulam o erro, no final eu testo a situação de sucesso usando uma massa de dados que irá dar sucesso para todos as nossas classes

Assim suponha que eu tenha algo assim

<blockquote>TestCase1

testSimulaCase1Erro1(dadossimulacase1erro1);

testSimulaCase1Erro2(dadossimulacase1erro2);

testCase1OK(dadoscomum);

TestCase2

testSimulaCase2Erro1(dadossimulacase2erro1);

testSimulaCase2Erro2(dadossimulacase2erro2);

testCase2OK(dadoscomum);

</blockquote>

o testCase2OK para funcionar precisa que o testCase1OK funcione

a idéia é que no final do test suite eu tenha uma massa de dados comum que passa por todos os processos que a gente precisa executar com sucesso

bom, esse é o jeito que a gente ta fazendo

arabéns, você acabou de descobrir como TDD e testes em geral ajudam a pensar em melhorar seu design.

Antes de mais nada, eu li sobre banco de dados ali. Se seu teste está usando banco de dados ele não é um teste unitário, é de integração. Testes de integração devem testar apenas a relação entre dois componentes (“se eu mando pro banco X ele me responde Y”) e não lógica de negócio. Lógica de negócio deve ser testada emt estes unitários, onde cada classe é testada isoladamente (i.e. sem Banco de Dados, sem container, sem nada além do JUnit e uma biblioteca de mocks).

Baseado no seu relato eu creio que seu problema é exatamente que você está tentando testar uma classe que contêm regra de negócios e fala com o banco de dados. O primeiro passo é separar as responsabilidade em duas ou mais classes, assim vcoê vai conseguir escrever testes mais eficientes para regra de negócio e vai simplificar seu teste de interação.

Complementando:

Procure uma biblioteca como o JMock para criar mocks da interação com o banco de dados, por exemplo.
Se o seu teste precisa de x dados do banco de dados, vc pode simular que existem estes x dados e ver se o seu código se comporta conforme o esperado.

Mas para isso vc deve separar bem as responsabilidades sob pena de ter mocks extremamente complexos ou praticamente impossiveis de serem trabalhados.

E ai pessoal, obrigado pelas dicas.

Bom, a idéia de usar o banco nos testes unitários e não mock objects foi a seguinte:

1. Primeiro eu implemento os testes unitários relacionados à camada de persistência.
2. Depois eu implemento as classes de testes unitários relacionados à camada de negócio que eventualmente acessam esses métodos de persistência.

A vantagem que eu vejo é que eu consigo isolar os erros que possam surgir. Se ocorrer um erro em algum teste unitário da camada de negócio e os testes unitários das classes de persistência estiverem OK, então, com certeza o erro está nessa camada de negócios.

Essa é uma forma meio “top-down” de testar as funcionalidades. A idéia de criar mock objects é interessante se eu for começar os testes unitários a partir da camada de negócios e não tiver nenhum teste unitário para validar os métodos de teste para validar as minhas classes de persistência. O problema que eu vejo é que vai dar um trabalhão implementar esses mock objects e de qqer forma, depois eu vou ter que implementar os métodos testes para validar as classes de persistência. Logo, pq não começar validando os métodos de persistência para então validar os de negócio, i.e., sem usar mock objects ?

Realmente, no meu caso específico, se eu tivesse feito os mock objects emulando o comportamento do BD, os meus testes unitários relacionados às classes de negócio teriam passado, entretanto, o problema do reuso da Session do Hibernate iria passar batido.

Em resumo, questiono a real vantagem em se fazer testes unitários usando mock objects, em vez de fazer logo os testes de integração que o Phillip menciona.

O que vcs acham?

Abracos

Para testes de integração com BD use DBUnit e resolva o problema de consistencia dos dados para cada teste.

http://dbunit.sourceforge.net/

[]s

oi Marcos

Então, aqui a gente também tem uma suite de testes para BD que é rodada antes e depois então rodamos a suite de testes para business.

Eu nunca usei mocks mas já estamos pensando em colocar no projeto

O problema que temos em fazer do jeito que está é que toda vez que formos recriar a base de dados temos que carregar os dados iniciais para que os testes funcionem

Eu acho que isso não é legal, e talvez a gente implemente a solução de usar os mocks, o dbunit eu relamente não conheço

abs

Oi andre,

pois eh, aqui no projeto o pessoal montou um script que faz uma carga inicial no BD. E todos os testcases sao baseados nas informacoes contidas nessa carga.

De qqer forma, acho melhor eu estudar mais um pouquinho aqui sobre TDD para chegar a uma conclusão sobre o qual a forma mais interessante de se implementar esses testes.

Obrigado.

Oi,

Hm… tem algo bem estranho ai. Num sistema Orientado a Objetos você espera que o fluxo seja contrário: primeiro os objetos e depois o banco. De qualquer modo, como falei antes, testes que conectam com o banco de dados não são unitários, são testes de integração e devem ser tratados de maneira bem diferente.

Exato, e por isso que você deve separar bem as responsabilidades. De qualquer forma, use os testes de desenvolvedor como ajuda no design e não como verificação. A verificação é um efeito colateral, útil mas ainda um efeito colateral.

A forma que você escreveu não é top-down, ela é extremamente bottom-up. Top-down seria você testar primeiro a funcionalidade toda, provavelmente com um teste de aceitação, depois criar os testes na Camada de Negócios e só depois persistência.

O trabalho repetido que você vai ter se deve ao fato de que suas classes estão fazendo coisas demais. Como disse antes separe suas classe em lógica de negócios (testadas com mocks) e acesso a recursos (testadas em testes de integração).

]Você não deve criar mocks para o banco de dados! Só se cria mocks do seu código.

Acho que você pode não ter entendido o que quis dizer. Testes de Integração são usados em conjunto com Testes Unitários. Os primeiros testam a interação do seu sistema com outros sistemas e recursos e o segundo testa as suas classes de negócio.

Phillip, obrigado pelos esclarecimentos.

Para testes de integração, como esses acessos a banco de dados, o jUnit é o cara mesmo ou existe algum mais específico?