[quote=pcalcado]Exato, e elas sao complementares.
Ele nao usa porque nao precisa. [/quote]
Poxa, dessa eu não sabia, que existia gente que não precisa de testes 
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.
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.
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.
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
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
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?
[quote=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.
[/quote]
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.
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.[/quote]
Sim… é exatamente isso!!! Motivação pega.
[quote=Luca]Olá
(…)
[]s
Luca[/quote]
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…
fw