| Autor |
Mensagem |
|
|
takeshi10 wrote: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
|
 |
|
|
então tá.
valeu
Woody
|
|
|
|
eu acho isso muito "joselito" (sem noção - gíria carioca).
eu acho que é igual à aqueles caras que entopem suas assinaturas com seus certificados (cada um com seu cada um né?).
Woody
|
|
|
|
pcalcado wrote:http://www.martinfowler.com/articles/continuousIntegration.html
poxa, não dá pra resumir?
Valeu
Woody
|
|
|
|
sistema de integração contínua - nome bonito e pomposo. Mas o quê é esse treco? pra que serve?
Woody
|
|
|
|
tem sim, tem um fantástico chamado CAP - code analyzer plugin, algo assim, ele é muito bom pra achar cycling e tem muitas métricas que os outros não tem (vc acha ele no plugins central).
Woody
|
|
|
|
e aí? qual é a resposta correta?
Tô achando que ele acabou se convencendo da respota do teste!!!
Woody
|
|
|
|
louds wrote:Primeiro que com classloading você não resolveria o seu problema, pois teria que recarregar TODAS classes do teu sistema.
Segundo, todas maneira que existem são gambiarras porque quer ir contra algo que você mesmo estabeleceu, quer que tuas constantes deixem de ser constantes.
É como querer uma classe tua não possua os métodos wait() de Object, vai contra o sistema de tipos da linguagem.
Em resumo, seja esperto e crie um wrapper para essas Strings e seja feliz. Caso contrario não existe nem garantia que reloading vai funcionar, pois a JVM é livre para propagar os valores de constantes estáticas diretamente para onde bem entender.
Primeiro, segundo, terceiro? lista de compras?
Desculpe mas vc chegou a ler os dois artigos nos links que postei? Please. Eles falam justamente sobre como resolver esse problema: reescrevendo um classload mais simples.
As constantes continuariam sendo cosntantes (são REFerências tá? não são strings imutáveis) sendo que a "inicialização" destas é que é responsável pela leitura de seus valores do bundle.
Descarregá-las iria facilitar minha vida (se não fosse arriscado), elas não deixariam de ser "constantes". Na verdade essa solução (descarregar classes) já é necessidade de containers de aplicação (jboss, tomcat)
Não sou esperto louds, gosto de pesquisar e um wrapper (ou vários) não iriam resolver sem ter de alterar muita coisa no meu código legado - sorry.
Woody
|
|
|
|
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
|
|
|
|
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
|
|
|
|
maneiro!!!
essa eu não sabia.
Valeu
Woody
|
|
|
|
isso resolveria é verdade. Mas eu não quero que elas deixem de ser constantes - deve ter alguma forma de fazer isso - caracas.
Se esse lance do classload não fosse tão arriscado eu mandava ver nele (não conheço ninguém que o tenha usado) - resolveria tudo, bastaria descarregar a classes "constante" e vua-lá (na sua próxima utilização ela seria carregada novamente).
AOP? Tô fora - já vio o peso que essa parada agrega? não conheço ninguém ninguém mesmo usando AOP em produção (só vejo bobeirinhas ou demos pra tentar vender o peixe)
Woody
|
|
|
|
renato3110, concordo plenamente.
Woody
|
|
|
|
renato3110 wrote:
agodinhost wrote: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 é?).
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
|
|
|
|
J2Alex wrote: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
|
|
|
|