Como faço para funções sobrecarregadas de teste de unidade?

Question

Então, eu tenho uma classe que é algo como o seguinte:

public class MyClass
{

    DatabaseDependency _depend;

    public MyClass(DatabaseDependency depend)
    {
        _depend = depend;
    }

    public string DoSomething(DBParameter database)
    {
        var result = _depend.GetResults(database, ...);
        string response = String.Empty;        

        // some logic to process the result 

        return response;
    }

}

Onde DbParameter é uma classe de valor simples, que contém propriedades como Server, DBName, dbType, etc.

Agora, quero acrescentar uma sobrecarga para DoSomething para que ele aceite uma seqüência de conexão em vez do parâmetro DbParameter (assumir que DatabaseDependency já tem uma sobrecarga de GetResults que aceita uma seqüência de conexão).

A minha pergunta: Eu tenho vários testes de unidade que descrevem os vários caminhos lógicos usados ??para resultado do processo de DatabaseDependency.GetResults. Quando eu adicionar a sobrecarga de DoSomething, eu seria, essencialmente, refatorar o código para que esta lógica é reutilizada por ambas as sobrecargas (ou seja, provavelmente, movê-lo para um método particular). Qual é o caminho certo para ir sobre unidade testar isso? Preciso ter apenas como muitos testes de unidade para verificar todos os caminhos lógicos para a nova sobrecarga estou adicionando?

Answer 1

Se você está confiante de que seu método sobrecarregado tomando uma corda apenas converte em um objeto de conexão e, em seguida, delegados ao original, você deve adicionar mais um método de teste.

No entanto, este se decompõe se você refatorar os métodos sobrecarregados subjacentes de tal forma que nenhuma delegação tem lugar. Neste cenário Eu me sentiria mais confiante replicando todos os testes para ambos os métodos.

Eu acho que a primeira via é a mais pragmática. No entanto, é uma boa idéia para executar análise de cobertura de código de vez em quando, e que indicará em um momento posterior, se são necessários mais testes.

Answer 2

Se as suas estadias de código do jeito que atualmente aparência, então sim:. Você terá de teste de unidade que o método, bem como, essencialmente duplicando o seu esforço de teste

No entanto, se faz sentido para implementar a funcionalidade de modo que um método simplesmente chama o outro, você poderia fazer que outro método virtual. Isso permitiria que você criar uma subclasse específica de teste, onde você simplesmente verificar se o método virtual está sendo invocado por outro método com os valores corretos.

Uma vez que é verificado por um ou mais testes de unidade, você não precisa testar esse método ainda mais, porque agora você tem comprovada que o método chama o outro método corretamente, e você pode concentrar seus testes esforços nesse método.

Answer 3

Sim, refatorar o tratamento comum para um método particular - Presumo que você faria isso de qualquer maneira, independentemente de considerações de teste, código duplicado é ruim. É interessante como pensar sobre o teste leva-nos a fazer a coisa certa.

Então você tem um par de testes simples para cada caminho de iniciação overlaoded.

Answer 4

Depende se você está fazendo caixa-preta ou teste de caixa-branca e também se você está aplicativo está usando as duas versões do método.

Se você está assumindo que você está apenas testando a implementação, em seguida, basta testar a versão 'main' seria OK. Se você está pensando ao longo das linhas de um escritor de teste que só sabe sobre a API apresentado (javadocs ou similar), então você precisa testar com base apenas na API, o que implica testar ambos os métodos completamente.

Se você está aplicativo está usando apenas um método, então depreciar o outro e criar um teste condicional versão que falha quando o método preterido ainda existe em algum versão pré-determinado. IE:. Impor que o método preterido é removida em algum momento