Knuth tem algumas opiniões controversas e polêmicas sobre unit testing, extreme programming, open source e programação concorrente.
O entrevistador sabe atacar as questões de maneira elegante, mas faz algumas ótimas perguntas, tais como: “Se você não usa unit test, como garante que a sua máquina MMIX funciona corretamente?”. Algumas respostas de Knuth indicam que a maior parte do tempo ele programa sozinho, isso sem dúvida impacta em muitas de suas opiniões. Algumas dificuldades que nós encontramos no dia a dia certamente não são vividas por um programador solitário.
Gostei do artigo e com certeza a opinião dele é importantíssima, por mais polêmica que seja.
O que eu acho estranho é o texto comentado no blog do Phillip, que diz que teste unitário é bom vc fazer, afinal você não é Don Knuth.
Se por acaso o Knuth tivesse dito: “adoro testes unitários” , o discurso seria: " tão vendo? o cara que é um gênio usa, pq vc não usa?".
Ou estou enganado?
dreamspeaker
boaglio:
… O que eu acho estranho é o texto comentado no blog do Phillip, que diz que teste unitário é bom vc fazer, afinal você não é Don Knuth.
Se por acaso o Knuth tivesse dito: “adoro testes unitários” , o discurso seria: " tão vendo? o cara que é um gênio usa, pq vc não usa?".
Ou estou enganado?
Acredito que vc não esteja enganado não. Quotes são como estatisticas, as pessoas interpretam como quiserem. Só abrir qualquer jornal por aí.
Mas eu levo mais a sério a primeira interpretação do que a segunda. Imagina se gente como Don Knuth e Martin Fowler pulassem juntos do 20o andar…
pcalcado
Não entendi sua dúvida. Sim, eu citaria, assim como envie pelo twitter a parte que ele fala que só confia no Linux para fazer seu trabalho e quem não concorda deveria postar seus argumentos. Como o caso é contrário quem posto argumentos foi quem defende testes unitários.
boaglio
pcalcado:
Não entendi sua dúvida. Sim, eu citaria, assim como envie pelo twitter a parte que ele fala que só confia no Linux para fazer seu trabalho e quem não concorda deveria postar seus argumentos. Como o caso é contrário quem posto argumentos foi quem defende testes unitários.
Eu acho que o dreamspeaker já respondeu, cada um interpreta a coisa a seu favor mesmo.
Eu sou favorável ao uso de testes unitários e o Knuth claramente não é.
Criar uma lógica que leve o fato dele não gostar de testes unitários à conclusão de que você deva usá-los ficou meio estranho pra mim.
pcalcado
Como voce inferiu essa logica? O meu ponto eh: Don Knuth nao precisa de testes unitario. Voce nao eh Don Knuth .
Alias, cade os Knuth facts?
boaglio
Eu acredito que ocorreu uma das duas possíveis opções:
1 :arrow: Knuth não gosta de testes unitários
2 :arrow: Knuth gosta de testes unitários
Respostas dos defensores de testes:
1 :arrow: Knuth não precisa de testes unitários. Você não é o Knuth .
2 :arrow: se o Knuth que é um gênio usa, por que vc não usaria?
pcalcado
Exato, e elas sao complementares.
Ele nao usa porque nao precisa. Se ainda nao precisando ele usasse seria mais um ponto positivo.
saoj
Eu poderia argumentar pela 1000 vez que teste unitário não é essa coisa maravilhosa, fundamental, o ar que vc respira, etc e tal, mas isso só criaria mais um flame cansativo e desnecessário. Quem quiser usar testes unitários em tudo, até em getters and setters, use e seja feliz. Se isso te deixa produtivo e feliz então isso é MUITO importante para você.
Um recém-contratado no seu primeiro dia de emprego fez as seguintes perguntas para o chefe:
Qual o sistema operacional que devo usar?
R: Use o que te deixa mais feliz e produtivo.
Qual é a IDE que time usa?
R: Use a que vc quiser e a que te deixa mais produtivo.
Qual é a política de testes unitários?
R: Faça o que vc quiser, só não entregue código com bugs.
Devo usar Office ou OpenOffice?
R: Vc já terminou o seu projeto? Que tal parar de fazer perguntas inúteis e começar a trabalhar?
Minha opinião é que essa discussão é improdutiva.
No mundo Java acho que tirando uma ou outra classe de infra-estrutura (BufferUtils, ByteUtils, etc.), o restante não faz muito sentido de ser testado via testes unitários. Há diversas outras maneiras mais prazerosas e não automatizadas de fazer a coisa. Sem contar que o melhor é sempre previnir do que remediar. Se vc programa de qualquer jeito e se vc não revisa o seu código pelo menos 5 vezes a cada etapa, então testes unitários podem te ajudar bastante. Programe para não cometer nenhum erro, ou o mínimo de erros possíveis. E quando cometer um erro (sim eles acontecem), descubra e corrija-o rapidamente.
No mundo Ruby me parece que teste unitário cai bem, pois como já dizia o homem aranha “with great power comes great responsability”.
Java não é uma linguagem poderosa. Com java é difícil vc dar um tiro no próprio pé. Tem que fazer um grande esforço.
Já com Ruby isso é plenamente possível, seja por um conhecimento mediano da linguagem, desatenção ou estupidez mesmo.
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.
PS: Eu estou para começar a desenvolver alguns testes unitários para o meu último projeto em Ruby. Só não sei ainda se farei testes unitários ou funcionais, mas eu realmente gostaria de ter alguma coisa automatizada.
Agora se quiserem criar um flame, dizendo que quem não respira testes unitários não é profissional, blah, blah, blah, tudo bem. Só que dessa vez eu não vou participar, pois tenho andado realmente muito ocupado. Espero que apareça outra figura querendo argumentar a favor desse meu ponto de vista. Último caso chamem o Knuth.
Paulo_Silveira
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.
louds
Paulo Silveira:
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.
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.
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.
Paulo_Silveira
Oi louds, voce me concluiu mal… nao sou a favor tambem. To dando so uma possivel desculpa pela qual o Knuth ainda nao percebeu a real necessidade de unit tests. Nao estou de maneira alguma aprovando a opiniao dele!!! Desaprovo essa e a ideia de que multi core em casa nao tem utilidade.
Daniel_Quirino_Olive
O dia em que as pessoas começarem a entender que TDD e unit tests menos a ver com testes em si e mais a ver com design, boa parte das threads do GUJ vão perder sentido
Paulo_Silveira
Daniel Quirino Oliveira:
O dia em que as pessoas começarem a entender que TDD e unit tests menos a ver com testes em si e mais a ver com design, boa parte das threads do GUJ vão perder sentido
Pois é. Varios momentos eu leio codigo e penso “se tivesse unit test, nao estaria abrindo esse FileInputStream aqui no meio dessa classe”. TDD leva ao desacoplamento.
O dia que eu tiver trabalhando isolado, numa plataforma que eu inventei, num sistema que eh praticamente 99% teoria computacional, eu paro de escrever unit tests
louds
O dia que eu puder mandar cheques de valores exponenciamente crescentes para cada bug encontrado no meu sistema também paro de escrever testes.
Por exemplo, se eu começar com um cheque 2 reais e aparecerem uns 39 tópicos sobre bugs no fórum do meu projeto de fundo de quintal, vou torrar 549.755.813.888 no último deles. Provavelmente nem vendendo todos jatinhos do meu chefe vou conseguir pagar esse valor se compensarem.
Um comentário meio nada a ver com o assunto mas que tem a ver como minha relação com o Dr Knuth.
Confesso que nas primeiras leituras que fiz do Knuth tive imensa dificuldade para entender. Naquela época não tinha nada pronto. Se você quisesse um sort, tinha que escrever o seu na raça. Vivíamos na época em que busca binária era novidade e tabelas hash prometiam ser a última Coca Cola do deserto. Fui atrás dos 3 livros do Knuth como a solução dos meus problemas. Como eram livros muito caros para importar, ia até a USP para estudá-los. Vários capítulos me exigiram ler mais de uma vez.
Se eu tivesse estudado o Knuth depois de algum outro livro mais básico ou se tivesse tido um professor para me explicar algumas dúvidas por falta de base teórica, talvez pudesse ter lido em muito menos tempo.
E ainda achava muito chato de ler os algorítmos escritos naquele assembler maluco.
Confesso que não sei de nenhuma atividade não acadêmica do Dr Knuth. Acho que no fundo ele não passa de um nerd que envelheceu.
Abaixo um dos cheques de US$ 2.56 (equivalente a 256 pennies em 1 dolar hexadecimal) que ele deu para os que acharam um erro tipográfico em seus livros.
Ele fez muitos cheques que somavam até março de 2005 um total de US$ 20 mil, mas poucos deles foram depositados porque quem achou algum erro preferiu guardar o cheque como troféu. Como alguém assinou no Slashdot:
Intelligence: Finding an error in a Knuth text.
Stupidity: Cashing that $2.56 check you got.
[]s
Luca (velho, mas fã de testes unitários)
renatosilva
pcalcado:
Exato, e elas sao complementares.
Ele nao usa porque nao precisa.
Poxa, dessa eu não sabia, que existia gente que não precisa de testes
rodrigoy
Vou compartilhar uma coisa com vocês. Estive programando sozinho um software para controle de projetos de engenharia mecânica e civil. Bem, numa primeira fase que era um protótipo, passei praticamente 4 meses programando sozinho. Como era um protótipo logicamente não tinha testes unitários e nem qualquer teste, pois era só uma prova de conceito (a gente nem sabia se o projeto iria de fato rolar).
Bem, quando virou um projeto de verdade tive que saldar esse débito técnico e escrever os testes junto com uma equipe pequena. Não foi uma das tarefas mais gostosas não.
Independente disso, agora estou sozinho de novo. De fato, faz uns 3 meses que estou sozinho. Realmente É BEM MAIS FÁCIL programar sozinho. Você pode fazer integração contínua só 1 vez por dia. Pode até esquecer de fazer algumas vezes na semana. Eu estou escrevendo os testes antes mas por ter me acostumado a isso. Quando você está sozinho é menos comum os testes quebrarem comparado do que quando você está em equipe.
É mais fácil gerenciar débito técnico quando você está sozinho.
cv1
Em compensacao, eh bem mais dificil se manter motivado, revisar o codigo pra descobrir onde estao problemas em potencial (ou partes que podiam ser melhoradas), e vc aprende bem menos.
pcalcado
E quando você muda o coração da sua aplicação você sabe que não matou as outras partes
E quando você tem uma idéia você escreve num teste ao invés de um pedaço de papel
E você ganha user stories bem documentadas gratuitas
E daqui há quinze dias, quendo o projeto der uma desafogada e você tiver tempo para seus pets de novo, voc6e vai conseguir continuar e não escrever tudo de novo
E quando sair alguma coisa do seu pet projeto você vai poder compartilhar cm alguém que pode começar a entender apenas lendo seus testes
E… por ai vai.
Dieval_Guizelini
Senhores,
me desculpem a sinceridade, mas
eu trabalho com várias pessoas que são “geniais”, e posso assegurar que a maior parte dessas pessoas que trabalham com computação científica jamais leram qualquer coisa sobre testes unitários e o que as tornam diferentes são a capacidade de criar novas técnicas e aplicar técnicas as vezes elementares em problemas que ninguém tinha ousado resolver. Em suma, a maior parte dos códigos estão sendo escritas em C, prolog, pseudo-código, matlab etc. A comprovação da solução são realizados com cálculos matemáticos e experimentais…
Neste contexto, que é o universo que o Dr Knuth faz parte, ninguém quer saber se ele usa a metodologia A ou B, se ele escreve com a ferramenta X ou Y e simplesmente querem saber o que eles estão aprontando… para o mundo começar a utilizar daqui uns 10 ou 20 anos.
Novamente, não acredito que as técnicas e argumentos apresentados até aqui melhore significativamente o trabalho dessas pessoas… Eu acredito que é absolutamente ERRADO assumir que qualquer técnica ou metodologia pode ser aplicadas a qualquer ou todos tipos de problemas e soluções.
Acho que o entrevistador foi infeliz em não ver que o Dr Knuth não faz parte do grupo de pessoas que usam a tecnologia para desenvolver sistemas corporativos e que ele na realidade faz parte de um reduzido time que CRIA nova técnicas, que talvez venhamos utilizar um dia.
Acho que devemos criticar menos as pessoas pelo que elas usam ou pensam e mais pelo que elas fazem ou deixem de fazer…
Knuth é o pai de toda base algoritmica e lógica computacional, acho que devemos respeitar melhor a visão dele.
fw
Luca
Olá
Concordo em parte e acrescento algumas considerações e ressalvas:
O uso de testes unitários não é igual em todos os ambientes de programação. Em Ruby, por motivos que não vou me alongar, são necessários muito mais testes unitários do que em Java. Já em Java se usa muito mais do que em C/C++, Fortran e outras, tanto por necessidade como por hábito.
Hoje em dia há bibliotecas para testes unitários do tipo JUnit para praticamente todas as linguagens. Como exemplo cito Fortran: FUnit (hospedado no site da NASA) e Fruit do sourceforge. Nem sempre estas bibliotecas são tão evoluídas como as do Java e do Ruby. E nem sempre valem o esforço de aprender a usar para trocar pelos tradicionais meios de assegurar correção do código. Há gente que programa em Fortran que preferia a opção de logar tudo que foi feito e conferir o log na mão. Tenho programas antigos do início da década de 80 que era assim que se faziam testes unitários.
Quando a gente trabalha tentando fazer um algoritmo funcionar, algumas vezes o problema do algoritmo está na teoria. Acreditem ou não, mas no meu mestrado levei um mês para retirar um bug de um algoritmo porque naquela época não havia google e eu precisava passar horas e horas na biblioteca fuçando livros atrás de alguma justificativa do porque aquela condição matemática falhava. Assim, pelo menos no meu tempo, era comum no ambiente científico, o cara escrever um código tosco só como prova de conceito e só depois de testado isoladamente refatorar para algo que podia ser usado dentro de um sistema. Era uma éspecie de teste unitário tentando fazer a fórmula funcionar isoladamente.
[]s
Luca
peczenyj
Luca, que tal postar no seu blog sobre esse bug (nem q seja de forma resumida)?
Hoje em dia, como vc resolveria com o google?
louds
rodrigoy:
Vou compartilhar uma coisa com vocês. Estive programando sozinho um software para controle de projetos de engenharia mecânica e civil. Bem, numa primeira fase que era um protótipo, passei praticamente 4 meses programando sozinho. Como era um protótipo logicamente não tinha testes unitários e nem qualquer teste, pois era só uma prova de conceito (a gente nem sabia se o projeto iria de fato rolar).
Bem, quando virou um projeto de verdade tive que saldar esse débito técnico e escrever os testes junto com uma equipe pequena. Não foi uma das tarefas mais gostosas não.
Independente disso, agora estou sozinho de novo. De fato, faz uns 3 meses que estou sozinho. Realmente É BEM MAIS FÁCIL programar sozinho. Você pode fazer integração contínua só 1 vez por dia. Pode até esquecer de fazer algumas vezes na semana. Eu estou escrevendo os testes antes mas por ter me acostumado a isso. Quando você está sozinho é menos comum os testes quebrarem comparado do que quando você está em equipe.
É mais fácil gerenciar débito técnico quando você está sozinho.
Nos meus projetos solo eu sou muito mais desleixado com o código que escrevo e confio muito mais nos testes que normalmente no trabalho. Faço isso pois é muito mais produtivo e divertido. Nem sempre escrevo testes unitários pois, devido ao desleixo, estou mais preocupado com o resultado final então me foco em testes funcionais. Ultimamente só tenho escrito software fora da curva, pois para quase todos todos eles é mais fácil escrever testes de aceitação que unitários, o que explica meu foco.
rodrigoy
Em compensacao, eh bem mais dificil se manter motivado, revisar o codigo pra descobrir onde estao problemas em potencial (ou partes que podiam ser melhoradas), e vc aprende bem menos.
Sim… é exatamente isso!!! Motivação pega.
Dieval_Guizelini
Luca:
Olá
(…)
[]s
Luca
Concordo Luca, e acho que para os “normais” não existe justificativa para não se fazer uso destas técnicas…
Passei por experiências similares, como os bugs de ponto flutuante da biblioteca do MS-C 5…
até onde me recordo, um bom depurador ajudava nestes casos, naturalmente se os autores da biblioteca tivessem usados os testes unitários, provavelmente os bugs não existiriam…
Eu adorava o Turbo Debugger da Borland, e o depurador do clipper era muito bom, mesmo nas primeiras versões…
Mas, o que me chamou a atenção foi o fato da discussão ocorrer se Knuth usa ou não testes e se ele tem ou não que usar essa metodologia…
Knuth é para mim como o nosso glorioso Oscar Niemeyer, que com 100 anos de vida continua CRIANDO e não se limita as dificuldades que eventualmente uma estrutura pode apresentar… ele quebra o tradicional, faz a diferença… é obvio que depois que ele faz os rascunhos, precisam de um exército de pessoas para viabilizar o projeto… mas e dai? vamos dizer ao genio para parar, para se restringir aos recursos básicos… para desenhar prédios quadrados…
