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

um monte de gente wrote:
um monte de coisas

Talvez até fosse possível usar-se apenas composição e não herança. O problema é que o java foi arquitetado desta forma e não será refatorado (backward compatibility). Logo, se você for programar em java deverá usar herança. Não gosta disso? Procure outra linguagem ou aprenda a lidar com isso. Não tem jeito.

Interfaces também tem lá seus problemas (que pouca gente cita). Precisa adicionar um método na interface ou mudar a assinatura? VOCÊ VAI QUEBRAR TODAS AS IMPLEMENTAÇÕES AO FAZÊ-LO! E que tal fazer uma outra interface que herde desta primeira acrescentando os métodos novos e colocar um @Deprecated nos que devem ser removidos? VOCÊ ESTARÁ FAZENDO GAMBIARRAS, E NÃO CONSERTANDO O PROBLEMA! Aliás, existem interfaces no java que são gambiarradas desta forma.

Acho que o maior problema em java é a falta de mixins. Se houvesse mixins, delegação seria algo mais simples e mais usado, mas talvez isso pudesse trazer a herança múltipla de classes. E antes que falem, sim herança múltipla de classes também tem algum propósito válido em alguns casos.

Outro problema no java é o backward compatibility. Embora ele seja vital para o sucesso do java, ele é ao mesmo tempo um câncer. As cagadas feitas na API estão lá para sempre!

Hehe, mas o tópico já se desvirtuou totalmente aqui

*bocejo*

Bom,
respondendo a pergunta original do topico, eu acho que os testes unitarios ainda não são tão populares pq ainda não se vende software se utilizando alguma cultura/metodologia que use testes.
A maioria do sistemas desenvolvidos ainda utilizam waterfall(classico ou modificado) aonde não existe a figura dos testes unitarios. Ou quando existe, vão ser feitos em uma "fase de construção de testes", ou seja, muito codigo ja foi produzido, dificultando a utilização de testes.
Eu pelo menos, so desenvolvi usando testes unitarios em projetos que utilizaram alguma metodologia agil. Pq nesses casos os testes eram vistos como devem, sem ser a bala de prata, mas sendo muito uteis dentro da maneira de desenvolvimento proposta.

[]´s

jgbt wrote:Bom,
respondendo a pergunta original do topico, eu acho que os testes unitarios ainda não são tão populares pq ainda não se vende software se utilizando alguma cultura/metodologia que use testes.
A maioria do sistemas desenvolvidos ainda utilizam waterfall(classico ou modificado) aonde não existe a figura dos testes unitarios. Ou quando existe, vão ser feitos em uma "fase de construção de testes", ou seja, muito codigo ja foi produzido, dificultando a utilização de testes.
Eu pelo menos, so desenvolvi usando testes unitarios em projetos que utilizaram alguma metodologia agil. Pq nesses casos os testes eram vistos como devem, sem ser a bala de prata, mas sendo muito uteis dentro da maneira de desenvolvimento proposta.

[]´s

Pois é. Imagine que você já tenha um código grande e peçam para criar o código de teste. É possível fazer isso de forma relativamente fácil? Se a resposta for não, está aí a causa deles não serem muito populares!

Pras consultorias é vantajoso não ter testes antes, porque o software vai dar trocendo milhoões de problemas, eles vão ficar extendendo o prazo de entrega eternamente e a consultoria continua ganhando lá R$ 150/hora por cada desenvolvedor, qual a vantagem pra eles entregam algo de qualidade dentro do prazo?

E infelizmente é esse tipo de empresa que pega a grande maioria (chute uns 90% até) dos projetos de softwares existentes no mercado.

Olá

victorwss wrote:Imagine que você já tenha um código grande e peçam para criar o código de teste. É possível fazer isso de forma relativamente fácil? Se a resposta for não, está aí a causa deles não serem muito populares!

Só que a resposta é sim. O próprio Mentawai criou testes assim.

Existem alguns softwares que fazem isto como o JUnit Factory por exemplo: http://www.agitar.com/

[]s
Luca

ramilani12 wrote:

pcalcado wrote:
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

Shoes nao entendi muito bem prq herança atrapalharia em testes por qual motivo?
No livro design Patterns (Head First) eles recomendam que de prioridade a composição em relação a heranca depois que li o captiulo abriu a minha mente em utilizar Herança

O que eu quis dizer foi que assim como composição pode atrapalhar testabilidade se mal feita a herança também. Herança por si só não atrapaha testabilidade, depende de como é feita.

victorwss wrote:
Parcialmente.
[...]
E eu respondi basicamente que pode acontecer em sistemas onde é obrigatório o uso de algum tipo de framework mal projetado (seja legado ou não). E mesmo assim JPasswordField extends JTextField extends JTextComponent extends JComponent extends Container extends Component extends Object. Ou seja, há um uso grande de herança
[...]
Basicamente, o problema é que você é obrigado a herdar esses métodos (mesmo se não os quiser), e EU não posso refatorar o swing para eliminar isso, ou seja, o framework ruim me forçou a herdar um caminhão de métodos.

No final crio a minha classe que herda de JPasswordField. EU estou usando a herança de forma propícia, MAS a minha classe tem centenas de métodos (porque estes foram herdados). E isto não é um design ruim que é minha culpa, e sim culpa do framework (no caso, neste exemplo, o swing e o AWT).

Acho que você não entendeu o que eu falei. Se você não pode refatorar o framework você ainda pode isolá-lo do seu código. Tem que implementar uma interface com mil métodos? Não faça a sua classe de negócios implementar isso, crie uma classe que implementa e atende os desejos profanos do framework mas delega para a sua classe de negócios, que é bem testada e seue bons princípios. Você até pode ter uma classe de 100 métodos mas apenas como 'cola' entre framework e seu código.

--

Agora eu não entendi como este debate caiu para herança. Além do fato de que herança por si só não prejudica testabilidade (design ruim prejudica, mas até aí...) esse papo de que 'bom design oo evita necessidade de testes' é tão furado hoje quanto sempre foi.

Uma recomendação para quem quer avaliar seus sistemas: http://testabilityexplorer.org/

saoj wrote:
Trocaríamos Herança por composição + interfaces + um monte de repetição de código. A vida poderia ser mais pura assim, visto que nós estaríamos de acordo com as nossas entidades superiores. Mas tenho minhas dúvidas se seria mais maravilhosa...

eh que java nao tem mixins ou algum sistema de delegates. eh um problema da linguagem mesmo.

a segunda solucao que voce apresentou eh incrivelmente mais elegante que a primeira, voce mesmo reconhece.

e nao eh repeticao de codigo, eh delegacao.... voce chama repetir codigo soh porque tem de copiar a assinatura de um metodo de uma interface?

Luiz Aguiar wrote:Pras consultorias é vantajoso não ter testes antes, porque o software vai dar trocendo milhoões de problemas, eles vão ficar extendendo o prazo de entrega eternamente e a consultoria continua ganhando lá R$ 150/hora por cada desenvolvedor, qual a vantagem pra eles entregam algo de qualidade dentro do prazo?

E infelizmente é esse tipo de empresa que pega a grande maioria (chute uns 90% até) dos projetos de softwares existentes no mercado.

Exatamente isso.
Conversando com um amigo que é gerete de projetos de uma consultoria ele me disse isso. Apesar de atrasos e encomodações, os projetos eram extremamente lucrativos, por isso a consultoria continuava a vender dessa maneira.
Essa mudança na verdade deveria partr do cliente, exigindo mudanças. Mas os proprios clientes tem medo dessa mudança. Na maioria das vezes o cliente exige saber quanto o sistema vai custar e quando vai ser entregue. Mesmo sabendo que dificilmente essas metas irão ser atingidas.

[]'s

Paulo Silveira wrote:Sergio, usar heranca eh tao ruim quanto blocos de catch vazios, instanceofs em vez de polimorfismo, switches, metodos longos, classes so com getters e setters, etc....

A única coisa que eu mudaria neste teu comentário é que eu diria: usar herança errado.

JavaGuru Membro desde: 18/05/2006 20:04:34 Mensagens: 256 Offline

Existe alguma linguagem (OO) cuja sintaxe dê ênfase na troca de mensagens?

Sem herança, sem classes, sem interfaces... Com duck typing, talvez. Ia ser interessante.

bzanchet wrote:Existe alguma linguagem (OO) cuja sintaxe dê ênfase na troca de mensagens?

Sem herança, sem classes, sem interfaces... Com duck typing, talvez. Ia ser interessante.

Se você não usar herança em Ruby vai ter exatamente o que precisa. Aliás, raramente se precisa de herança em algo como Ruby.

JavaGuru Membro desde: 18/05/2006 20:04:34 Mensagens: 256 Offline

Mas ruby tem classes (e métodos estáticos).

Seria legal se tivesse pattern matching também. E se 'function' e 'method' e 'def' e 'class' não significassem nada de especial. Acho que um novo vocabulário faria mais bem do que mal (eg: bdd vs tdd

) - mantem-se o termo 'object', reinventa-se o resto (dando ênfase em "troca de mensagens", não em "funcionalidade").

E qual o problema em ter métodos e atributos de classe já que a classe em si é um objeto?

JavaGuru Membro desde: 18/05/2006 20:04:34 Mensagens: 256 Offline

Não, nenhum. Me referia ao vocabulário, apenas..

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