Única coisa mais importante para dar ao ensino TDD [fechado]

Question

Eu estou colaborando com um grupo de profissionais para colocar em um evento para ajudar a ensinar a prática de TDD para as pessoas que estão interessadas, mas não têm experiência (novatos).

Estamos tentando chegar a laboratórios, oficinas, etc e eu estou tentando pensar em uma única coisa mais importante, que precisamos para dar em cima destes indivíduos para ajudá-los ser bem sucedido em praticar TDD daqui para frente.

O que você diria que devemos fazer a nossa prioridade para a aprendizagem? Que aspecto do TDD ensino é o mais importante. Se você tem que fazer duas coisas, tudo bem, eu não vou te segurar para a parte ÚNICO:)

Answer 1

Trata-se de projeto . É de não sobre os testes.

Answer 2

Não pule etapas do processo. Leva mais tempo para entrar no ritmo inicial de TDD, mas uma vez que está no lugar todo o SDLC é mais rápido e muito mais livre de bugs.

Red - Green - Refactor -> apenas fazê-lo

.

Answer 3

Só porque seus testes passá-lo não significa que o código está correto.

Além de que, eu diria que é importante considerar o teste em seu projeto. Se o código é difícil de teste sem conhecimento íntimo da implementação interna da unidade em teste, você pode querer reconsiderar o projeto. Caso contrário, refatoração torna-se mais propenso risco porque os testes provavelmente terá de ser alterado com o código.

Answer 4

Eu não sei se isso iria contar como a coisa mais importante -. Mas foi algo que me levou algum tempo para "pegar" quando eu estava explorando primeiro usando TDD

Não escreva o código em sua cabeça antes de escrever o teste.

Quando eu comecei a fazer TDD eu "sabia" o que o projeto deve ser. Eu "sabia" o que o código que eu queria escrever. Então eu escrevi um teste que iria me deixar escrever esse pedaço de código.

Quando eu estava fazendo isso, eu não estava realmente fazendo TDD - desde que eu estava escrevendo o primeiro código (mesmo se o código foi apenas na minha cabeça: -)

Levei algum tempo (e alguns cutucando por gente inteligente) para perceber que você precisa se concentrar no teste. Escrever o teste para o comportamento que você quer - então escrever o código mínimo necessário para fazê-lo passar - então deixe o design emergem através refatoração. Repita até feito.

Answer 5

Eu sugiro, "Seja paciente." É uma sensação estranha no começo. Para mim, foi provavelmente três projetos antes que ele começou a se sentir natural.

Answer 6

Concordo com o que Jon disse em sua resposta , mas acho que um corolário importante é que a capacidade de teste não dita " bom design ", mas é apenas um indicador de que seu projeto em no alvo.

Answer 7

TDD, na minha mente, é tudo sobre o ritmo (vermelho, verde, refactor). Obtendo o baixo ritmo você fica sobre o "corcunda" de "não consegui-lo". E se você não pegar o ritmo para baixo você provavelmente não vai ficar com TDD por muito tempo. A essência do ritmo é passos de bebê, que já foi mencionado. Escrever o mínimo de código possível, e refatorar impiedosamente.

Uma coisa a enfatizar é que TDD comercializa alguns ganhos de curto prazo para as de longo prazo. Começando com TDD, invariavelmente, diminuir a sua produtividade. Mas uma vez que você aprende o ritmo, é semelhante a entrar em um sulco, e ele pode realmente ajudá-lo a trabalhar mais rápido. Para não mencionar o efeito colateral de TDD é uma base crescente de testes de unidade que oferecem testes de regressão. Uma inevitabilidade do software é que os sistemas sendo mantidos (sem um conjunto de testes de regressão automatizados) degradar ao longo do tempo.

Answer 8

Enfatize que TDD é uma mudança de paradigma para o desenvolvedor s. Se você está de pé uma nova equipe, percebe que vai demorar até seis meses para obter a equipe totalmente eficaz como praticantes de TDD. Uma vez que você tem uma equipe ágil amadurecer efetivamente praticando TDD, o emparelhamento irá permitir um novo desenvolvedor para entrar no balanço de uma coisas depois de um par de iteração. Além disso, por meio de pares de uma equipe para semear uma nova linha, você pode obter a nova linha até a velocidade em TDD muito mais rápido do que a primeira linha.

Nos projetos que temos medidos, vimos uma queda de seis vezes em defeitos encontrados durante o teste / regressão funcional automatizado uma vez que a equipe aprendeu a fazer TDD. Isso é uma economia significativa. Além disso, o código reflete um design mais limpo, com menos linhas de código para cada recurso. TDD, mas uma parada virtual para revestimento de ouro. TDD é mais eficaz se você história cartões têm critérios de aceitação.

TDD também permite ritmo sustentável. A equipe vai achar que eles podem continuar a receber o mesmo número de recursos feitas com cada iteração porque o código permanece limpo com alguns defeitos. Com ambos TDD e test / regressão funcional automatizado, muitas vezes vemos zero defeitos encontrados durante Teste de Aceitação.

Answer 9

Lidar com o pressue de amaragem TDD quando os prazos estão ficando apertado. Este é um dos maiores problemas que eu vieram aross ajudar as pessoas e equipes com TDD. Eles tiveram uma dificuldade para expressar a importância eo valor de deixar cair destaque em vez de testes para a gestão superior.

Answer 10

Proceda baby-passos.

Certifique-se de seus testes cobrem apenas uma pequena escopo e, como diz PhlipCPP: ' Realizar a EDIT mínimo necessário para fazer o teste passar '

Mesmo assim, há muito para TDD, então você ainda tem que ter certeza que você não perca nada.

Answer 11

Na minha experiência, usando TDD permite que eu e minha equipe para impiedosamente refatorar nosso código sem se preocupar que ele vai quebrar alguma coisa em algum lugar inesperado.

Então eu acho que para mim o aspecto mais importante de TDD é a cobertura, já que uma boa cobertura me dá a confiança para refatorar sempre que vejo uma mancha na base de código que pode usá-lo.

Answer 12

Enfatizar diferentes tipos de testes. Ambos teste de caixa-preta e teste de caixa branca são importantes e têm finalidades diferentes. teste caixa-branca não está lá para verificar a exatidão, pois não pode testar o sistema como um todo. Ele está lá para tornar o código cheira mesmo stinkier e, portanto, fornecem uma melhor direção refatoração. teste de caixa-preta está lá para correção de teste. Cada recurso deve ser caixa-preta testado.

Além disso, enfatizar as diferenças na cobertura de teste. Devido a problemas combinatórios e repetibilidade, é impossível teste caixa-preta cada caminho de código em sua aplicação. Minha regra é que um recurso não está completo até que é caixa-preta testado. Você deve ajudar os alunos a descobrir suas próprias regras. No entanto, os testes de caixa branca não deve ter dependências classe externos; portanto, cada linha de cada classe deve ser branco-box testado.