Como e quando usar o teste UNIT corretamente

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.

O teste de unidade permite testar módulos de código sem o aplicativo. Você pode testar o código bem antes de o aplicativo existir. No desenvolvimento orientado a objetos, os testes unitários devem testar apenas uma classe. Testes de integração são usados para verificar várias classes trabalhando em concerto. Felizmente, muitos testes de integração podem ser executados usando estruturas de teste de unidade. Testes unitários de classes únicas podem ser difíceis, pois você pode precisar fornecer objetos simulados para atender suas dependências. Este é especialmente o caso quando se testa o código relacionado ao banco de dados. Em muitos casos, seu exemplo pode ser um teste de integração.

Supondo que você tenha unidade e / ou integração testou o código que pega o pacote e o processa no banco de dados, você simplifica o teste do aplicativo. Agora, se o aplicativo não conseguir processar dados no banco de dados, você sabe que o problema provavelmente ocorrerá antes do código que realmente carrega os dados no banco de dados. Talvez o pacote não esteja sendo preparado corretamente ou enviado para o manipulador correto.

Quanto mais código você tiver testado em unidade e / ou integração, mais simples será testar todo o aplicativo, já que você deve ter muitas partes que já foram testadas e que podem ser confiáveis para funcionar corretamente.

Testes de unidade e integração simplificam o teste em que os desenvolvedores ou os sistemas de criação podem testar o código antes da conclusão do aplicativo. Testes semelhantes são feitos ao construir coisas como aviões e carros. Tudo a partir de parafusos em cima são testados para garantir que eles estão à altura do trabalho; então os assemblies são testados; e finalmente o produto finalizado é testado. Isso facilita a substituição de peças quando necessário, pois os testes podem ser aplicados à peça substituta. Quando aplicamos essas técnicas, testes de unidade, integração e aplicativos, geralmente obtemos um software mais confiável e de fácil manutenção.

Quando um problema é encontrado com código que é testado por unidade ou integração, é comum adicionar um novo caso de teste para verificar se o problema foi resolvido. Isso aumenta a robustez do conjunto de testes ao longo do tempo.

Os sistemas de compilação automatizados geralmente executam os testes de unidade e integração como parte do processo de compilação. Isso permite que o sistema de construção sinalize ou rejeite o código que não passa mais nos conjuntos de teste. Os testes de aplicativos podem se concentrar em verificar a funcionalidade e a usabilidade do negócio sem se preocupar muito com a funcionalidade do código.

EDIT: percebi que não tinha respondido o título desta pergunta.

Quando usar o teste UNIT: Use o teste unitário para testar a interface pública em suas classes ou módulos. Você pode optar por não testar o código trivial. Geralmente, os métodos privados não são testados. Quanto mais complexo o código, mais importante é desenvolver testes de unidade.

Como testar a unidade: Use uma estrutura de teste, como jUnit (a estrutura foi desenvolvida para vários idiomas e, como um grupo, é chamada de xUnit). Desenvolver um conjunto de entradas e saídas esperadas. Concentre-se em testar casos de borda e casos de limite. Adicione testes que lidem com casos comuns ainda não cobertos. Use essas expectativas para escrever casos de teste que verificam se as entradas fornecidas fornecem os resultados esperados. Não se esqueça de testar as condições de falha.

No teste de unidade, você escreve primeiro os testes e depois implementa o código.