Se testarmos uma função B, testando uma função C que chama essa função B, ou seja, escrevendo um programa de teste para testar a função C que chama essa função B, o método de teste ainda é chamado de teste de unidade ou algo mais?
Quando é preferido testar indiretamente uma função que chama a função de destino e quando é preferido testar uma função diretamente?
Respostas:
Uma definição popular de teste de unidade é a do ISTQB:
Um teste de unidade é a menor parte testável de um aplicativo, como funções, classes, procedimentos, interfaces. O teste de unidade é um método pelo qual unidades individuais de código-fonte são testadas para determinar se são adequadas para uso.
De acordo com esta definição:
Agora pode haver uma diferença entre a intenção e o escopo do teste. Se você escreve um programa de teste para B usando C, ainda é um teste de unidade de C, porque tudo o que você pode fazer é fornecer a entrada para C e verificar com base na saída se B estava correto. É que você deduz que B funciona porque C funciona.
Há também uma definição de teste de integração :
Testes realizados para expor defeitos nas interfaces e nas interações entre componentes ou sistemas integrados.
A definição usual de componentes de software implica que ele é independente e pode ser implantado por conta própria. Aqui, B e C parecem não ser componentes independentes, portanto não temos teste de integração.
Isso depende muito do que você considera uma unidade. Se Cé tão simples que testá-lo separadamente não faz sentido, então seu teste é um teste de unidade.
Muito mais importante é que seu conjunto de testes de unidade para uma determinada unidade tenha quase 100% de cobertura de linha e teste todos os caminhos de código praticamente previstos.
Sim, ainda o chamamos de teste de unidade se as funções chamam outras funções.
Os testes de unidade devem testar o comportamento público de uma classe e não as implementações privadas. Conforme sugerido pelos testes deste artigo do Google sobre o banheiro .
Se você seguir as regras do Código Limpo , suas funções não deverão ter mais de 4 linhas de código. Isso torna impossível não testar outra função privada com seus testes de unidade.
Por que você não deveria testar separadamente a maioria das funções privadas? Como a refatoração o forçaria a continuar atualizando todos os seus testes de unidade de implementação. Isso se tornará frustrante quando você tiver muitos deles, enquanto o comportamento do público não deve mudar durante a refatoração e, portanto, o teste não precisa de atualização. Você deve poder testar a privacidade com seus pais públicos. Às vezes, pode valer a pena testar particulares complexos, mas se pergunta se eles deveriam ser uma classe separada por conta própria?
Teste de integração :
Agora, se a função faz parte de outra classe, é diferente. Em seguida, chamaríamos de teste de componente ou teste de integração. Você está integrando várias classes e executando um teste contra elas. A função B dependeria da função C. Para poder testar a função B, você poderia usar a injeção de dependência para isolar a função que está testando, agora seria um teste de unidade novamente.