Composicao ao invés de heranca mesmo quando temos uma relacao IS-A

[fantomas]

saoj, desculpe a pegunta direta, mas por que vc não gosta dos testes?

P.S Ótimo topico.

flws

[saoj]

[quote=fantomas]saoj, desculpe a pegunta direta, mas por que vc não gosta dos testes?

P.S Ótimo topico.

flws[/quote]

Melhor deixar essa discussão para outro tópico, né? Se vc googlar vai encontrar uns pouquíssimos gatos pingados que pensam como eu. Eu sou a favor de teste automatizado. Acho bem legal. Mas teste automatizado (feito via JUnit) é MUITO DIFERENTE de teste UNITÁRIO.

O melhores sistema que vi na vida não tinha quase nenhum teste unitário. Os piores estavam cheios de testes unitários, daqueles que fazem o build demorar 20 minutos rodando os 1123123123 testes.

Um maluco que achei no Google: http://www.contrariansoftware.com/2008/11/unit-testing-sucks.html

There is also the theory that unit testing ensures that, when you change some code, it doesn?t break other code. Well that?s only true if it breaks something in a way anticipated by the unit test. But you have to ask yourself, why is your project architected in such a way that it?s so susceptible to a small code change in one place breaking code elsewhere? No, it?s not because of ?tight coupling? or failure to follow object oriented design patterns. It?s because of bad planning, and bad developers who confuse unit testing with quality coding. It?s because too many developers are working on the same parts of the project. Too many programmers spoil the code just as surely as too many cooks spoil the broth. The only way to create a quality big project is to divide it up into independent small projects.

[fantomas]

Oi saoj, valeu pela resposta.

Concordo com vc, este papo acho que vale um outro tópico.

Fiz a pergunta porque vc foi o primeiro (que eu vi) que teve coragem de falar isso neste forum e a idéia me deixou bem curioso tambem. Quando comecei a programar haviam bem menos recursos e ferramentas em termos de software do que hoje para auxiliar na produção de códigos; debuggers acho que nem existiam só para ter ideia. Quem queria um código com mais qualidade deveria se valer de um esforço próprio lançando mão de conhecimentos técnicos mais consistente, sem falar da experiencia.

Não tenho resistencia em utilizar testes, eu até utilizo mas não como vc diz que é feito por aí de forma ostensiva a ponto de criar scripts de execução automática e etc…apenas em coisas bem pontuais. Eu até me culpava um pouco por ainda não aplicar isto (força do modismo), até o dia de hoje rsrsrs.

Vou fazer algumas pesquisas sobre o assunto.

Abraços

[YvGa]

[quote=fantomas]Oi saoj, valeu pela resposta.

Concordo com vc, este papo acho que vale um outro tópico.

Fiz a pergunta porque vc foi o primeiro (que eu vi) que teve coragem de falar isso neste forum e a idéia me deixou bem curioso tambem. Quando comecei a programar haviam bem menos recursos e ferramentas em termos de software do que hoje para auxiliar na produção de códigos; debuggers acho que nem existiam só para ter ideia. Quem queria um código com mais qualidade deveria se valer de um esforço próprio lançando mão de conhecimentos técnicos mais consistente, sem falar da experiencia.

Não tenho resistencia em utilizar testes, eu até utilizo mas não como vc diz que é feito por aí de forma ostensiva a ponto de criar scripts de execução automática e etc…apenas em coisas bem pontuais. Eu até me culpava um pouco por ainda não aplicar isto (força do modismo), até o dia de hoje rsrsrs.

Vou fazer algumas pesquisas sobre o assunto.

Abraços[/quote]

Hmm, nao tao rapido.

There is also the theory that unit testing ensures that, when you change some code, it doesn?t break other code. Well that?s only true if it breaks something in a way anticipated by the unit test.

Esta pseudo seguranca é apenas um dos beneficios dos testes, nao o maior deles. E mesmo que ele tenha quebrado de uma forma que voce nao havia previsto e o erro so tenha sido descoberto em producao, ainda assim, agora voce vai poder adicionar mais um teste e garantir que esta falha nao ocorrera novamente. Sem os testes voce nao garante que daqui algum tempo alguem fara uma alteracao que resultara no mesmo erro.

But you have to ask yourself, why is your project architected in such a way that it?s so susceptible to a small code change in one place breaking code elsewhere? No, it?s not because of ?tight coupling? or failure to follow object oriented design patterns. It?s because of bad planning,

Teste faz parte do planning. “Planning” em grande parte das vezes é especulação. De fato os testes por si só nao levam a um bom código, mas nao consigo imaginar de que forma eles possam atrapalhar quem tem esta capacidade.

and bad developers who confuse unit testing with quality coding. It?s because too many developers are working on the same parts of the project. Too many programmers spoil the code just as surely as too many cooks spoil the broth. The only way to create a quality big project is to divide it up into independent small projects.

É dificil de responder a uma “acusação” dessas. “Too many”, “big project”? Quanto é too many? O q é um big project? Se voce disser que dez programadores trabalhando em códigos bem proximos, isto é too many. Se voce disser que dois ou tres, isto é o ideal.

Os testes são uma forma de projetar o código. Se vai ficar bom ou ruim é uma outra historia, isto vai depender mais dos programadores do que dos testes. Mas o que eu tenho visto é que programadores que não conseguem projetar bons códigos, não são capazes de manter os testes por muito tempo. Porque sem duvidas, os testes tem contra si, a necessidade de um cuidado muito grande ou eles viram uma massa disforme que toma mais tempo para ser manuseada do que o proprio codigo da aplicacao. E ai eles perdem o sentido.

Agora, este paragrafo me pareceu obra de alguem que defende o big design upfront, que gosta de dividir bem o trabalho e planejar com cuidado.

Mas e as consequencias disso? Quando voce tem o trabalho “bem dividido”, isto é, cada um trabalhando pacientemente em uma coisa separada, voce leva mais tempo entre o inicio e o fim de uma funcionalidade. Quando voce tem dois ou tres programadores trabalhando numa mesma parte do código voce vai ter o teu processo cuspindo funcionalidade pronta para ser testada, integrada e entregue em ciclos muito curtos. O que tem muito mais valor do que um planejamento especulativo que cria a ilusão de qualidade.