Cómo crear una prueba basada en el estado de un método que llama a otros métodos dentro de la misma clase?

Question

Tengo el siguiente código (que he atontados por la pregunta):

    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
        }
    }

¿Cómo se podría probar unidad de este método sin convertirlo en una prueba de integración (donde se terminan las pruebas de lo que DoThis (), DoThat (), y DoSomethingElse () lo están haciendo)? Dado que estas llamadas a métodos están hechas a métodos en de la misma clase que HandleModeInit (), ¿cómo probar esto?

Aunque lo ideal, las llamadas a métodos se extraería a cabo en otra clase, ¿y si este movimiento no tiene ningún sentido?

Answer 1

Si usted tiene control sobre lo que se pasa en este método entonces me lo pase en una interfaz que lleva appmode como un argumento que es un AppModeImplementationFactory. El propósito de esta fábrica es crear AppModeImplementations. La fábrica se vería de la siguiente manera:

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

Cuando se pasa en la fábrica de esto puede ser una instancia de objeto de burla y se puede comprobar que el método se llama crear. Si desea verificar el tipo de instancia que se devuelve lo que tendría que hacer eso a una prueba diferente. Este enfoque satisfacer su necesidad de ejecutar la lógica debido al modo de aplicación porque la fábrica volverá a la aplicación que necesita en base a la appMode.

Espero que esto ayude

Answer 2

En lugar de utilizar una sentencia switch / case para cambiar appModes, puede crear una interfaz llamada IAppMode (voy a suponer que la persona que llama puede decidir cuál es el objeto de instanciate que implementa adecuadamente IAppMode puesto que ya están pasando en un int a representar el App Mode).

La persona que llama pasaría en un objeto IAppMode, entonces su método podría llamar al método DoThis () de IAppMode.

A continuación, podría crear un objeto ficticio que implementa IAppMode e inyectarlo en el método durante la prueba.

Esto hace que su código easer (usando patrones de diseño puede hacer eso) y la prueba de poder.

Answer 3

Me doy cuenta (sobre todo con que su anotación) que el código se dumbed abajo, pero si no se prueba lo que los llamados métodos pueden hacer en este caso, ¿cuáles son en realidad probando? El valor de appMode?

¿Cómo funciona exactamente a atacar esto es difícil (si no imposible) que decir sin saber alguna acerca de lo que está sucediendo dentro de los llamados métodos. ¿Están haciendo las llamadas salientes (a servicios externos, bases de datos, lo que sea) que puede ser burlado? Si es así, eso puede ser un camino a seguir. Si contienen único comportamiento que se encapsula en la clase, tal vez se alteran algunos valor de la propiedad que se puede comprobar cuando la llamada a HandleModeInit retornos?

Yo normalmente no soy un fan de alterar el diseño de mi código con el único propósito de hacer más comprobable, pero un enfoque sería separar la interfaz pública de la clase de las partes internas, y luego definir la interfaz interna como , así, una interfaz. De esta manera se abre por burlarse de los componentes internos.