Dúvida sobre JUnit

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:

Assert.assertEquals("valorEsperado", meuObjeto.getValorEsperado);

[]'s

Olá João,

Valeu pela dica… preciso rever alguns conceitos. :roll:

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?

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 :mrgreen:
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

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?

takeshi10:

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

O framework de teste poderia abstrair isso…

Seus métodos privados de alguma forma são reaproveitados pelos métodos públicos da classe. O que importa são os métodos públicos funcionando. Nada impede de você testar metodos protegidos ou default.

Se seus metodos privados dar a impressão que possuem logicas muito importantes, talvez vale a pena colocar esse código em alguma outra classe e testá-la. Ou ainda, deixe o modificador do metodo como default, e coloque a classe de teste no mesmo pacote da classe que está sendo testada.

O framework de teste poderia abstrair isso…

Exatamente.

O objetivo da reflexão é descobrir detalhes do teu código em tempo de execução.

O objetivo do teste é certificar que os contratos do teu código estão ok.

Internamente o JUnit já usa reflexão …

Woody

Outra classe? Parece interessante, mas acho que não cobre todos os casos…

EDIT: acho que a única solução mesmo sendo esquisitinha seria o protected, ou aina o default, já que não veria necessiadde de liberar acesso às subclasses assim à tôa…

A questão de mudar os métodos pra default ou protect é questionável… devemos fazer isso permanentemente, violando boas práticas de OO, já que eu considero que a utilização de protect ou default devem ser evitadas ao máximo? Devemos fazer isso somente durante os testes e depois voltar ao escopo normal? Blz, mas e se esquecermos algum método pra trás? Bye escapsulamento…

Tem algum expert em testes aqui para nos dar uma luz? TDD? Vou dar uma olhada nisso… :roll:

Antes o modificador default do que protected.

Se for realmente necessário testar o metodo privado, eu mudaria ele para default.

O encapsulamento só seria quebrado por classes que se encontram no mesmo pacote. Ou seja, para quebrar o encapsulamento o cliente teria que criar uma classe no mesmo pacote.

Se quiser criar uma classe utilitária, deixe o modificador da classe como default. Ninguém vai conseguir acessá-la fora do pacote.

Vc só vai ter de violar essas boas práticas pq teu código sob teste já não as segue. Pense bem: o objetivo dos testes é validar contratos dos trechos relevantes. RELEVANTES - não devo testar tudo, devo testar apenas as entradas e saídas que realmente importam.

Se tuas classes tem 99 % de métodos privados isso cheira mal - tem certeza de que vc está programando OO? Muito método privado acaba gerando baixo número de classes (o que em projetos grandes significam baixa coesão e alto acoplamente não é?).

Só um lembrete: não adianta tentar ser purista (ou acadêmico) - o dia a dia nos prova que sempre devemos buscar outras soluções, esse negócio de torcer o nariz toda vez que vc tem de escrever uma linha torta não leva a lugar nenhum.

Não sou nehum expert em testes.

Afinal de contas estamos todos aprendendo não é?

Woody

eu normalmete crio testes para as partes visiveis do codigo, ja que apenas a interface me interessa (e nao os detalhes de implementacao, que estarao nas partes privadas)…

Tá, tudo muito bonitinho: “criar testes para partes visíveis”, mas na prática isso pode não funcionar muito(não estou questionando em hipótese alguma a utilidade dos testes unitários, muito pelo contrário…).

Podemos ter códigos importantes e relevantes (e complexos) em métodos privados. Simplesmente não testamos?

Agodinhost, eu não disse que a classe XYZ possui muitos métodos privados - pode ter um e esse um ser extremamente relevante e passível de testes.

Ainda não surgiu nenhum argumento inquestionável neste tópico, tomara que isso aconteça.

Muitos métodos privados não é OO? Estranho. Olhem este exemplo aqui no arquivo anexado, para entenderem do que estou falando. 90% dos métodos são privados e não vejo necessidade de dividir em mais classes porque não há necessidade de reutilização desses métodos. EDIT: Mas eu gostaria SIM de testá-los porque o ÚNICO método público depende do bom funcionamento da galera do private.

Concordo com o J2Alex…

Se algo estiver dificil demais para resolver é pq alguma coisa tá errada. Ou você esta querendo testar algo que não precisa ou tem coisa demais aonde não devia.

Por exemplo, qual é a dificuldade de mover um método privado com um cálculo complexo para uma classe que possui modificador default? Ao meu entender, encapsulamento não é apenas marcar atributos como privado e criar metodos acessores para eles. Definir um pacote responsável por uma lógica de negócio da aplicação não deixa de ser um encapsulamento, IMHO.

J2Alex:

Tá, tudo muito bonitinho: “criar testes para partes visíveis”, mas na prática isso pode não funcionar muito(não estou questionando em hipótese alguma a utilidade dos testes unitários, muito pelo contrário…).

Podemos ter códigos importantes e relevantes (e complexos) em métodos privados. Simplesmente não testamos?

Agodinhost, eu não disse que a classe XYZ possui muitos métodos privados - pode ter um e esse um ser extremamente relevante e passível de testes.

Ainda não surgiu nenhum argumento inquestionável neste tópico, tomara que isso aconteça.

cara, esses métodos importantes (ou não) ainda são chamados indiretamente por alguém certo? senão serão dead code. Se vc testar os métodos públicos que os utilizarem vc os testará indiretamente não é?

Se esses testes indiretos ainda não forem suficientes vc terá de prover testes específicos pra esse cara - o que o torna suspeito, ou seja: será que não deveria ser público? será que alguém mais não vai precisar desse cara em um futuro qq? a dificuldade em testar um método muitas vezes sugere a relevância do mesmo (muitas vezes não quer dizer sempre)

Qto ao que disse sobre o número de métodos privados acho que preciso ser mais claro: “acaba gerando” quer dizer: promove, favorece. Isso não é verdade?

Woody

PS: toda regra tem um m. de exceção

Thiago Senna:

Se algo estiver dificil demais para resolver é pq alguma coisa tá errada. Ou você esta querendo testar algo que não precisa ou tem coisa demais aonde não devia.

Por exemplo, qual é a dificuldade de mover um método privado com um cálculo complexo para uma classe que possui modificador default?

Vocês não estão entendendo:

public       private
---------- = ------------
class user    self class

Ao meu ver, encapsulamento está loge de ser isso. Encapsulamento é você não mostrar o que não é relevante. Se você cria get/set para um membro private você não tá encapsulando nada, você só tá mudando o jeito de acessar, pelo o que eu entendo.

Deixar todas as classes do pacote verem aquilo que, se não fossem os testes, seria desnecessário me parece meio artificial, pois o teste deveria ser orientado em função da aplicação e não o contrário IMHO.

Muitos métodos privados não é OO? Estranho. Olhem este exemplo aqui no arquivo anexado, para entenderem do que estou falando. 90% dos métodos são privados e não vejo necessidade de dividir em mais classes porque não há necessidade de reutilização desses métodos. EDIT: Mas eu gostaria SIM de testá-los porque o ÚNICO método público depende do bom funcionamento da galera do private.

Concordo com o J2Alex…

Não disse que não é OO. Disse que cheira mal (é suspeito) - mas isso é só minha opinião okay?

Essa classe tem o quê? uns 20 métodos dos quais tem uns 5 públicos. Os métodos estão coesos (todos falam do mesmo assunto). Não vi problema algum aí.

Essa classe não tem muitos métodos privados - ela tem o necessário.

Quando eu digo classes grandes pense em classes com mais de 200 métodos. Coisa feia, eu sei, mas em projetos grandes é bem comum esse tipo de m. (são as famosas classes fazTudo.java - vc já viu alguma?).

Woody

renato3110, concordo plenamente.

Woody

Indiretamente, mas não individualmente. Se eu fizer mudanças nos meus 400 métodos privados não-testáveis do Valerioduto, e por um acaso houve um errinho que fez desabar o método público, falhando o teste, como vou futucar à mão os 400 métodos para descobrir o erro?

Deveria ser público porque deveria testar? Não seria mais para o contrário? Testes = servo, Código = senhor.

Quando precisar tu muda. Pra quê se apressar?

Você deve estar falando de classes gordas, mas ao que parece como se muitos privates fosse um indicativo disso. Não acho que seja, seria apenas uma classe com um alto encapsulamento, sou ignorante quanto aos perigos disso…

renato3110:

Ao meu ver, encapsulamento está loge de ser isso. Encapsulamento é você não mostrar o que não é relevante. Se você cria get/set para um membro private você não tá encapsulando nada, você só tá mudando o jeito de acessar, pelo o que eu entendo.

Deixar todas as classes do pacote verem aquilo que, se não fossem os testes, seria desnecessário me parece meio artificial, pois o teste deveria ser orientado em função da aplicação e não o contrário IMHO.

exatamente… o teste eh orientado em funcao da aplicacao, ou seja, da interface que ela oferece… nos casos de classes, sao os metodos publicos (e protected e default tambem, pois serao usadas por outras classes)…

metodos (e campos) privados nao sao visiveis nem para as subclasses, o que indicam que eles nao devem ser usados / chamados diretamente, pois fazem parte da implementacao da funcionalidade das classes…
os testes (IMHO) devem ser orientados a interface que as classes oferecem, de modo que nao importando a implementacao da mesma, desde que ela respeite a interface, ela passe nos testes…

e tambem concordo que mudar o escopo de um metodo / campo para ser acessivel pelos testes eh artifical demais, mas sugere que alguma coisa na sua arquitetura depende demais da implementacao das classes, quando deveria depender apenas das interfaces…

Ok ok, não estamos brigando, só aprendendo juntos. O que eu tô falando tammbém é minha umird opinião

Não entendi

Já falei daquela parada do TDD não foi?

Vc começou esse projeto na fase de implementação? Teve projeto pra ele? Requisito? Caso de Uso? (só pra me situar ok?)

Cara, no mundo ideal vc escreveria primeiro os testes (eu sei, eu tb nunca consegui fazer isso).

Tá mais pra:

• código = biblioteca fechada com contratos bem definidos que tem de atender meus requesitos (não interessa a parte interna)

• testes = usam essa biblioteca e verificam se fazem o que o seu contrato diz fazer.

Quem vem primeiro? O requisito ou o código?

Woody

Renato:

Ao meu ver, encapsulamento está loge de ser isso. Encapsulamento é você não mostrar o que não é relevante. Se você cria get/set para um membro private você não tá encapsulando nada, você só tá mudando o jeito de acessar, pelo o que eu entendo.

Concordo Renato, mas além de não permitir acesso ao que é desnecessário, acredito que o encapsulamento tem o objetivo de facilitar futuras manutenções. Ou seja, eu facilmente posso alterar meu metodo setIdade(Idade idade) para nao aceitar numeros negativos. Bom, mas isso não está em questão agora!

Bom, eu tentei fazer do jeito que você considera correto, mas não consegui. Ai tive que escolher, é melhor quebrar e testar ou deixar do jeito ideal sem testes?

É, estas situações são foda!

Os testes de unidade (ou de regressão) não tem como objetivo serem completos - isso não dá. Eles cobrem só o que eu acho interessante pra meu negócio dentro da verba que se tem pra fazer esses testes.

Qto mais perfeito mais caro é pois leva mais tempo - obviamente soluções rápidas tendem a ser incompletas por terem pouco tempo pra se observer todos os cenários relevantes então nos sobra o bom senso: O Meio Termo (que é o que sempre devemos buscar).

Woody

prefiro o contrário! (EDITADO: o contrário é demais… talvez o meio termo!)

Renato:

agodinhost wrote:

será que alguém mais não vai precisar desse cara em um futuro qq?

Quando precisar tu muda. Pra quê se apressar?

Renato, também acho que é preocupação demais achar que alguém vai quebrar o seu encapsulamento de metodos com modificador default. Se vc está fornecendo um pacote com um serviço para alguém, quando esse alguém vai criar alguma classe no mesmo pacote que estão suas classes? IMHO, é ele quem está optando por correr o risco.

renato3110:

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.

takeshi10:

e tambem concordo que mudar o escopo de um metodo / campo para ser acessivel pelos testes eh artifical demais, mas sugere que alguma coisa na sua arquitetura depende demais da implementacao das classes, quando deveria depender apenas das interfaces…

A própria classe depende de sua implementação, o que é óbvio. Ora, se o método é private, que coisa fora da própria classe teria como depender dele? Ou seja, classes externas não tem como depender do private da classe…

Imaginem um carro. Temos, basicamente, como interface pública dele a direção, o freio, o acelerador, a embrenhagem, o câmbio e mais algumas outras coisas. Tudo bem, vamos criar uma rotina de testes para checar se esta interface está funcionando bem.

Agora imaginem que nosso carro possui um sistema de injeção eletrônica - não é uma interface pública, nós - motoristas - não temos acesso a ela, mas ela vai propiciar ou não o perfeito funcionamento do veículo e será acionada sempre que ligarmos a chave de ignição ou pisarmos no acelerador… não seria razoável que pudéssemos testar o sistema de injeção eletrônica do carro? Lembrem-se que em hipótese alguma ele deve se tratar de uma interface pública.

Essa sua afirmação eu achei bem relevante e coerente, mas então aí se coloca em xeque até que ponto os teste serão aplicados de forma eficiente, ou se estão lá só pra cumprir com as exigências da gerência. Pois todos sabemos que os custos de manutenção são bem maiores quanto mais tardiamente se localizem os problemas.

ola renato!
entendi sim o que vc quis dizer e vou exemplificar com a classe que vc mandou (soh uns pedacos, pois nao li inteiro)
por exemplo onde ele pega os campos de uma classe, eu faria uma classe acessora para tal (uma com get / set value para um field em cima de um objeto), para que o desseriador de xml pudesse ser usado (e tambem para poder acessar campos privados, etc)…
outro exemplo eh quando vc formata os objetos em XML dentro do xml output, eu faria uma classe XMLFormatter ou algo do tipo e testaria fora…
perceba, ainda, que estas coisas nao dependem da instancia da classe (nao usam campos de instancia), ou seja, poderiam ser estaticos…

IMHO, a classe esta fazendo muita coisa a mais do que deveria e por isso os metodos devem ser privados e por isso eh dificil de testar… eu dei apensar 2 sugestoes que poderiam, IMO, melhorar um pouco a testabilidade e o reuso dos componentes, alem de poder mudar, por exemplo, a forma como os objetos sao representados o arquivo xml, sem criar subclasses (e mudar todos os metodos private para protected)…

Bingo! No entato, IMHO testes unitários não são para gerência. É para o próprio programador. Você está provando para você mesmo que o código que você escreveu funciona.

agodinhost:

Vc começou esse projeto na fase de implementação? Teve projeto pra ele? Requisito? Caso de Uso? (só pra me situar ok?)

Não existe teste ainda, mas se for o caso só vai ter UM teste pois só há UM método público, e existe muita funcionalidade nos privates que eu queria testar.

Ou então pode criar esse método quando for necessário, ou então pode sugerir ao JCP que crie proprieades que é mais bonito e mantém o código compilando

Thiago Senna:

Bom, eu tentei fazer do jeito que você considera correto, mas não consegui. Ai tive que escolher, é melhor quebrar e testar ou deixar do jeito ideal sem testes?

É, estas situações são foda!

Exatamente, Thiago! Você acaba de resumir a discussão!

J2Alex:

Imaginem um carro. Temos, basicamente, como interface pública dele a direção, o freio, o acelerador, a embrenhagem, o câmbio e mais algumas outras coisas. Tudo bem, vamos criar uma rotina de testes para checar se esta interface está funcionando bem.

Agora imaginem que nosso carro possui um sistema de injeção eletrônica - não é uma interface pública, nós - motoristas - não temos acesso a ela, mas ela vai propiciar ou não o perfeito funcionamento do veículo e será acionada sempre que ligarmos a chave de ignição ou pisarmos no acelerador… não seria razoável que pudéssemos testar o sistema de injeção eletrônica do carro? Lembrem-se que em hipótese alguma ele deve se tratar de uma interface pública.

mas provavelmente teria uma classe InjecaoEletronica que poderia ser testada unitariamente, certo?

Hehe… concordo, talvez meu exemplo não tenha sido muito feliz… mas estou sem tempo pra pensar em algo melhor…

A questão é: suponha (apenas suponha) que a injeção eletrônica não tivesse relevância suficiente para ser uma classe, seria portanto implementado como um método. Ele não faz parte da interface pública, mas é realmente importante e deveria ser testado.

Hehe… concordo, talvez meu exemplo não tenha sido muito feliz… mas estou sem tempo pra pensar em algo melhor…

A questão é: suponha (apenas suponha) que a injeção eletrônica não tivesse relevância suficiente para ser uma classe, seria portanto implementado como um método. Ele não faz parte da interface pública, mas é realmente importante e deveria ser testado.[/quote]

tb nao consigo pensar em nenhum exemplo pratico e eh exatamente por isso que eu acho q testes devem ser feitos sobre metodos publicos (protected e default tambem merecem set testados)…
nao estou querendo saber mais que ninguem, apenas colocando a minha opiniao e o meu jeito de arquitetar classes e testes…

takeshi10:

ola renato!
entendi sim o que vc quis dizer e vou exemplificar com a classe que vc mandou (soh uns pedacos, pois nao li inteiro) […]

É, não entendi muito bem as sugestões, mas quanto à criar mais classes seria mais por organização mesmo, não muito por reuso.

Isso levanta uma outra questão. O projeto em si possui umas classes utilitárias que só serverm para o próprio projeto, não para quem usa. Moral da história: eu queria fazer um package private. Alguém já pensou nisso?

A única solução que vejo por enquanto é sugerir por nomenclatura que o pacote não interessa ao usuário. Exemplo: org.valerioduto o pacote público, e org.valerioduto.suporte, as classes que não são package only, mas também não tem a ver com o usuário final…

renato3110:

takeshi10:

ola renato!
entendi sim o que vc quis dizer e vou exemplificar com a classe que vc mandou (soh uns pedacos, pois nao li inteiro) […]

É, não entendi muito bem as sugestões, mas quanto criar mais classes seria mais por organização mesmo, não muito por reuso.

Isso levanta uma outra questão. O projeto em si possui umas classes utilitárias que só serverm para o próprio projeto, não para quem usa. Moral da história: eu queria fazer um package private. Alguém já pensou nisso?

A única solução que vejo por enquanto é sugerir por nomenclatura que o pacote não interessa ao usuário. Exemplo: org.valerioduto o pacote público, e org.valerioduto.suporte, as classes que não são package only, mas também não tem a ver com o usuário final…

as minhas sugestao sao tanto por organizacao, quanto para reuso (imagine que vc precise formatar apenas 1 objeto em XML)…
embora talvez seja um tanto “overdesign”, eu soh quis dar um exemplo…

É takeshi, acho que é o melhor a fazer mesmo, dividir em mais classes e colocar num pacote “semanticamente privado”… Isso até evitaria o lance artificial de mudar a visibilidade do private só pra testar…

Só não sei se vou conseguir dividir legal, pelo menos o método recursivo achei um pouco grande mas acho que não dá pra dividir hehehe porque quando tentei quebrou tudinho…

metodos recursivos sao os mais dificeis de ser testados…
eu soh testo a base da recursao e depois um ou dois casos…

takeshi10:

metodos recursivos sao os mais dificeis de ser testados…
eu soh testo a base da recursao e depois um ou dois casos…

pra mim o problema destes são os cenários - quase sempre é n.
EDIT: - quase sempre é bem grande.

Woody

n???

Bom no meu caso aconteceu os seguinte: achei o método grandinho, pensei em granular até mesmo pra ficar mais legível, mas quando tentei fazer isso simplesmente quebrou tudo e não consegui de jeito nenhum descobrir o porquê disso, aí voltei a deixar o método gordinho.

Quando eu for fazer o teste o foda vai ser testar todas as MUITAS possibilidades de comportamento do método, de acordo com as MUITAS entradas possíveis. Isso que vai ser foda…