A menos que você escreva um código sem testá-lo, você sempre incorre no custo do teste.
A diferença entre ter testes de unidade e não tê-los é a diferença entre o custo de escrever o teste e o custo de executá-lo em comparação com o custo do teste manualmente.
Se o custo de escrever um teste de unidade for de 2 minutos e o custo de executar o teste de unidade for praticamente 0, mas o custo de testar manualmente o código for de 1 minuto, você será prejudicado ao executar o teste duas vezes.
Por muitos anos, fiquei com a má compreensão de que não tinha tempo suficiente para escrever testes de unidade para o meu código. Quando escrevi testes, eles estavam inchados, coisas pesadas que só me incentivaram a pensar que só deveria escrever testes de unidade quando soubesse que eram necessários.
Recentemente, fui encorajado a usar o Test Driven Development e achei uma revelação completa. Agora estou firmemente convencido de que não tenho tempo para não escrever testes de unidade .
Na minha experiência, desenvolvendo com testes em mente, você acaba com interfaces mais limpas, classes e módulos mais focados e, geralmente, mais código SOLID testável.
Toda vez que trabalho com código legado que não possui testes de unidade e preciso testar algo manualmente, fico pensando "isso seria muito mais rápido se esse código já tivesse testes de unidade". Toda vez que tenho que tentar adicionar a funcionalidade de teste de unidade ao código com alto acoplamento, fico pensando "isso seria muito mais fácil se tivesse sido escrito de maneira desacoplada".
Versão TL; DR :
Escreva um teste quando o custo de escrevê-lo, mais o custo de executá-lo quantas vezes for necessário, for menor do que o custo de testá-lo manualmente quantas vezes for necessário.
Lembre-se, porém, de que, se você usar o TDD, é provável que o custo de escrever testes diminua à medida que você melhora e, a menos que o código seja absolutamente trivial, você provavelmente acabará executando os testes com mais frequência do que espera.