Os caras do JUnit (framework de teste de unidade Java) têm uma filosofia que se for simples demais para testar, não teste ele . É altamente recomendável ler as Perguntas frequentes sobre práticas recomendadas , pois é bastante pragmático.
O TDD é um processo diferente de escrever seu software. A premissa básica por trás do teste de unidade é que você gastará menos tempo no depurador percorrendo o código e mais rapidamente descobrirá se a alteração do seu código acidentalmente quebra alguma outra coisa no sistema. Isso se encaixa com o TDD. O ciclo TDD é assim:
- Escreva um teste
- Assista a falha (prove que você tem algo a fazer)
- Escreva exatamente o que é necessário para fazer o teste passar - não mais.
- Assista passar (yay!)
- Refatorar (melhorar)
- Lave, enxague e repita
O que é menos óbvio sobre a aplicação do TDD é que ele muda a forma como o seu código de escrita . Forçando-se a pensar em como testar / validar se o código está funcionando, você está escrevendo um código testável. E já que estamos falando de testes de unidade, isso geralmente significa que seu código se torna mais modular. Para mim, o código modular e testável é uma grande vitória na frente.
Agora, você precisa testar coisas como as propriedades do C #? Imagine uma propriedade definida assim:
bool IsWorthTesting {get; set;}
A resposta seria "não" não vale a pena ser testada, porque neste momento você está testando o recurso de idioma. Apenas confie que os caras da plataforma C # acertaram. Além disso, se falhar, o que poderia você fazer para corrigir isso?
Além disso, você descobrirá que há certas partes do seu código que muito bem serão muito trabalhosas para serem testadas adequadamente. Isso significa que não faça isso, mas certifique-se de testar o código que usa / é usado pelo problema complicado:
- Exceções verificadas que só podem ocorrer se uma instalação foi mal. Java tem uma tonelada desses. Você é obrigado a escrever um bloco catch ou declarar a exceção verificada, mesmo que não haja como falhar, sem invadir os arquivos instalados.
- Interfaces do usuário. Encontrar o controle em teste e invocar os eventos certos para simular as ações de um usuário são muito problemáticos e, em alguns casos, impossíveis. No entanto, se você usar o padrão Modelo / Visualização / Controlador, poderá certificar-se de que o modelo e os controladores sejam testados e deixar a parte da vista para testes manuais.
- Interações entre cliente e servidor. Este não é mais um teste de unidade e agora é um teste integração . Escreva todas as partes que vão até o envio e recebimento de mensagens pelo fio, mas não passe pelo fio. Uma boa abordagem é reduzir a responsabilidade do código que realmente fala sobre o fio para as comunicações brutas. Em seu código de teste de unidade, ignore o objeto de comunicação para garantir que os serviços estão se comportando conforme o esperado.
Acredite ou não, o TDD irá ajudá-lo a cair em um ritmo sustentável de desenvolvimento. Não é por causa da magia, mas sim porque você tem um loop de feedback apertado e você é capaz de pegar erros realmente idiotas rapidamente. O custo de consertar esses erros é essencialmente constante (pelo menos o suficiente para propósitos de planejamento), porque os pequenos erros nunca crescem como grandes erros. Compare isso com a natureza em rajadas dos sprints de limpeza de depuração / depuração de código.