Muitas vezes, os benefícios do uso do TDD são considerados ganhos de 'longo prazo' - o código geral será melhor estruturado, mais testável, menos bugs relatados pelos clientes, etc.
No entanto, onde estão os benefícios de curto prazo do uso do TDD? Existe algum que seja realmente tengible e facilmente mensurável?
É importante ter um benefício óbvio (ou mesmo não óbvio por quantificável) a curto prazo, se os ganhos a longo prazo forem mensuráveis?
Respostas:
Existem alguns benefícios de curto prazo para o TDD, alguns mais mensuráveis que outros. Aqui estão alguns do topo da minha cabeça:
Código limpo, seguindo os bons princípios do SOLID . Ou seja, se você mantiver seus testes tão limpos quanto seu código e evitar código de teste híbrido sujo , o código tenderá a seguir o SOLID. Código limpo é mais fácil de ler e mais fácil de manter seu código desde o início. As horas de trabalho são salvas durante a manutenção, mas a curto prazo: você obterá um código mais limpo mais rapidamente (porque você tem alguns testes para fazer backup).
Teste de regressão desde o início; você quebrou, você saberá sobre isso ... cedo. Apoiado por um servidor de IC, você economizará um pouco de cabelo. É difícil medir as horas de trabalho para corrigir um erro regredido que você descobrirá cedo sem testes, mas digamos que são muitas horas de trabalho.
Permite que a refatoração seja feita sem muita adivinhação. Se você tiver feito um conjunto de testes para uma classe, refatorá-lo (como extrair métodos, usar outras estruturas de dados, extrair classes) será fácil porque você definiu os testes desde o início. O que levaria dias para refatorar uma classe levaria menos de uma; e você pode fazer isso imediatamente se tiver feito os testes de antes.
O design orientado a teste permite corrigir a duplicação de código com antecedência. Pelo menos se você é um programador atento; porque testar com código duplicado (tanto no código de teste quanto no código de produção) torna-se rapidamente uma tarefa monótona. Quanto mais inteligente você estiver com seu código de teste, melhor ele ficará. Menos código, menos problemas, mais horas de trabalho salvas.
EDIT Também adicionado por Frank Shearar, que por acaso concordo:
A qualquer momento, você tem código de trabalho (exceto o caso de teste com o qual você está trabalhando).
Encontrar bugs ou problemas de design no início do TDD é realmente inestimável e difícil de medir quanto você economiza em horas de trabalho; embora uma maneira seja contar as horas que você passou anteriormente trabalhando em questões de design no final do desenvolvimento. Com testes de unidade, um subconjunto do seu código pode ser exercido através de seus testes sem precisar executar o aplicativo ou sistema real. Dessa forma, você pode garantir, por meio do TDD, que parte do seu programa está funcionando no momento , mesmo que não esteja ligado à realidade no momento.
A curto prazo, você quer dizer pequenos projetos ou os primeiros dias de um projeto?
Acredito que a integração de testes e a preparação das bases iniciais renderá dividendos imediatamente, porque você verificou os pilares sobre os quais todo o restante do projeto permanecerá. Tendo a projetar de cima para baixo e a implementar de baixo para cima, isso faz sentido para minha maneira de trabalhar.
Se você perceber uma inconsistência agora, seu trabalho acabou de se pagar por não precisar depurar um programa mais complexo posteriormente.
Além disso, seu projeto já está configurado para teste e você não precisará refatorar uma plataforma mais tarde.
Um benefício a curto prazo que encontro no TDD é que não preciso me concentrar tanto no que estou tentando alcançar.
Se eu for interrompido do meu trabalho, sem o TDD, levará alguns minutos para me lembrar de onde estou quando voltar à tarefa.
Com o TDD, apenas executo os testes para ver qual deles falha e instantaneamente sei o que estava tentando alcançar. Eu trabalho mais rápido com menos dor de cabeça.