Quanto mais tarde você testar, mais custa escrever testes.
Quanto mais tempo um bug vive, mais caro é consertar.
A lei dos retornos decrescentes garante que você possa testar a si mesmo até o esquecimento, tentando garantir que não haja bugs.
Buda ensinou a sabedoria do caminho do meio. Testes são bons. Existe algo de muito bom. A chave é saber quando você está desequilibrado.
Cada linha de código que você escreve sem testes terá custos significativamente maiores para adicionar testes mais tarde do que se você tivesse escrito os testes antes de escrever o código.
Cada linha de código sem testes será significativamente mais difícil de depurar ou reescrever.
Cada teste que você escreve leva tempo.
Cada bug levará tempo para corrigir.
O fiel lhe dirá para não escrever uma única linha de código sem primeiro escrever um teste com falha. O teste garante que você está recebendo o comportamento esperado. Ele permite que você altere o código rapidamente sem se preocupar em afetar o restante do sistema, pois o teste prova que o comportamento é o mesmo.
Você deve pesar tudo isso contra o fato de que os testes não adicionam recursos. Código de produção adiciona recursos. E os recursos são o que pagam as contas.
Pragmaticamente falando, eu adiciono todos os testes que posso fazer. Eu ignoro os comentários em favor de assistir a testes. Eu nem mesmo confio em código para fazer o que eu acho que faz. Eu confio em testes. Mas sou conhecido por jogar ocasionalmente granizo e ter sorte.
No entanto, muitos programadores bem sucedidos não fazem TDD. Isso não significa que eles não testem. Eles simplesmente não insistem obsessivamente que cada linha de código tenha um teste automatizado contra ela. Até mesmo o tio Bob admite que ele não testa sua interface do usuário. Ele também insiste em que você mova toda a lógica para fora da interface do usuário.
Como uma metáfora do futebol americano (que é o futebol americano), o TDD é um bom jogo de chão. O teste somente manual onde você escreve uma pilha de código e espera que funcione é um jogo de passagem. Você pode ser bom em qualquer um. Sua carreira não vai fazer os playoffs a menos que você possa fazer as duas coisas. Não fará o superbowl até que você aprenda quando escolher cada um. Mas se você precisar de um empurrão em uma direção específica: as ligações dos oficiais vão contra mim com mais frequência quando estou passando.
Se você quiser experimentar o TDD, recomendo que pratique antes de tentar fazê-lo no trabalho. TDD feito meio caminho, meio coração e meia boca é uma grande razão para alguns não respeitarem. É como derramar um copo de água no outro. Se você não se compromete e o faz de forma rápida e completa, acaba driblando a água por toda a mesa.