O custo de não escrever testes
Escrever testes unitários pode gerar um custo adicional de tempo de desenvolvimento. Pode parecer estranho, mas muitas equipes deixam de cobrir algumas funcionalidades com testes pois acham que estão perdendo tempo com isso.
Primeiro, se você acha que escrever testes é perda de tempo, é melhor começar a ler mais sobre o assunto e tentar entender o benefício que eles trazem para o seu projeto. Vou elencar alguns pontos que provam que escrever testes é mais barato do que não escrever.

Qualidade de código
Esse é o primeiro ponto e um dos mais importantes. É óbvio que escrevendo testes você cria um código mais coeso, claro e de qualidade. Guiar um programador por testes, faz com que ele se importe mais com o código que escreve. Faz com que ele entenda quais pontos do código está suscetível a falhas. Não existe software de qualidade sem um código de qualidade.
Escrever código de qualidade vai muito além de ter testes. Mas geralmente quando temos uma funcionalidade com bons testes, o código dela tende a ser melhor. O programador entendeu o que ele precisava fazer, pois teve que fazer os cenários de teste. Isso ajuda o código a ficar claro e de boa qualidade.
Benefícios a longo prazo
A maioria dos benefícios dos testes automatizados você só vai perceber com o passar do tempo. Seu software vai passar por muitas mudanças, isso é uma certeza. Essas mudanças muitas vezes vão ser em rotinas chaves, complexas e podem ser desenvolvidas por programadores que talvez não tenham um domínio completo da funcionalidade. Nesse momento, os testes vão manter a qualidade do que foi desenvolvido, vão guiar esse programador e principalmente garantir a qualidade.
Refatorar
Melhorar um código sem testes, parece ser uma tarefa impossível. Se torna pior ainda quando o software já está em produção e você tem o dever de não quebrar esse código. Muitas vezes esse é o grande motivo dos programadores terem receio de refatorar.
Criando bons testes, o programador vai se sentir confortável para refatorar. Ele tem menos medo de mexer no software, isso vai melhorando a qualidade do software e facilitando futuras atualizações.
Refatorando o software, ele vai ser mais barato de manter. Tendo códigos bem escritos e estruturados, as atualizações, melhorias e correção de bugs vão se tornar mais simples. Criando essa cultura, o custo de manter e melhorar o software vai baixar e você vai acabar tendo um produto de melhor qualidade.
Precisa testar tudo?
Alguns vão dizer que sim, outros que não. E realmente é discutível. O principal é que códigos que são alterados com uma certa frequência, tem regra complexa ou um papel muito importante devem ter uma boa cobertura de testes, por motivos óbvios.
Algumas rotinas acabam sem testes porque no início eram simples e com o passar do tempo começaram a evoluir, evoluir e evoluir. Nesse tempo, ninguém parou para implementar os testes. O resultado disso é que agora ela está complexa, toda semana aparece um bug e ninguém quer refatorar, pois tem “muita coisa em jogo”.
Escalabilidade
É difícil imaginar um sistema escalável que não tenha uma boa suite de testes. Escalabilidade é algo desejável em qualquer software. Escalar com o software funcionando e mantendo a qualidade, parece impossível sem testes. O mundo sabe disso faz décadas. O custo de escalar seu software sem testes pode ir além de bugs. Você pode perder clientes, pois não vai conseguir manter a qualidade de costume.
Evoluir
Todo software passa por uma evolução. Algumas são pequenas, mas geralmente temos grandes mudanças que impactam em funcionalidades chaves do sistema. Quando a evolução chega até você, e você precisa evoluir uma parte dele e não tem a garantia de que tudo vai continuar funcionando… pode ser uma má ideia.
Teste manual
Não faz sentido fazer teste manual na maioria das situações. Não é confiável. Afinal, dependemos de pessoas e sempre existe um risco. Não tem como uma pessoa garantir que “tudo está funcionando”, é humanamente impossível. Imagine se toda vez que uma funcionalidade fosse alterada, precisássemos retestar tudo.
Custo
Esse é o ponto principal, e não é óbvio as vezes. Um software com baixa cobertura de testes tem um custo elevado. Provavelmente você vai precisar de muitos programadores para fazer o que poucos fariam, parece que nunca consegue dar conta das demandas.
Pense bem, quanto desse tempo é consumido por bugs e códigos mal feitos? Muito, certamente. A maioria desse dinheiro e tempo que está indo pelo ralo poderia ser evitada com um desenvolvimento pensado, de qualidade e com uma boa cobertura de testes. Criando com isso um software de qualidade com menos devs.
O mundo usa testes automatizados. Não seja hipócrita em pensar que “isso não é pra mim”, pois talvez programar não seja pra você. Eu já fiz projetos sem testes, inclusive estou tendo que melhorar um que fiz há um tempo e não tem testes. Acredite, me arrependo dessa decisão em todo trecho de código que tenho que mudar. Além de querer melhorar meus códigos antigos, ainda vou atualizar o meu Framework. Agora é a minha chance de fazer um trabalho bem-feito. Alterar algo que está em produção, é sempre mais doloroso. Fica a dica.
