Dependendo de onde você olha, você receberá respostas ligeiramente diferentes. Eu li muito sobre o assunto, e aqui está minha destilação; Novamente, estes são levemente confusos e outros podem discordar.
Testes unitários
Testa a menor unidade de funcionalidade, geralmente um método / função (por exemplo, dada uma classe com um estado específico, chamar x método na classe deve fazer com que y aconteça). Os testes de unidade devem ser focados em um recurso específico (por exemplo, chamar o método pop quando a pilha está vazia deve gerar um InvalidOperationException). Tudo o que toca deve ser feito na memória; isso significa que o código de teste e o código em teste não devem:
- Convide colaboradores (não triviais)
- Acesse a rede
- Atingir um banco de dados
- Use o sistema de arquivos
- Girar um fio
- etc.
Qualquer tipo de dependência lenta / difícil de entender / inicializar / manipular deve ser stubbed / mocked / seja o que for, usando as técnicas apropriadas para que você possa se concentrar no que a unidade de código está fazendo, e não nas suas dependências.
Em resumo, os testes de unidade são o mais simples possível, fáceis de depurar, confiáveis (devido a fatores externos reduzidos), rápidos de executar e ajudam a provar que os menores blocos de construção do seu programa funcionam conforme planejado antes de serem reunidos. A ressalva é que, embora você possa provar que eles funcionam perfeitamente isoladamente, as unidades de código podem explodir quando combinadas, o que nos leva a ...
Testes de integração
Os testes de integração se baseiam em testes de unidade combinando as unidades de código e testando se a combinação resultante funciona corretamente. Isso pode ser o interior de um sistema ou a combinação de vários sistemas para fazer algo útil. Além disso, outra coisa que diferencia os testes de integração dos testes de unidade é o ambiente. Os testes de integração podem e vão usar threads, acessar o banco de dados ou fazer o que for necessário para garantir que todo o código e as diferentes alterações no ambiente funcionem corretamente.
Se você criou algum código de serialização e a unidade testou suas entranhas sem tocar no disco, como você sabe que ele funcionará quando você estiver carregando e salvando no disco? Talvez você tenha esquecido de liberar e descartar os filmes. Talvez suas permissões de arquivo estejam incorretas e você tenha testado as entranhas usando em fluxos de memória. A única maneira de descobrir com certeza é testá-lo 'de verdade' usando um ambiente mais próximo da produção.
A principal vantagem é que eles encontrarão erros que os testes de unidade não podem, como erros de fiação (por exemplo, uma instância da classe A recebe inesperadamente uma instância nula de B) e erros de ambiente (ele funciona bem na minha máquina com CPU única, mas meu a máquina de 4 núcleos do colega não pode passar nos testes). A principal desvantagem é que os testes de integração tocam mais código, são menos confiáveis, as falhas são mais difíceis de diagnosticar e os testes são mais difíceis de manter.
Além disso, os testes de integração não necessariamente provam que um recurso completo funciona. O usuário pode não se importar com os detalhes internos dos meus programas, mas eu sim!
Testes Funcionais
Os testes funcionais verificam a exatidão de um recurso em particular, comparando os resultados de uma determinada entrada com a especificação. Os testes funcionais não se preocupam com resultados intermediários ou efeitos colaterais, apenas o resultado (eles não se importam que, após fazer x, o objeto y tenha o estado z). Eles são escritos para testar parte da especificação, como "chamar a função Square (x) com o argumento 2 retorna 4".
Testes de aptidão
O teste de aceitação parece ser dividido em dois tipos:
O teste de aceitação padrão envolve a execução de testes no sistema completo (por exemplo, usando sua página da web por meio de um navegador da web) para verificar se a funcionalidade do aplicativo atende à especificação. Por exemplo, "clicar no ícone de zoom deve aumentar a exibição do documento em 25%". Não há um continuum real de resultados, apenas um resultado aprovado ou reprovado.
A vantagem é que os testes são descritos em inglês simples e garantem que o software, como um todo, tenha recursos completos. A desvantagem é que você subiu outro nível na pirâmide de testes. Os testes de aceitação tocam montanhas de código, portanto, rastrear uma falha pode ser complicado.
Além disso, no desenvolvimento ágil de software, o teste de aceitação do usuário envolve a criação de testes para espelhar as histórias do usuário criadas pelo / para o cliente do software durante o desenvolvimento. Se os testes forem aprovados, significa que o software deve atender aos requisitos do cliente e as histórias podem ser consideradas completas. Um conjunto de testes de aceitação é basicamente uma especificação executável escrita em um idioma específico do domínio que descreve os testes no idioma usado pelos usuários do sistema.
Conclusão
Eles são todos complementares. Às vezes, é vantajoso focar em um tipo ou evitá-lo completamente. A principal diferença para mim é que alguns dos testes analisam as coisas da perspectiva de um programador, enquanto outros usam o foco no cliente / usuário final.