Neste episódio do .Net Architects Podcast Alexandre Valente, Fabio Margarito,Giovanni Bassi e Victor Cavalcante falam sobre TDD (Test Driven Development), esse podcast nasceu do post “TDD não existe” escrito por Giovanni Bassi e gerou uma ótima discussão.
Alguns dos temas abordados foram:
- Onde e quando aplicar TDD faz sentido, quando TDD pode ser considerado SDD (Specification Driven Development ou Specification Driven Design).
- Quando utilizar Baby Steps .
- Devemos ou não aplicar testes em toda a aplicação inclusive interface gráfica.
- Custo x benefício do TDD.
Links do podcast:
- TDD não existe
- .Net Architects Dojo
- Test Driven Development: By Example – Kent Beck
- Refactoring: Improving the Design of Existing Code – Martin Fowler
- Coding Dojo
- Blog do Alexandre Valente
- Blog do Fabio Margarito
- Blog do Giovanni Bassi
- Blog do Victor Cavalcante
Ouça o podcast:
#1 by Herberth Amaral on January 24th, 2010
Vocês falaram sobre testes de view e o Giovanni disse que testa seu código de view quando trabalha com WPF e Silverlight. Ultimamente eu esotu com alguns problemas para testar JavaScript. Algum de vocês já teve experiência com testes para código JS?
P.S: Parabéns pela iniciativa e pelo podcast!
#2 by Jefferson Fernandes on March 29th, 2010
Na verdade, pelo que pude interpretar, ele disse que NÃO testa View, nem XAML, nem WinForm, nem ASPX…
#3 by Daniel Cazé on January 25th, 2010
Muito bom.
Desde o post “PodCasts interessantes” eu passei a escutar o podcast de vocês.
Espero o proximo anciosamente
#4 by Felipe Fujiy on January 28th, 2010
Muito bom o podcast, assim como os outros. E também já estou esperando o próximo. Abraços.
#5 by Alexsandro on February 1st, 2010
Muito bom artigo comentado por vcs.
Eu tenho uma pergunta:
O TDD nao seria bom ser feito por uma outra pessoa em conjunto do programador talvez um analista de teste?
#6 by Leonardo Aguiar on February 22nd, 2010
Talvez eu não tenha entendido bem, mas ouvindo o podcast me pareceu que o TDD para ser realmente útil, o desenvolvedor deve ter uma visão do sistema como um todo, e não em suas partes. É isso mesmo?
Se for, como fica nos casos em que o desenvolvedor acabou de chegar na equipe, e ainda não conhece o sistema como um todo, e a documentação do mesmo não é das melhores, ou não é suficiente.
Vale a pena para o profissional, no caso o desenvolvedor, aprender o TDD de verdade?
#7 by Ítalo Brilhante on May 4th, 2010
Olá pessoa, primeiramente parabéns pelo podcast, muito interessante a iniciativa. Eu sou analista de testes, e minha monografia fala sobre TDD.
Respondendo a algumas perguntas:
Alexsandro: Uma companhia interessante seria outro desenvolvedor, um que saiba aplicar o TDD, para ajudar. O analista de testes também pode ajudar, mas caso ele não saiba programar, pode ficar um pouco complicado, pois a idéia do TDD na verdade, é fazer o desenvolvedor pensar na solução antes de desenvolver, onde ele pode encontrar problemas de especificação. O analista de testes vai estar focado em modelar casos de teste para achar defeitos, então foge um pouco do assunto.
Leonardo: Acredito que valha sim. Claro que com uma documentação de qualidade, fica mais fácil aplicar o TDD. Creio que quanto mais os desenvolvedores saibam TDD, mais fácil ficará de resolver este problema, pois vai ter alguém para auxiliar. É como ter um programador júnior que tem problemas em utilizar o padrão Singleton. Acredito que boa parte dos colegas de trabalho poderão ajudá-lo.
Tenho feito estudos com o TDD sendo aplicado no desenvolvimento de um SAD, e os resultados estão sendo ótimos, pois os problemas são encontrados na especificação, reduzindo o custo das mudanças ($$$) e removendo defeitos.
#8 by Guilherme Oenning on May 15th, 2010
Olá,
No final do podcast o Vitor comenta sobre o artigo que diz que o programador é mais produtivo quando está corrigindo um bug do que quando está implementando uma feature nova.
O que eu pude enteder disso é que quando você está trabalhando em um bug, você tem um ponto final. Você sabe exatamente quando parar de codificar, que é quando o bug sumir. Ao implementar uma feature nova sem TDD, quando você acaba? Quando estourar o prazo? Quando você achar que não tem mais nada para codificar? Quando você testou a feature 10x seguidas e não deu nenhum erro?
Ao fazer uma feature usando TDD, você sabe exatamente quando parar, que é quando não há mais testes para escrever.
Foi isso que eu entendi do comentário.
Gostei também do comentário que fizeram do TDD no Ruby. Ainda não tinha caido a ficha aqui de que no Ruby, sem TDD, seu código fica muito mais vulnerável a erros.
De resto, parabéns, ficou muito bom.
#9 by Antonio Castro Jr on June 26th, 2010
Eu não sei, mas o Alexandre bateu forte na questão do aumento do custo do projeto por causa de pareamento e TDD. Se voce desenvolve, entrega pro cliente e não precisa mais manter o código ele tem razão. O Cliente é que fique com o pepino. Mas as coisas não são bem assim.
Desenvolvedor nas fábricas de softwares não treinam – coding dojo neles.