Podcast 9: TDD não existe

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:

13 thoughts on “Podcast 9: TDD não existe”

  1. 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. Muito bom.

    Desde o post “PodCasts interessantes” eu passei a escutar o podcast de vocês.

    Espero o proximo anciosamente

  3. 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?

  4. 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.

  5. 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.

  6. 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.

Leave a Reply

Your email address will not be published. Required fields are marked *