É.
Mesmo se você fizer apenas um teste de unidade, não é incomum ter mais código dentro dos testes do que o código realmente testado. Não há nada de errado com isso.
Considere um código simples:
public void SayHello(string personName)
{
if (personName == null) throw new NullArgumentException("personName");
Console.WriteLine("Hello, {0}!", personName);
}
Quais seriam os testes? Existem pelo menos quatro casos simples para testar aqui:
-
O nome da pessoa é null . A exceção é realmente lançada? São pelo menos três linhas de código de teste para escrever.
-
O nome da pessoa é "Jeff" . Nós obtemos "Hello, Jeff!" em resposta? São quatro linhas de código de teste.
-
O nome da pessoa é uma string vazia. Qual saída esperamos? Qual é a saída real? Pergunta secundária: corresponde aos requisitos funcionais? Isso significa outras quatro linhas de código para o teste de unidade.
-
O nome da pessoa é curto o suficiente para uma string, mas é muito longo para ser combinado com "Hello, " e o ponto de exclamação. O que acontece? ¹
Isso requer muito código de teste. Além disso, as partes mais elementares do código geralmente requerem um código de configuração que inicializa os objetos necessários para o código em teste, o que também muitas vezes leva a escrever stubs e simulações, etc.
Se a proporção for muito grande, você poderá verificar algumas coisas:
-
Existe duplicação de código nos testes? O fato de ser um código de teste não significa que o código deva ser duplicado (copiado e colado) entre testes semelhantes: essa duplicação dificultará a manutenção desses testes.
-
Existem testes redundantes? Como regra geral, se você remover um teste de unidade, a cobertura da filial deverá diminuir. Caso contrário, pode indicar que o teste não é necessário, uma vez que os caminhos já estão cobertos por outros testes.
-
Você está testando apenas o código que deve testar? Não se espera que você teste a estrutura subjacente das bibliotecas de terceiros, mas exclusivamente o código do projeto em si .
Com testes de fumaça, testes de sistema e integração, testes funcionais e de aceitação e testes de carga e estresse, você adiciona ainda mais código de teste, então ter quatro ou cinco LOC de testes para cada LOC de código real não é algo que você deve se preocupar sobre.
Uma nota sobre o TDD
Se você está preocupado com o tempo que leva para testar seu código, pode ser que você esteja fazendo errado, que é o primeiro código, testa mais tarde. Nesse caso, o TDD pode ajudar, incentivando você a trabalhar em iterações de 15 a 45 segundos, alternando entre o código e os testes. De acordo com os proponentes do TDD, ele acelera o processo de desenvolvimento reduzindo o número de testes que você precisa fazer e, mais importante, a quantidade de código de negócios a ser gravado e especialmente reescrita para testes.
¹ Deixe n ser o comprimento máximo de uma string . Podemos chamar SayHello e passar por referência uma string de tamanho n - 1 que deve funcionar bem. Agora, em Console.WriteLine step, a formatação deve terminar com uma cadeia de comprimento n + 8, o que resultará em uma exceção. Possivelmente, devido aos limites de memória, até mesmo uma string contendo n / 2 caracteres levará a uma exceção. A pergunta que se deve fazer é se este quarto teste é um teste unitário (parece um, mas pode ter um impacto muito maior em termos de recursos comparado com testes unitários médios) e se testa o código real ou o framework subjacente. / sup>