Unidad de prueba de una fábrica de resumen que toma parámetros

Question

Dada una aplicación fábrica de resumen:

public class FooFactory : IFooFactory { 
    public IFoo Create(object param1, object param2) { 
     return new Foo(param1, param2); 
    } 
} 

¿Qué pruebas de unidad se escribiría para esta clase? ¿Cómo puedo verificar que param1 y param2 se enviaron a la creación de Foo? ¿Debo hacer estas propiedades públicas de Foo? ¿No sería eso romper la encapsulación? ¿O debería dejar esto para la prueba de integración?

Answer 1

Así es como me gustaría escribir uno de un par de pruebas de unidad para una fábrica de este tipo (con xUnit.net):

[Fact] 
public void CreateReturnsInstanceWithCorrectParam1() 
{ 
    var sut = new FooFactory(); 
    var expected = new object(); 
    var actual = sut.Create(expected, new object()); 
    var concrete = Assert.IsAssignableFrom<Foo>(actual); 
    Assert.Equal(expected, concrete.Object1); 
} 

¿Rompe encapsulación? Sí y no ... un poco. La encapsulación no solo trata sobre el ocultamiento de datos; más importante aún, se trata de protecting the invariants of objects.

Asumamos que Foo expone esta API pública:

public class Foo : IFoo 
{ 
    public Foo(object param1, object param2); 

    public void MethodDefinedByInterface(); 

    public object Object1 { get; } 
} 

Mientras que la propiedad Object1 viola levemente el Law of Demeter, no meterse con los invariantes de la clase porque es de sólo lectura.

Además, la propiedad Object1 es parte de la clase Foo concreto - no la interfaz IFoo:

public interface IFoo 
{ 
    void MethodDefinedByInterface(); 
} 

Una vez que darse cuenta de que en una API de acoplamiento flexible, concrete members are implementation details, tales sólo de hormigón de sólo lectura establecimientos un impacto muy bajo en la encapsulación. Piénsalo de esta manera:

El constructor Foo pública es también una parte de la API de la clase Foo hormigón, por lo que sólo mediante la inspección de la API pública, aprendemos que param1 y param2 son parte de la clase. En cierto sentido, esto ya 'rompe la encapsulación', por lo que hacer que cada parámetro esté disponible como propiedades de solo lectura en la clase concreta no cambia mucho.

Tales propiedades proporcionan la ventaja de que ahora podemos probar la forma estructural de la clase Foo devuelta por la fábrica.

Esto es mucho más fácil que tener que repetir un conjunto de pruebas de unidades de comportamiento que, debemos suponer, ya cubren la clase concreta de Foo. Es casi como una prueba lógica:

1. De las pruebas de la clase concreta de Foo, sabemos que utiliza correctamente/interactúa con sus parámetros de constructor.
2. De estas pruebas también sabemos que el parámetro constructor está expuesto como una propiedad de solo lectura.
3. De una prueba de FooFactory sabemos que devuelve una instancia de la clase concreta de Foo.
4. Además, sabemos por las pruebas del método Create que sus parámetros se pasan correctamente al constructor Foo.
5. Q.E.D.

Answer 2

Puede hacer que FooFactory sea una clase genérica que espera a Foo como parámetro, y especifique que se trata de un simulacro. Llamando a factory.Create (...) luego crea una instancia del simulacro, y luego puede confirmar que el simulacro recibió los argumentos que esperaba.

Answer 3

Depende de lo que haga Foo con los 2 objetos de entrada. Busque algo que Foo haga con ellos que pueda ser fácilmente cuestionado. Por ejemplo, si se invocan métodos (incluidos getters o setters) sobre los objetos, proporcione simulaciones o stubs que puede verificar si se han llamado a las cosas esperadas. Si hay algo en el IFoo que puede ser probado en contra, puede pasar los valores conocidos a través de sus objetos simulados para probar contra después de la creación. Los objetos en sí mismos no deberían estar disponibles públicamente para verificar que los hayas aprobado.

También podría verificar que se devuelva el tipo esperado (Foo), dependiendo de si los otros comportamientos evaluados dependen de la diferencia entre las implementaciones IFoo.

Si se producen condiciones de error, intentaré forzarlas también, lo que sucederá si pasa nulo para uno o ambos objetos, etc. Foo se probará por separado, por supuesto, por lo que puede asumir durante una prueba de FooFactory que Foo hace lo que debería.

Answer 4

Las fábricas generalmente no están unitarias, al menos de acuerdo con mi experiencia - no hay mucho valor en la unidad que las prueba. Debido a que es la implementación de ese mapeo de implementación de interfaz, se refiere a la implementación concreta. Como tal, burlarse de Foo no es posible comprobar si recibe esos parámetros pasados.

Por otro lado, normalmente los contenedores DI funcionan como fábricas, por lo que si está utilizando uno, no necesitaría una fábrica.

Answer 5

Bueno, presumiblemente esos parámetros hacen que el IFoo devuelto tenga algo de cierto al respecto. Pruebe que eso sea cierto sobre la instancia devuelta.