Pq os teste unitários não são tão populares!

saoj wrote:Testes unitários é a rodinha da bicicleta. O problema é que pouca gente tem afirmado que é preciso aprender e gostar de andar sem rodinha.

Essa analogia as rodinhas de bicicleta implica que existe alguma vantagem em andar sem elas. Numa bicicleta normal, existem diversas vantagens (maior mobilidade, flexibilidade nas manobras, nao fazer papel de maneh quando vc ja passou dos 16 anos, etc). Eu nao vejo absolutamente nenhuma vantagem em escrever codigo fora do TDD alem do bom e velho "so pra dizer que eh macho". Cite algumas?

This message was edited 11 times. Last update was at 31/05/2008 10:49:24

louds wrote:
Eu pessoalmente acho que herança é um daqueles conceitos de OO que simplesmente não deu certo na prática, é uma idéia falha que só leva a designs furados.

Joshua Bloch usou *bastante* herança para fazer as collections. Usou interface tb, e da maneira correta é claro, mas fez uso extensivo de herança quando poderia ter optado por composição.

http://java.sun.com/javase/6/docs/api/java/util/LinkedHashSet.html

Que eu saiba todo objeto em Java herda de Object, logo herança é um conceito fundamental e essencial da linguagem Java.

Se eu tenho uma classe com 100 métodos e eu quero modificar o comportamento de um método, eu não quero ter que usar composição e delegar 99 métodos. É muita verbosidade em troca de ser puritano, sem falar de classes a mais (FruitImpl, Fruit, Apple). Até mesmo os criadores do Java optaram por herdar de Object ao invés de uma interface Object. Pensem bem como seria a linguagem se tivéssemos uma interface Object e a cada novo objeto tivéssemos obrigatoriamente que implementar hashCode, toString, equals, etc?

De qualquer forma, via composição + interfaces (digitando pra kacete) ou herança (digitando pouco) é possível estender as características de um objeto sem quebrá-lo, isto é, é possível criar novas funcionalidades (novo objeto ou método subescrito) sem distruir o objeto que ficou embaixo (herança) ou dentro (composição).

Mas concordo se vc tem um objeto A, e se por algum motivo justificável vc vai modificar agressivamente o código dos métodos já prontos de A, durante a vida do projeto, então seria bom ter testes unitários para A.

Eu geralmente programo um método uma única vez, faço ele funcionar como eu quero e depois não mexo mais nele, ou se mexo é para fazer um ajuste fino onde qualquer pessoa normal e minimamente atenta não vai fazer cagada. Até onde eu sei, um IF não exige replicação de código, não é POG, nem pecado.

A nova funcionalidade pode até não funcionar (claro, pois vc está codificando ela agora), mas o que já funcionava pode e tem que continuar funcionando.

Um caso que pede testes unitários é quando o método myMethod implementa um algoritmo mais ou menos complexo e vc vai modificar agressivamente esse algoritmo (pode até refaze-lo do zero) e não quer quebrar os contratos/output desse algortimo. Ex: BufferUtils, ByteUtils, etc. Nesses casos, achar que vai resolver o problema com um IF do tipo acima é ilusão. Mas essas classes são exceção e não regra.

É claro que o IF a cima só vai ser feito se a possibilidade de hierarquia (via herança ou composição) for descartada. Ninguém deve fazer algo assim: (erro clássico)

Será que as pessoas estão com medo de usar herança, com preguiça de usar composição, e estão programando como o exemplo acima e usando testes unitários como muleta? Sinceramente acho que não, mas talvez os conceitos de hierarquia e separação de responsabilidades não estão sendo entendidos como deveriam. É o caso de se ficar vigilante para não adentrar esse caminho, com ou sem testes unitários...

Virtual Machine Man Membro desde: 04/07/2007 18:28:58 Mensagens: 824 Offline

saoj wrote:Que eu saiba todo objeto em Java herda de Object, logo herança é um conceito fundamental e essencial da linguagem Java.

Sim, todo programador Java iniciante sabe disso, mas e daí?

saoj wrote:Se eu tenho uma classe com 100 métodos e eu quero modificar o comportamento de um método, eu não quero ter que usar composição e delegar 99 métodos. É muita verbosidade em troca de ser puritano, sem falar de classes a mais (FruitImpl, Fruit, Apple).

Primeiro, porque você tem um ÚNICA classe com cem, CEM!, métodos? Isso é design ruim, e provavelmente você não está utilizando herança, nem composição, nem orientação a objetos. Provavelmente é comportamento pra ser quebrado em algumas outras classes.

Segundo, quem disse que você TEM que expor todos os métodos da classe que está delegando? A beleza da OO é o encapsulamento, e se você repassa todos os métodos, existe alguma coisa furada.

Terceiro, o que a quantidade de classes influencia na qualidade do código? Se for necessário ter mais classes para melhorar o design, que seja feito.

Quarto, o que FrutaImpl faz? Esse é o problema! Você está querendo fazer composição, mas pensando em herança! Aí é claro, isso é POG! Quer ver um exemplo bom de composição? Digamos que eu queira saber valores nutricionais da fruta, cujo cálculo é "complicado" (na realidade, não tenho a mínima idéia se é isso ou não). Eu criaria uma interface InformacaoNutricional que qualquer fruta pudesse ter como referência (ou seja, composição), e poderia criar mais de uma classe para essa essa interface se houver diferentes estratégias (pattern?) de implementação. A Fruta poderia também ter outras interfaces para outros conceitos. Ou seja, não estou usando uma classe sem sentido como FrutaImpl, onde eu iria socar qualquer coisa lá dentro, estou usando composição de maneira correta.

saoj wrote:De qualquer forma, via composição + interfaces (digitando pra kacete) ou herança (digitando pouco) é possível estender as características de um objeto sem quebrá-lo, isto é, é possível criar novas funcionalidades (novo objeto ou método subescrito) sem distruir o objeto que ficou embaixo (herança) ou dentro (composição).

Isso não acontece de verdade, vide explicação anterior.

saoj wrote:Mas concordo se vc tem um objeto A, e se por algum motivo justificável vc vai modificar agressivamente o código dos métodos já prontos de A, durante a vida do projeto, então seria bom ter testes unitários para A.

Porque complicar o descomplicado? Afinal, como é que eu diferencio um código em que se modifica "agressivamente", de um outro em que se modifica "calmamente"? Melhor mesmo é parar de discutir besteiras e fazer testes unitários em todos os trechos de código possíveis.

saoj wrote:Eu geralmente programo um método uma única vez, faço ele funcionar como eu quero e depois não mexo mais nele, ou se mexo é para fazer um ajuste fino onde qualquer pessoa normal e minimamente atenta não vai fazer cagada. Até onde eu sei, um IF não exige replicação de código, não é POG, nem pecado.

public String myMethod(String p) { String res = null; // um monte de código aqui que vc não vai mexer... if (nova condição) { // faça uma coisa nova aqui... } else { // deixe aqui o código que já estava funcionando... } // um monte de código aqui que vc não vai mexer... return res; }
A nova funcionalidade pode até não funcionar (claro, pois vc está codificando ela agora), mas o que já funcionava pode e tem que continuar funcionando.

Primeiro (novamente!), quem disse que o que você quer agora será a mesma coisa que você irá querer amanhã? Quem disse que um "ajuste fino" não vai quebrar outras partes do sistema? Ninguém consegue prever ao certo se determinada modificação vai trazer efeitos colaterais ou não, independente do tamanho da modificação. Isso não existe, é desculpa esfarrapada de programador preguiçoso.

Segundo, aquele if do código é pecado SIM! Quem te disse que todas as partes do sistema que utilizavam o trecho de código antigo, vai continuar usando? Isso só aconteceria se expressão dentro do if estivesse correto, cuja prova só seria possível se fosse feito testes unitários.

saoj wrote:Um caso que pede testes unitários é quando o método myMethod implementa um algoritmo mais ou menos complexo e vc vai modificar agressivamente esse algoritmo (pode até refaze-lo do zero) e não quer quebrar os contratos/output desse algortimo. Ex: BufferUtils, ByteUtils, etc. Nesses casos, achar que vai resolver o problema com um IF do tipo acima é ilusão. Mas essas classes são exceção e não regra.

Besteira, não existe o conceito de "modificação agressiva", já explicado anteriormente.

saoj wrote:É claro que o IF a cima só vai ser feito se a possibilidade de hierarquia (via herança ou composição) for descartada. Ninguém deve fazer algo assim: (erro clássico)

public void coma() { if (sou cachorro?) { // coma como um cachorro } else if (sou gato?) { // coma como um gato } else { // coma como um animal } }

Não existe diferenças conceituais entre o primeiro e o segundo exemplo com ifs. Mas você está dizendo que um é bom e o outro não. Por quê?

saoj wrote:Será que as pessoas estão com medo de usar herança, com preguiça de usar composição, e estão programando como o exemplo acima e usando testes unitários como muleta? Sinceramente acho que não, mas talvez os conceitos de hierarquia e separação de responsabilidades não estão sendo entendidos como deveriam. É o caso de se ficar vigilante para não adentrar esse caminho, com ou sem testes unitários...

Também acho que as pessoas não estão com medo. É questão de inteligência mesmo. Separação de responsabilidades de faz com composição ou com herança. A diferença é que, com composição, a configuração pode ser feita em runtime.

Pra finalizar, não é questão de masculinidade. Fazemos testes unitários por puro pragmatismo.

This message was edited 7 times. Last update was at 31/05/2008 18:56:58

Leonardo3001 wrote:
(um monte de coisas)

Respeito inteiramente sua posição, mas gostaria de expressar meu completo desacordo com praticamente tudo que vc falou.

E o Joshua Bloch deve ser maluco por ter usado herança e não composição nas Collections. (http://java.sun.com/javase/6/docs/api/java/util/LinkedHashSet.html)

Só para explicar o FruitImpl, que acho que vc não entendeu:

É assim que vcs gostariam que Java fosse? Sem herança, com tudo baseado em composição e interfaces?

Pensei nesse código rapidamente, logo se houver alguma coisa errada por favor corrigia-o, para o bem do debate. Mas corrigia-o com código e não com palavras, pois o código deixa menos espaço para interpretações.

Ok, cem métodos é muito. Foi apenas um número solto, ok? Então pegue o java.util.Map, que tem mais que 10 métodos. Eu (e parece que nem o Joshua Bloch) não quero ter que reescrever e delegar 15 métodos. É tedioso e error-prone. Veja o exemplo bastante concreto de código acima e tire suas próprias conclusões. E sim, composição com interfaces é isso. Java não é Ruby com duck typing. Tem que implementar todos os métodos da interface, se não não compila.

Não existe diferenças conceituais entre o primeiro e o segundo exemplo com ifs. Mas você está dizendo que um é bom e o outro não. Por quê?

Tem certeza? O primeiro IF é um IF lógico e nada mais. IF's não são pecado, ou vcs querem tb remover o IF da linguagem? Já o segundo está assassinando claramente o polimorfismo, um erro clássico de quem está começando com programação OO ou de quem está programando muito rápido sem tomar cuidado com a arquitetura.

Trocar polimorfismo por if (obj instanceof Dog) é um erro muito feio que todo programador sincério (sincero + sério) vai admitir que cometeu no passado.

This message was edited 1 time. Last update was at 31/05/2008 23:06:23

1) Herança, assim como qualquer outra coisa, tem seus usos mas é amplamente exagerada sem motivo.

2) Você não precisa de herança -como em java- para ter OO. Linguagens OO baseadas em protótipos basicamente clonam o objeto original. Da mesma forma linguagens como Ruby permitem que reuso de código seja feito através de mixins, você não precisa usar herança para quase nada e um subset de Ruby que não incluísse herança continuaria sendo OO.

3) Heranças atrapalham testes da mesma maneira que composição atrapalha: quando se cria acomplamento com classes difíceis de serem testadas. O resto escrito neste tópico é FUD

4) Você não precisa de herança para ter polimorfismo.

Vou tentar trazer o tópico de volta ao assunto original, começando do ponto onde ele começou a desvirtuar...

saoj wrote:
... Muitos, tb por causa dos testes unitários, abominam herança.

Sérgio, você pode explicar isso um pouco melhor? Eu uso TDD e testes unitários há alguns anos e não sinto isso. Quando programo eu sempre tento deixar as coisas fáceis de serem testadas, mas não lembro de ter abolido herança para isso.

saoj wrote:
Eu geralmente programo um método uma única vez, faço ele funcionar como eu quero e depois não mexo mais nele, ou se mexo é para fazer um ajuste fino onde qualquer pessoa normal e minimamente atenta não vai fazer cagada. Até onde eu sei, um IF não exige replicação de código, não é POG, nem pecado.

Programar com testes unitários me faz pensar um pouco diferente. Eu sempre assumo que um método que eu fiz pode ser repensado a qualquer momento e por qualquer pessoa. Novas regras de negócio podem surgir, restrições de performance podem surgir, uma idéia para melhorar o design pode surgir. Neste caso meus testes ajudam a especificar e assegurar a responsabilidade de cada método, já que eu não confio na minha memória depois que alguns dias e algumas centenas de código já passaram na minha mão. E se for outro programador que estiver alterando o código, quero que ele tenha esta mesma segurança que eu.

This message was edited 10 times. Last update was at 01/06/2008 11:25:31

s4nchez wrote:
Sérgio, você pode explicar isso um pouco melhor? Eu uso TDD e testes unitários há alguns anos e não sinto isso. Quando programo eu sempre tento deixar as coisas fáceis de serem testadas, mas não lembro de ter abolido herança para isso.

Já ouvi diversas vezes por aí que herança deve ser evitada pois prejudica os testes unitários...

s4nchez wrote:
Programar com testes unitários me faz pensar um pouco diferente. Eu sempre assumo que um método que eu fiz pode ser repensado a qualquer momento e por qualquer pessoa. Novas regras de negócio podem surgir, restrições de performance podem surgir, uma idéia para melhorar o design pode surgir. Neste caso meus testes ajudam a especificar e assegurar a responsabilidade de cada método, já que eu não confio na minha memória depois que alguns dias e algumas centenas de código já passaram na minha mão. E se for outro programador que estiver alterando o código, quero que ele tenha esta mesma segurança que eu.

Colocando dessa maneira não tenho como discordar de vc. Se vc prevê e deseja tanta flexibilidade assim com o seu código e se vc tem certeza que os seus testes unitários vão garantir isso, então tudo bem. Com tanta flexibilidade assim, logo vc vai querer mudar a assinatura do método e terá que refazer também o teste unitário. E quem testa o teste unitário? Eu, pessoalmente, não gosto dessa metodologia de flexibilidade total, muda tudo, refaz tudo, etc. Eu vejo um sistema ou código como coisa séria, principalmente se ele está funcionando. Sair alterando tudo a torto e a direito exige uma ótima razão de ser. As regras do negócio não mudam a torto e a direito. Geralmente elas são evoluidas para acomodar novas funcionalidades e necessidades. Não são refeitas do zero, pelo menos não com essa frequência toda que vc sugere para justificar testes unitários. Apenas minha opinião. Há casos e casos, pessoas e pessoas, projetos e projetos, linguagens e linguagens, etc.

Na verdade, se rever a minha primeira mensagem, verá que eu entrei na discussão não para debater se testes unitários é bom ou ruim. Se vc o utiliza dessa maneira é claro que é bom. TDD é totalmente válido. O que eu discordei, e continuo discordando, é da afirmação de que não seria possível evoluir um sistema adicionando novas funcionalidades sem fazer uso de testes unitários. É sim, plenamente possível, estender sem quebrar um sistema OO minimamente bem-feito, e não deve ser os testes unitários que vão te garantir isso, mas um bom entendimento de herança, separação de responsabilidaes, polimorfismo, lógica básica (IF-THEN-ELSE) e disciplina. Pelo menos em Java...

saoj wrote:
Com tanta flexibilidade assim, logo vc vai querer mudar a assinatura do método e terá que refazer também o teste unitário. E quem testa o teste unitário? Eu, pessoalmente, não gosto dessa metodologia de flexibilidade total, muda tudo, refaz tudo, etc. Eu vejo um sistema ou código como coisa séria, principalmente se ele está funcionando. Sair alterando tudo a torto e a direito exige uma ótima razão de ser. As regras do negócio não mudam a torto e a direito. Geralmente elas são evoluidas para acomodar novas funcionalidades e necessidades. Não são refeitas do zero, pelo menos não com essa frequência toda que vc sugere para justificar testes unitários. Apenas minha opinião. Há casos e casos, pessoas e pessoas, projetos e projetos, linguagens e linguagens, etc.

Justamente porque também vejo código como coisa séria é que prefiro contar com o máximo de testes possível. Não pense no tamanho ou frequencia das mudanças. A questão é que a probabilidade de que um método nunca mude é bem baixa. Então por que não escrever alguns testes para ajudar se/quando essa hora chegar? Não é porque as mudanças são pequenas ou infrequentes que devemos tratá-las como menos importantes. Por isso em boa parte do tempo eu concordo com o Uncle Bob:

Bob Martin wrote:
..."I think that nowadays it is irresponsible for a developer to ship a line of code that he has not executed in a unit test"...

saoj wrote:
Na verdade, se rever a minha primeira mensagem, verá que eu entrei na discussão não para debater se testes unitários é bom ou ruim. Se vc o utiliza dessa maneira é claro que é bom. TDD é totalmente válido. O que eu discordei, e continuo discordando, é da afirmação de que não seria possível evoluir um sistema adicionando novas funcionalidades sem fazer uso de testes unitários. É sim, plenamente possível, estender sem quebrar um sistema OO minimamente bem-feito, e não deve ser os testes unitários que vão te garantir isso, mas um bom entendimento de herança, separação de responsabilidaes, polimorfismo, lógica básica (IF-THEN-ELSE) e disciplina. Pelo menos em Java...

Quem afirmou isso? É claro que é possível evoluir um sistema sem testes unitários. Afinal, é assim que a maioria dos sistemas ainda são tratados. Também é óbvio que um sistema bem-feito é mais fácil de se manter. Assim como é óbvio que os testes unitários não resolvem 100% dos problemas na hora de dar manutenção num sistema.

A questão é que um conjunto de testes bem feito ajuda MUITO. E aqui não falo apenas de testes de unidade, embora eles com certeza fazem parte da "safety net" que todo programador deveria tentar construir quando está programando.

saoj wrote:

s4nchez wrote:
Sérgio, você pode explicar isso um pouco melhor? Eu uso TDD e testes unitários há alguns anos e não sinto isso. Quando programo eu sempre tento deixar as coisas fáceis de serem testadas, mas não lembro de ter abolido herança para isso.

Já ouvi diversas vezes por aí que herança deve ser evitada pois prejudica os testes unitários...

Eu tambem já ouvi diversas vezes por aí que sair de casa a noite deveria ser evitado pq tem lobisomem na rua.

Pare com o achismo.

A resposta é simples: um projeto do zero é dificilimo de se inserir testes unitarios por causa do acoplamento entre as classes ja existentes.

Acho que o Sergio e pessoal do menta passou por isso: alguns comecaram a colocar testes unitarios la, e perceberam que eh uma tarefa quase impossivel. Foi o mesmo quando a gente fez o vraptor1 e quis fazer testes unitarios DEPOIS de ter feito muito codigo. Testes unitarios sao impossiveis quando voce nao tem uma "unidade".

É normal. Todo mundo passa por isso. Depois que usa testes unitarios num projeto do zero, é paixao a segunda vista!

Repare que todo mundo passou pelo mesmo efeito quando viu OO pela primeira vez: eu detestei. Quando vi que deveria usar interface em vez de heranca, tambem detestei a primeira vez. Pra mim isso é fase: todo programador bom passa pela epoca de odio ao teste unitario assim como odiou quando teve de parar de escrever arquivos de 10 mil linhas de codigo. Vamos sempre avancando.

Paulo Silveira wrote:Repare que todo mundo passou pelo mesmo efeito quando viu OO pela primeira vez: eu detestei. Quando vi que deveria usar interface em vez de heranca, tambem detestei a primeira vez. Pra mim isso é fase: todo programador bom passa pela epoca de odio ao teste unitario assim como odiou quando teve de parar de escrever arquivos de 10 mil linhas de codigo. Vamos sempre avancando.

Qual o problema de arquivos de 10mil linhas? Não vejo problema nisso. Minhas teclas preferidas são page-up e page-down. Muito mais rápido e produtivo que ficar trocando de arquivo o tempo todo.

Por que testes não são populares?

1º - Não se usa por quê não se sabe usar. Onde aprender? Nunca vi cursos sobre o assunto, documentação do JUnit, por exemplo, é palpérrima. E cadê os livros que ensinam passo-a-passo? Ou melhor, cadê os livros sobre o assunto?

2º - Não se usa por quê não se sabe aplicar testes unitários na fase de manutenção de projetos. Perguntam-se "Para quê a esta altura?", ou melhor, "como quebrar um monolito em partes manejáveis". O princípio de um teste unitário é que há unidades a se testar. A maioria dos projeots simplesmente não tem unidades, é um spaguetti code.

Refatoração depende de testes unitário, mas como se não temos eles em primeiro lugar?

3º - Preguiça. Falta de tempo. A empresa não tem experiência, muito menos cultura. Três letrinhas e tudo mais.

Ola

Bruno Laturner wrote:... cadê os livros sobre o assunto?

JUnit in Action de 2004 - excelente livro

Test Driven Development: By Example de 2002

Test Driven Development: A J2EE Example de 2005

Test-Driven Development: A Practical Guide de 2003

Pragmatic Unit Testing in Java with JUnit de 2003

TDD and Acceptance TDD for Java Developers de 2007

Java Testing and Design livro grátis disponivel em PDF desde 2004

Além destes livros, há muitos tutoriais que podem ser baixados livremente como este por exemplo: http://hotwork.sourceforge.net/hotwork/manual/junit/junit-user-guide.html

Outra fonte de aprendizado podem ser as centenas de projetos open source que usam testes unitários

E a documentação do JUnit não é "palpérrima" e muito menos paupérrima

Não é por falta de documentação que não se usa.

[]s
Luca

Não ter testes do início não é desculpa. Como qualquer um com alguns anos no mercado 90% do que eu fiz foi dar manutenção em alo já pronto e que não tinha testes. Testes funcionam muito bem nestes cenários, inclusive facilitando a nenharia reversa de módulos cujo "dono" foi demitido.

This message was edited 1 time. Last update was at 03/06/2008 09:27:21

Leonardo3001 wrote:
...
Primeiro, porque você tem um ÚNICA classe com cem, CEM!, métodos? Isso é design ruim, e provavelmente você não está utilizando herança, nem composição, nem orientação a objetos. Provavelmente é comportamento pra ser quebrado em algumas outras classes.
...

Já viu quantos métodos as classes do swing tem? O problema principal é que você nunca vai desenvolver nada puro e do zero que não use algum outro código já existente. Sempre vai usar alguma coisa já existente (Swing, EJB, ou até mesmo java.lang.*). Há partes do sistema que não foi você que fez, você não pode mudar e são engessadas. E um bom programador/arquiteto deve saber como conviver com isso e lidar com limitações. Imagine implementar JPasswordField extends Object via composição com JTextField, seria loucura. Além de que isso não funcionaria porque existem muitos lugares que iriam testar se o seu JPasswordField extends Component, JComponent ou qualquer coisa assim.

Ok, você pode falar que o swing não tem uma boa arquitetura, e eu concordo contigo. Mas aí está a diferença entre o bom arquiteto e o excelente arquiteto. O bom arquiteto sabe criar um design lindo. O excelente arquiteto sabe criar um design lindo mesmo usando componentes mal-projetados.

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