Como criar um teste baseado em estado para um método que chama outros métodos dentro da mesma classe?

Question

Eu tenho o código seguinte (que eu estúpidos para a pergunta):

    public void HandleModeInit(int appMode){
        switch(appMode){
            Case 1:
                DoThis();
            Case 2:
                DoThat();
            Case 3:
                //no mode 3
            Case 4:
                DoSomethingElse();
            Case else:
                //do nothing
        }
    }

Como é que você teste de unidade este método, sem transformá-lo em um teste de integração (onde você acabar testar o que doThis (), doThat () e DoSomethingElse () está fazendo)? Uma vez que estas chamadas de método são feitas para métodos em da mesma classe que HandleModeInit (), como você testar isso?

Embora, idealmente, as chamadas de método seria extraído em outra classe, e se esse movimento não faz qualquer sentido?

Answer 1

Se você tem controle sobre o que é passado para este método, então eu iria passar em uma interface que leva AppMode como um argumento que é uma AppModeImplementationFactory. O objetivo desta fábrica é criar AppModeImplementations. A fábrica ficaria da seguinte forma:

public class AppModeImplementationFactory: IAppModeFactory
{
   public IAppModeImplementation Create(int appMode)
   {
      // switch case goes here to create the appropriate instance
   }
}

Quando você passa na fábrica isso pode ser uma instância escarnecido e você pode verificar que o método create é chamado. Se você quiser verificar o tipo de instância que é devolvida que você precisa para fazer isso sob um teste diferente. Esta abordagem irá atender sua necessidade de executar a lógica por causa do modo de aplicativo porque a fábrica vai voltar a implementação que você precisa com base na AppMode.

Espero que isso ajude

Answer 2

Em vez de usar uma instrução switch / case para appModes interruptor, você pode criar uma interface chamada IAppMode (eu vou assumir que o chamador poderia decidir qual objeto para instanciar que implementa corretamente IAppMode uma vez que já está passando em um int para representam o App Mode).

O seu interlocutor iria passar em um objeto IAppMode, então o seu método poderia chamar os doThis () de IAppMode.

Você pode então criar um objeto fictício que implementos IAppMode e injetá-lo para o método durante o teste.

Não faz o seu easer código (usando padrões de design pode fazer isso) e test-capazes.

Answer 3

Eu percebo (especialmente com você notar isso) que o código é suavizado, mas se você não testar o que os métodos chamados fazer neste caso, o que está realmente testando? O valor da appMode?

Como exatamente para atacar isso é difícil (se não impossível) para dizer sem saber alguma sobre o que está acontecendo dentro dos métodos chamados. eles estão fazendo quaisquer chamadas de saída (a serviços externos, banco de dados, seja qual for) que podem ser ridicularizado? Se assim for, isso pode ser um caminho para a frente. Se eles contêm apenas o comportamento que é encapsulado na classe, talvez eles alterar alguns valor de propriedade que você pode verificar quando a chamada para HandleModeInit retornos?

Eu não sou normalmente um ventilador de alterar o design do meu código com o único propósito de torná-lo mais testável, mas uma abordagem seria para separar a interface pública da classe dos internos, e, em seguida, definir a interface interna como , assim, uma interface. Dessa forma, você se abrir para zombar os internos.