ti-enxame.com

Desenvolvimento orientado a testes - me convença!

Sei que algumas pessoas são grandes defensoras do desenvolvimento orientado a testes. Eu usei testes de unidade no passado, mas apenas para testar operações que podem ser testadas facilmente ou que acredito que possivelmente estejam corretas. A cobertura completa ou quase completa do código parece demorar muito tempo.

  1. Para quais projetos você usa o desenvolvimento orientado a testes? Você o usa apenas para projetos acima de um determinado tamanho?
  2. Devo usá-lo ou não? Me convença!
30
Casebash

Ok, algumas vantagens para o TDD:

  1. Isso significa que você acaba com mais testes. Todo mundo gosta de ter testes, mas poucas pessoas gostam de escrever . Criar gravação de teste em seu fluxo de desenvolvimento significa que você acaba com mais testes.
  2. Escrever em um teste obriga a pensar na testabilidade do seu design, e o design testável é quase sempre um design melhor. Não está totalmente claro para mim por que isso acontece, mas a minha experiência e a da maioria dos evangelistas do TDD parece confirmar isso.
  3. Aqui está um estudo dizendo que, embora o TDD demore um pouco mais para escrever, há um bom retorno sobre o investimento, porque você obtém um código de melhor qualidade e, portanto, menos bugs para corrigir.
  4. Dá confiança na refatoração. É uma ótima sensação poder mudar um sistema sem se preocupar em quebrar tudo o resto, porque é muito bem coberto por testes de unidade.
  5. Você quase nunca recebe um bug repetido, pois todos os que encontrar devem fazer um teste antes de obter uma correção.

Você pediu para se convencer, então esses eram benefícios. Veja esta pergunta para uma visão mais equilibrada.

32
Fishtoaster

Robert C. Martin fez esses pontos originalmente - posso apoiá-los com minha própria experiência:

  • Você criará automaticamente um conjunto de testes de regressão de testes de unidade à medida que avança.
  • Você quase nunca gasta tempo depurando, como se você se codifica em um buraco, é mais fácil desfazer seu código ao ponto em que o último teste passou, em vez de abrir um depurador.
  • A cada poucos minutos, você verifica se seu código funciona - tudo (ou pelo menos todo o comportamento coberto pelos testes, que, se você estiver fazendo TDD, é uma porcentagem muito alta).

Pratico TDD o tempo todo, esteja trabalhando na produção ou no código do jogo; Atualmente, acho difícil codificar de qualquer outra maneira.

11
Paddyslacker

(Isenção de responsabilidade: quase não faço coisas com a interface do usuário, não posso discutir o TDD para UIs.)

Eu uso o TDD em praticamente tudo o que faço, desde aplicativos triviais até pilhas inteiras SIP.

Eu não uso o TDD em um site legado PHP site que eu assumi. Acho doloroso não ter testes. E acho que é intensamente irritante quebrar acidentalmente partes do site porque não tenho uma suíte de testes de regressão dizendo que eu quebrei alguma coisa.O cliente não tem orçamento para (a) escrever testes para a base de código e (b) no processo, tornar o código testável em primeiro lugar, então eu apenas com isso.

6
Frank Shearar
  • Sempre que seu cliente puder ser fornecido com mais eficiência (eles possivelmente se relacionarão bem a testes - e isso pelo menos reduzirá a discussão no final do projeto)
  • Sempre que levar mais tempo, mantenha seus co-desenvolvedores informados sobre TUDO no código do que se esforce na construção do teste - e isso é mais cedo do que você imagina
1
Tobiasopdenbrouw