[quote=Paulo Silveira][quote=saoj]
Teste unitário vai depender do time, do projeto, da linguagem, do estilo e do preço do chá de camomila. Quem quiser usar use-o e seja feliz.
[/quote]
Knuth nao trabalha em time. Escreveu o Tex e o SGB praticamente sozinho. O cara é um pistoleiro :).
Mas sobre a sua opiniao de que unit test nao é essencial, todos ja sabemos. A minha continua sendo de que é. Nada de flame, cada um com sua opiniao.
Se voce ja nao comecou com teste unitarios, vai ver que eh SUPER dificil colocar os testes unitarios depois… porque a chance eh grande do codigo ja estar altamente acoplado, o que dificuldade testar a “unidade”, ja que a unidade passou a ser varias classes, em vez de uma unica, o que forca voce a ir para testes funcionais, em vez de testes unitarios. Esse caminho é natural. Testes unitarios sem TDD fica bem dificil de aplicar mesmo.
[/quote]
Paulo, o problema do Knuth é que algumas práticas simplesmente se solidificam na cabeça das pessoas depois de décadas e simplesmente não tem como mudá-las. Testes unitários e/ou automatizados é uma coisa que foi criada em meados da década de 80. Não existia um PunchCardUnit quando o Don Knuth era jovem.
Porém hoje ninguém mais programa da forma dele, principalmente pq as ferramentas são completamente diferentes, como linguagens, runtime, poder computacional e tudo mais.
Porém acho errado pensar que só pq o cara é pistoleiro e programa sózinho ele não precisa usar testes automatizados. Uso bastante nos meus pet projects pq eles são uma forma fácil de medir meu progresso. Não sou fã de fica no papel de QA guy daquilo que faço.
Hoje a única justificativa que eu tenho para aceitar programadores profissionais que não escrevem testes é síndrome de estocolmo, pq existe evidencia não estatística de que é uma mais estritamente superior de se trabalhar. Código sem teste é feito documentação impressa, só vale na hora, depois é ladeira abaixo.
Uma pessoa tem que ser muito ingênua, ou nunca ter trabalhado em times grandes (onde grande são uns 5 programando), para achar que é possivel manter a qualidade original do software ao longo do tempo fazendo revisão localizada de código e sendo cowboy-coder.
Na minha experiência, com times grandes ou projetos longos, a qualidade ao longo do tempo é estritamente um fator da quantidade de testes automatizados. Código sem testes irá quebrar pois nenhuma empresa consegue ir aumentando o time de QA para o mesmo projeto ao longo do tempo indefinidamente.
Não defendo escrever testes para um one-shot shell script, mas para qualquer coisa significativa é indispensável.
