Em primeiro lugar o custo inicial não é tão alto quanto você acha que é . Sim, você gasta mais tempo lidando com testes do que se não fizer testes. Mas se você fizer um método "teste após", o que realmente está desperdiçando? Digamos que o TDD leve 10 horas e o DDT leve 6 horas. Seus custos iniciais "extras" são de apenas 4 horas. Agora, se você aplicar uma métrica de código ou um requisito como cobertura de 90%, seu TDD e DDT se tornarão ainda mais próximos em custos.
Você escreverá um código com menos bugs com o TDD. Mesmo que seja porque você especificou os requisitos como um teste, no final do dia você pode provar que seu código está fazendo exatamente o que você queria que isso acontecesse. Agora talvez você quisesse que fizesse a coisa errada, mas isso não é um bug que é uma solicitação de mudança. Isso é importante. É mais fácil "vender" um produto que está funcionando, mas pode funcionar de forma diferente / melhor, então é vender um produto que é percebido como não funcionando. Com o TDD, é literalmente impossível passar no teste e escrever código que não funciona. É possível que você não tenha entendido os requisitos e tenha escrito o código errado, mas funcionando.
O TDD é melhor quanto mais antigo for o código-base. Tente refatorar sem um conjunto de testes ou com um pacote mal implementado. Mesmo uma simples mudança pode introduzir erros. Ter uma suíte de testes com boa cobertura garante que, à medida que o produto evolui, continue funcionando como deveria. Também ajuda a destacar regras comerciais conflitantes (que acontecem por períodos mais longos).
Você não sabe que não funciona. Sem uma suíte de testes, você não sabe se o seu código está funcionando como você pensa ou se parece estar funcionando.
var foo = function(in) {
if(in == 0) {
return true
}
}
Agora, em todo o seu aplicativo, você chama if(foo()){ doStuff() }
O que acontece quando eu corri foo?
var foo = function(in) {
if(in === 0) {
return true
}
}
Você deve refatorar e SECAR seus testes também. Um bom conjunto de testes não é difícil de manter. Com testes atômicos bem escritos, raramente tive que voltar e mudar mais de 1-2 deles de cada vez. Quando houve mudanças maiores na suíte de testes, é uma gigantesca bandeira vermelha que algo não está certo.
I just do not see how I should know all my methods and how things will work until my code is there.
Bem, você não deveria. Você deveria escrever um teste que testa que alguma unidade de trabalho é feita. Se você sente que está testando coisas que você não pode saber, então você está pensando muito grande, ou o teste OR é muito pequeno.
Por exemplo, você precisa saber que uma porta se fecha e trava. Gostaria de testar door.close () e door.lock () e que door.open () retorna false quando a porta está bloqueada. É isso. Se os seus testes são door.lock () define um sinalizador no banco de dados. Então você está testando muito pequeno. O teste não precisa saber como o door.lock () funciona, apenas isso.
Agora, se você está escrevendo um teste que diz que house.isSecure () retorna verdadeiro quando todas as portas e janelas estão bloqueadas. Sem olhar para as portas ou janelas primeiro, então você está pensando muito grande.
Por fim, você pode estar olhando para uma unidade de trabalho muito grande . Quando você recebe sua lista de requisitos, você deve organizá-los para trabalhar na unidade mais pequena. Escreva o teste apenas para aquela unidade, depois o código, depois enxágüe e repita.
Em essência, o seu entendimento (a lista) de como o TDD deve funcionar está desativado. Você nunca deve passar 2/100. Você deve ter 1/1 de passe, 2/2 de passe, 3/3 de passe, 4/4 de passe e assim por diante.
Uma lista revisada para você
- Obtenha todas as especificações
- Escolha uma especificação
- Teste
- Codifique
- Teste
- Se os testes passarem para 7, vá para 4
- Se você tiver feito todas as especificações, vá para 8 e vá para 2
- Revise as especificações com o consumidor e adicione novas especificações quando necessário. Se feito corretamente, você não deve ter que alterar nenhum teste. Basta adicionar novos. Às vezes, a coleta de requisitos pode se desfazer e você precisa adicionar testes que entram em conflito com testes anteriores, mas raramente é necessário alterar os testes.