A ideia do teste de unidade é permitir o desenvolvimento de código completamente modular. Você provavelmente já sabe que o código modular é o caminho a seguir, pois incentiva designs reutilizáveis e claramente focados.
Se você tentar testar um sistema inteiro como um todo, muitas partes diferentes terão a possibilidade de falhar. Em qualquer sistema de tamanho razoável, seria quase impossível considerar todos os possíveis problemas. Além disso, quando problemas são encontrados, pode ser difícil (ou quase impossível) localizar o código responsável.
No entanto, se partes diferentes do seu código forem completamente separadas de outras partes (ou seja, elas não dependem uma da outra), você poderá usar o teste de unidade para testar um subconjunto do sistema maior. É muito mais fácil detectar erros em uma pequena quantidade de código, ao contrário de uma grande quantidade.
No exemplo apresentado, existem duas super-partes do seu código: a parte que recupera dados de um banco de dados; e a parte que processa esses dados. Se você tentou testar os dois juntos, seu teste pode ficar cheio de falhas devido à tentativa de acesso ao banco de dados. Existem inúmeras redes e outros problemas de E / S que podem surgir durante a leitura do banco de dados. Especialmente em casos extremos, isso pode dificultar muito o teste da parte de processamento do seu código. Da mesma forma, pode haver erros no código de processamento que, por algum motivo, não estão localizados claramente nessa parte do código.
A solução é usar o teste de unidade. Em vez de testar a recuperação e processamento juntos , você os separa. Você pode alimentar todos os dados que desejar para a parte de processamento para ver se eles funcionam corretamente. Se algo der errado, você sabe que o problema é um problema de processamento e não está relacionado à leitura do banco de dados. Da mesma forma, você pode fazer testes simples para garantir que esteja tentando acessar o banco de dados de maneira correta. Quaisquer problemas que surgirem desta vez certamente estarão relacionados à leitura do banco de dados.
Assim, o teste de unidade é realmente inestimável no teste de código para robustez. Além disso, incentiva um padrão de design que é extremamente encorajador. Especificamente, os desenvolvedores que desejam usar testes de unidade devem projetar de forma que seu código possa ser separado em unidades modulares. Por exemplo, uma função que depende muito do estado global mutável é inerentemente menos testável em unidades do que uma função que depende apenas de argumentos para produzir um resultado.
Editar
Uma coisa que esqueci de mencionar é que testes de unidade não são uma reflexão tardia. Eles pretendem ser uma parte integral do processo de desenvolvimento, de modo que pequenos pedaços de código sejam garantidos como robustos. Isso aumenta a robustez do código durante o desenvolvimento. Como cada nova parte é escrita, ela pode ser imediatamente testada em unidade para descobrir possíveis falhas. Assim, uma base robusta é colocada sobre quais camadas de código robusto podem ser escritas. O resultado final é que um produto final tem maior probabilidade de ter um nível de correção muito mais alto do que um produto equivalente que é testado após o processo de desenvolvimento. Além disso, o tempo gasto no teste é geralmente reduzido.