Dúvida sobre JUnit

Olá,

Tenho algumas dúvidas em relação ao JUnit. Imaginem o seguinte código (não é uma implementação real, é só um exemplo):

Estou usando o pattern Template Method neste exemplo para definir uma sequência de algoritmos.

Minha dúvida é: como seria um teste unitário neste caso?

Grato.

GUJ Master Membro desde: 16/12/2004 17:09:19 Mensagens: 1787 Offline

Sei lá, eu verificaria o estado esperado dos objetos que são afetados pela ação desses métodos. Crie objetos de mentirinha para testar. Você teria que testar cada implementação e não essa abstração...

Olá Renato,

Não foi muito esclarecedora a sua resposta. A questão é que não conheço bem testes unitários e estou querendo começar a entender melhor. Aí imaginei este exemplo. Sempre que vejo testes unitários eles testam o retorno de algum método ou algo semlehante.

No exemplo que passei os métodos não retornam valores, eles simplesmente executam processamentos internos e ainda estão encapsulados através do template method. Não entendo como ficaria um teste unitário neste caso.

Agradeço a qualquer um que possa me ajudar a solucionar esta questão filosófica tão profunda.

(Finalmente o GUJ voltou a vida!!!! Eba!!!!)

eu não testaria o metodo do template, e sim os metodos encapsulados, separadamente.
tente sempre testar a menor porção possivel do codigo, isso vai faciltar sua vida. se seus metodos não retornam nada vc precisa fazer um esquema de criar um objeto com o estado esperado e um outro que vai ser manipulado. e depois comparar eles. ou criar um unico objeto que é manipulado e depois vc testa o estado dele.
tipo:

[]'s

Olá João,

Valeu pela dica... preciso rever alguns conceitos.

GUJ Master Membro desde: 16/12/2004 17:09:19 Mensagens: 1787 Offline

Alexandre, não conheço bem testes unitários também

Como o João disse, nesse caso aí nem tem muito sentido testar o método baixarDoc em si. Veja que não tem sentido testar métodos abstratos como no Template Method, simplesmente porque eles não fazem nada. No seu caso inclusive, o Template Method em si não faz nada de concreto.

Agora, por exemplo, digamos que esses seus métodos aí no baixarDoc retornassem alguma coisa, e que o método pegasse esse retornos e batesse tudo no liquidificador pra fazer um suco de laranja. Neste caso, além de testar cada método e si dentro de baixarDoc, você teria que testar o próprio baixarDoc para ver se ele tá fazendo o suco de laranja direito.

Ok. Mas agora me ocorreu outra questão: e se meus métodos forem protegidos? Ou pior, privados... como testá-los? Eu só posso testar métodos públicos?

GUJ Master Membro desde: 16/12/2004 17:09:19 Mensagens: 1787 Offline

Boa pergunta, também queria saber. Protegidos e default a princípio dá pra pensar em colocar o teste no mesmo pacote, mas no caso de privados?

não tem o que fazer, sem uma entrada visivel não tem como testar mesmo.pelo menos que eu saiba

sua classe de teste é um objeto como qualquer outro, so vai enxergar de seu objeto o que vc espor. no caso do seu primeiro exemplo, se seus metodos encapsulados fossem privados, vc teria que testar sua casca mesmo.

[]'s

Métodos privados normalmente não são passíveis de testes.

Tenha em mente que devemos testar nossas classes como se fôssemos meros usuários das mesmas (como se elas estivessem empacotadas num jar).

Vc precisa ter seu contrato muito bem definido: cada método deve ter sua pré e pos condição (entrada e saída) muito bem definida, de preferência no javadoc - pois vc deve limitar seus testes à esse contrato - nada mais nem nada menos, claro que esse contrato pode resultar numa combinação bem grande de cenários - mas é exatamento isso que vc deve testar.

É muito comum alterar assinaturas de métodos privados para protected apenas para métodos críticos (na prática isso é inevitável) .

Espero que tenha ajudado.

Woody

GUJ Master Membro desde: 16/12/2004 17:09:19 Mensagens: 1787 Offline

Mas por exemplo eu tenho uma classe onde 90% da funcionalidade são métodos privados. Seria interessante manter essa estrutura por si só testável.

Acho que a única solução é colocar os testes na mesma classe

, mas se não der o lance do protected ou testar só os publics já parece bom...

via reflection, eh possivel executar metodos privados (da um pouco de trabalho)...
de uma olhada no PrivilegedExceptionAction

[edit]
mas normalmente vc vai querer testar as coisas publicas, jah que elas formam a interface da sua classe, ao inves de se preocupar com as implementacoes
[/edit]

Mas se eu não testo meus métodos privados, como posso afirmar com certeza que eles estão corretos? E se eu alterar os seus códigos? E se eu refatorar o meu sistema? E se a maior parte dos algoritmos complexos estiverem ocultos dentro dos meus métodos privados? O que eu faço então? Rezo?

GUJ Master Membro desde: 16/12/2004 17:09:19 Mensagens: 1787 Offline

takeshi10 wrote:via reflection, eh possivel executar metodos privados (da um pouco de trabalho)...
de uma olhada no PrivilegedExceptionAction

[edit]
mas normalmente vc vai querer testar as coisas publicas, jah que elas formam a interface da sua classe, ao inves de se preocupar com as implementacoes
[/edit]

Será que o JUnit trabalha com métodos privados?

Quanto ao [edit], é isso que vocês não estão entendendo. Os métodos públicos estão para os usuários da classe assim como os private estão para a própria classe. O conjunto private da classe é uma interface também, é só uma questão de escopo

Imagine que eu tenho uma classe Valerioduto com um único método público mensalar(), que usa uns 400 métodos privados de alta complexidade para distribuir o mensalão de forma justa e precisa, afinal são muitas, muitas contas, muitos bancos, muito políticos.

Aí eu crio o teste só para o mensalar() e um belo dia o teste começa a falhar após eu alterar um desses métodos (eu altero qualquer um toda hora). Aí complica porque vou ter que futucar os 400 métodos só pra achar dentre os que alterei que tá bugando o sistema. Se cada método por si só fosse testável ia ajudar bastante. Entenderam?

cara, esquece reflexão.

Os testes sempre devem primar por simplicidade (ou vc vai acabar tendo de escrever testes para seus testes !!!).

A soluçao é "aumentar" a visibilidade dos private para protected e escrever seus testes no mesmo pacote. Nunca na mesma classe ok? Lembre que na hora da distribuição isso não deverá ser carregado.

Mais alguns detalhes: escrever testes para código legado (já escrito e em produção) é o oposto do recomendado e isso acaba dificultando a escrita destes testes pois vc terá de descobrir todos os contratos na unha.

Sei que na teoria tudo é muito bonitinho - recomendam que vc comece a codificar escrevendo seus testes e só depois disso venha a escrever o código 'final'. Na prática isso exige uma fase de projeto e no dia a dia tupiniquim isso nem sempre é possível (nossos projetos quase sempre tem a fase de projeto misturada com a fase de implementação)

Procure por TDD na web, Test-Driven-Developement. Aprende aí e depois me conta tá?

O JUnit é uma super ferramenta mas para usá-lo adequadamente é necessário estudar TDD (a teoria). TDD por sua vez é baseada em outras técnicas que nós nem sempre podemos exercitar: lembro apenas da principal (ao meu ver) que é o Refactoring.

Pro teu caso não vai ter outra solução senão levantar todos os contratos pré-estabelicidos (pré e pós condições) na unha lendo o código de ante mão.

Conclusão: o JUnit vai ajudar a te ajudar a melhorar teu código?
(não vou responder - isso dá muito pano pra manga)

Procure tb por:
Prentice Hall 2003, Test-Driven Development A Practical Guide

Woody

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