Atualmente, o teste de unidade tem uma mística nisso. As pessoas o tratam como se 100% da cobertura de teste fosse um santo graal e como se o teste de unidade fosse a única maneira verdadeira de desenvolver software.
Eles estão perdendo o objetivo.
Teste de unidade não é a resposta. Teste é.
Agora, sempre que essa discussão surgir, alguém (muitas vezes até eu) fará a citação de Dijkstra: "O teste do programa pode demonstrar a presença de bugs, mas nunca demonstra a sua ausência". Dijkstra está certo: o teste não é suficiente para provar que o software funciona como pretendido. Mas é necessário : em algum nível, deve ser possível demonstrar que o software está fazendo o que você deseja.
Muitas pessoas testam à mão. Até os entusiastas do TDD fazem testes manuais, embora às vezes não o admitam. Não pode ser ajudado: pouco antes de você entrar na sala de conferências para demonstrar seu software ao seu cliente / chefe / investidores / etc., Você o percorrerá manualmente para garantir que funcione. Não há nada de errado com isso, e de fato seria louco esperar que tudo corra bem sem executá-lo manualmente - ou seja, testá-lo - mesmo se você tiver 100% de cobertura de teste de unidade e a maior confiança em seus testes .
Mas o teste manual, mesmo que seja necessário para a criação de software, raramente é suficiente . Por quê? Porque o teste manual é tedioso, demorado e realizado por humanos. E os seres humanos são notoriamente ruins em realizar tarefas tediosas e demoradas: evitam fazê-las sempre que possível e geralmente não as fazem bem quando são forçadas a fazê-lo.
As máquinas , por outro lado, são excelentes para executar tarefas tediosas e demoradas. Afinal, foi para isso que os computadores foram inventados.
Portanto, o teste é crucial, e o teste automatizado é a única maneira sensata de garantir que seus testes sejam empregados de forma consistente. E é importante testar e testar novamente, à medida que o software é desenvolvido. Outra resposta aqui observa a importância do teste de regressão . Devido à complexidade dos sistemas de software, alterações freqüentemente aparentemente inócuas em uma parte do sistema causam alterações indesejadas (ou seja, bugs) em outras partes do sistema. Você não pode descobrir essas alterações indesejadas sem alguma forma de teste. E se você deseja ter dados confiáveis sobre seus testes, deve realizar seus testes de maneira sistemática, o que significa que você deve ter algum tipo de sistema de teste automatizado.
O que tudo isso tem a ver com o teste de unidade? Bem, devido à sua natureza, os testes de unidade são executados pela máquina, não por um ser humano. Portanto, muitas pessoas têm a falsa impressão de que o teste automatizado é igual ao teste de unidade . Mas isso não é verdade: os testes de unidade são apenas pequenos testes automatizados.
Agora, qual é o valor em pequenos testes automatizados? A vantagem é que eles testam os componentes de um sistema de software isoladamente , o que permite um direcionamento mais preciso dos testes e ajuda na depuração . Mas o teste de unidade não significa intrinsecamente testes de qualidade superior . Muitas vezes, leva a testes de qualidade mais alta, devido à cobertura do software em um nível mais fino de detalhes. Mas é possível testar completamente o comportamento de apenas um sistema completo, e não suas partes compostas, e ainda testá-lo completamente.
Mas mesmo com 100% de cobertura de teste de unidade, um sistema ainda pode não ser completamente testado. Como os componentes individuais podem funcionar perfeitamente isolados, ainda assim falham quando usados juntos. Portanto , o teste de unidade, embora seja muito útil, não é suficiente para garantir que o software funcione conforme o esperado. De fato, muitos desenvolvedores complementam os testes de unidade com testes de integração automatizados, testes funcionais automatizados e testes manuais.
Se você não vê valor nos testes de unidade, talvez a melhor maneira de começar seja usando um tipo diferente de teste automatizado. Em um ambiente web, o uso de uma ferramenta de teste de automação de navegador como o Selenium geralmente oferece uma grande vitória para um investimento relativamente pequeno. Depois de mergulhar os dedos dos pés na água, você poderá ver com mais facilidade a utilidade dos testes automatizados. E uma vez que você tem testes automatizados, o teste de unidade faz muito mais sentido, pois fornece uma resposta mais rápida do que grandes testes de integração ou de ponta a ponta, pois você pode direcionar testes apenas para o componente em que está trabalhando no momento.
TL; DR: não se preocupe com o teste de unidade ainda. Apenas se preocupe em testar seu software primeiro.