Por que eu deveria praticar Test Driven Development e como devo começar?

votos
50

Muitas pessoas falam sobre a escrita de testes para seu código antes de começar a escrever o seu código. Esta prática é geralmente conhecido como Test Driven Development ou TDD para breve. Quais os benefícios que eu ganho de escrever software desta maneira? Como posso começar com esta prática?

Publicado 07/08/2008 em 03:27
fonte usuário
Em outras línguas...                            


6 respostas

votos
31

Há uma série de benefícios:

  • Você obter um feedback imediato sobre se o seu código está funcionando, para que possa encontrar bugs mais rápido
  • Ao ver o teste vai de vermelho para verde, você sabe que você tem tanto um teste de regressão de trabalho, e código de trabalho
  • Você ganha confiança para refatorar código existente, o que significa que você pode limpar o código sem se preocupar com o que poderia quebrar
  • No final você tem um conjunto de testes de regressão que pode ser executado durante compilações automatizadas para dar-lhe maior confiança de que sua base de código é sólido

A melhor maneira de começar é só começar. Há um grande livro de Kent Beck tudo sobre Test Driven Development. Basta começar com o novo código, não se preocupe com o código antigo ... sempre que você sentir que você precisa para refatorar algum código, escrever um teste para a funcionalidade existente, em seguida, refatorar-lo e certifique-se os testes de ficar verde. Além disso, leia este excelente artigo .

Respondeu 07/08/2008 em 03:33
fonte usuário

votos
3

A parte benefícios tem sido recentemente cobertas , como por onde começar .... em um pequeno sistema enterprisey onde não há muitas incógnitas para que os riscos são baixos. Se você ainda não conhece a estrutura de testes (como NUnit), começar a aprender isso. Caso contrário, começar a escrever o seu primeiro teste :)

Respondeu 07/08/2008 em 03:30
fonte usuário

votos
2

benefícios

  1. Você descobrir como compartimentar o seu código
  2. -Lo a descobrir exatamente o que você quer que seu código para fazer
  3. Você sabe como ele deve agir e, no caminho, se refatoração quebra tudo
  4. Você recebe o hábito de ter certeza que seu código sempre sabe o que é suposto fazer

Começando

Apenas faça isso. Escrever um caso de teste para o que você quer fazer, e, em seguida, escrever código que deve passar no teste. Se você passar o teste, ótimo, você pode passar para casos de escrita, onde o seu código sempre falhará (2 + 2 não deve igual a 5, por exemplo).

Uma vez que todos os seus testes passam, escrever sua lógica de negócio real para fazer o que quiser fazer.

Se você está começando do zero certifique-se de encontrar um bom conjunto de teste que é fácil de usar. Eu gosto de PHP assim PHPUnit ou SimpleTest funcionar bem. Quase todas as linguagens populares têm algum conjunto de teste xUnit disponível para ajudar a construir e automatizar testes.

Respondeu 07/08/2008 em 03:34
fonte usuário

votos
0

Você pode estar trabalhando em um ambiente ágil ou cachoeira. Talvez você tenha procedimentos que foram batalha-testadas através de anos de trabalho duro bem definido, ou talvez você acabou de começar sua própria start-up. Não importa o que a situação era, você provavelmente enfrentou pelo menos um, se não mais, dos seguintes dores, problemas, ou causas para a entrega sem sucesso:

  • Parte de sua equipe é mantido fora do circuito durante a criação de requisitos, especificações, ou histórias de usuários
  • A maioria, se não todos, os testes são manuais, ou você não tem provas em tudo
  • Mesmo que você tenha testes automatizados, eles não detectar problemas reais
  • testes automatizados são escritos e executados quando já é tarde demais para eles para fornecer um valor real para o projeto
  • Há sempre algo mais urgente do que dedicar tempo para testes
  • As equipes são divididas entre os testes, desenvolvimento e departamentos de análise funcional, e eles são muitas vezes fora de sincronia
  • Uma incapacidade para refatorar o código por causa do medo de que algo será quebrado
  • O custo de manutenção é muito alto
  • O mercado time-to-é muito grande
  • Os clientes não sentem que o que foi entregue é o que pediram
  • Documentação não está atualizado
  • Você tem medo de implantar a produção porque o resultado é desconhecido
  • Você é muitas vezes não é capaz de implantar a produção porque os testes de regressão demorar muito tempo para executar
  • Equipe está gastando muito tempo tentando descobrir o que alguns método ou uma classe faz

Test-driven development não magicamente resolver todos estes problemas. Em vez disso, ele nos coloca no caminho para a solução. Não há nenhuma bala de prata, mas se há uma prática de desenvolvimento que podem fazer a diferença em tantos níveis, que a prática é o desenvolvimento orientado a TDD.Test acelera o mercado de time-to-, permite fácil refatoração, ajuda a criar uma melhor concepção e promove looser topo coupling.On dos benefícios diretos, TDD é um pré-requisito para muitas outras práticas (entrega contínua sendo um deles). melhor design, código bem escrito, o mercado time-to-rápido, up-to-date documentação e cobertura de teste sólida, são alguns dos resultados que você vai conseguir aplicando TDD.

Respondeu 02/02/2017 em 13:41
fonte usuário

votos
0

Bom começo: Introdução ao Tdd em Java usando Eclipse por Brett L. Schuchert

É um conjunto de screencasts sobre TDD em Java e em C #. É a partir do zero e ensino básico de TDD.

Respondeu 03/06/2010 em 21:25
fonte usuário

votos
0

Na minha opinião, a única coisa mais importante é que ele claramente permite que você veja se o seu código faz o que é suposto. Isto pode parecer óbvio, mas é super fácil de executar desviar de seus objetivos originais, como eu descobri no passado: p

Respondeu 07/08/2008 em 03:32
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more