Coma seus vegetais, permaneça na escola e escreva testes de unidade antes de escrever seu código. Já ouvimos isso tantas vezes.
Provavelmente também não o seguimos exatamente, mas hey, isso é realidade. O principal benefício do desenvolvimento orientado por teste é que ele aumenta a confiança na previsibilidade do código. Isso é uma conversa sofisticada de power point, pois garante que seu código ainda funcione quando as coisas mudarem . Há um segundo lado do desenvolvimento orientado a testes que não é tão óbvio: ele fará com que você projete um código melhor . Essa é minha teoria, pelo menos; simplesmente escrever bons testes de unidade significa que suas habilidades como designer ficam melhores.
Esta é minha história: eu herdei um projeto JavaEE com o qual não fiquei exatamente feliz. Sem testes de unidade, sem documentação e script de construção que só parecia funcionar se seu sacrifício fosse aceito pelos deuses pagãos e você tivesse a combinação certa de arquivos .jar. Resumindo, não seria divertido.
Decidi que a primeira coisa que faria seria escrever testes de unidade. Dessa forma, eu poderia dizer se minhas alterações quebrariam alguma coisa. Eu rapidamente descobri que essa era uma tarefa impossível; o código simplesmente não foi escrito para ser testado na unidade. Os únicos métodos públicos retornaram void e não havia pontos de entrada que eu pudesse usar para testar o código sem depender de um grande número de recursos externos. Nesse ponto, eu estaria apenas escrevendo testes de integração completa e não os testes de unidade que queria. Por volta dessa época, descobri que o conteúdo do código também era muito ruim; muitos componentes fortemente acoplados que não aderiam a nenhuma interface declarada. Comecei a pensar em como tudo isso poderia realmente ser melhorado com um bom framework, como o Spring, que poderia quebrar o código em pequenos componentes reutilizáveis que são, por natureza,muito testável por unidade. A injeção de dependência requer interfaces, e essas, meus amigos, são coisas muito boas. Mesmo se você não estiver usando injeção de dependência ou uma estrutura, se seu código puder ser testado em unidades, provavelmente não será ruim. E mesmo que seja, pelo menos alguém pode entrar mais tarde e limpar as coisas.
Portanto, aqui está a lição: escrever testes de unidade força você a escrever código fracamente acoplado, e código fracamente acoplado é um código melhor projetado. Além disso, durma 8 horas. Isso é importante.