2009-11-08 17 views
5

Bien, así que he intentado entrar en IoC últimamente. Sin embargo, sigo corriendo en un obstáculo: ese es el hecho de que me encanta usar objetos simulados.Mejores prácticas para pruebas unitarias, objetos simulados y ioc

Son rápidos y fáciles de instalar.

Sin embargo, si utilizo IoC por todas partes en mi código, entonces me obliga a crear implementaciones de prueba (y configuraciones) de mis objetos en lugar de usar objetos simulados (es decir, usando moq).

El resultado final es que termino con enormes archivos de configuración para probar.

Además, hay muchos escenarios en las pruebas en los que requiero diferentes comportamientos de mis clases en una prueba a prueba. Con objetos moq esto es extremadamente fácil. ¿Cómo harías algo similar con IoC?

Cualquier ayuda sería muy apreciada.

Gracias,
Mike

+0

¿Puede dar más información acerca del problema? No entiendo cómo o por qué estás teniendo un problema. Tal vez una muestra de código? –

+0

Si está utilizando inyección, las dependencias en su clase normalmente deberían inyectarse en el constructor o en las propiedades, por lo que en su prueba, debería tener todas las costuras necesarias para reemplazar lo que inyectan los simulacros. ¿Puedes explicar un caso específico con el que estás luchando? – Mathias

+0

¿Por qué usa un contenedor de IOC para pruebas unitarias? – mwjackson

Respuesta

5

COI debería hacer uso de los objetos de imitación más fácil, no más difícil.

Varios frameworks de contenedores IoC le permitirán definir objetos preexistentes para inyectar; con Moq que acaba de configurar para myMockObject.Object.

EDIT: Ejemplo de configuración de Unity con una maqueta:

var mockService = new Mock<IMyService>(); 
container.RegisterInstance<IMyService>(mockService.Object); 

Como alternativa, sólo puede pasar el objeto simulado en el constructor de la clase bajo prueba (para inyección constructor) y omitir el contenedor IoC completamente en sus pruebas de unidad.

EDIT: la respuesta de Josh es un buen ejemplo de la alternativa. Por lo general, voy con su solución en lugar de reconfigurar el contenedor.

+0

Agradable mostrando cómo usar el IoC para probar. Terminamos teniendo que rodar nuestro propio IoC para utilizarlo con WCSF fuera de un contexto web. Fue sorprendentemente fácil de hacer y terminó siendo un excelente ejercicio para comprender los patrones de Inyección de Dependencia e IoC. – Josh

3

Me encanta COI y me amo algunos objetos simulados ...

no hay conflicto con estos dos. Si está realizando algún tipo de Inyección de Dependencia, entonces simplemente debe crear objetos falsos usando su marco de burla favorito y luego pasarlos a su SUT.

[Test] 
public void AnAwesomeTest() 
{ 
    IDependencyOne d1 = MyMocker.Create<IDependencyOne>(); 
    IDependencyTwo d2 = MyMocker.Create<IDependencyTwo>(); 

    //Constructor injection 
    SUT sut = new SUT(d1); 

    //Property Injection 
    sut.DependantProperty = d2; 

    //Do some stuff and Assert 
} 
+0

+1. Tenga en cuenta que sería "nuevo SUT (d1.Object)" con Moq. – TrueWill

+0

Interesante. Estoy acostumbrado a RhinoMocks yo mismo ... si la sintaxis no me delata. – Josh

+0

@Josh: Una diferencia es que d1 y d2 serían del tipo Mock . Downside tiene que hacer .Objeto para llegar a la interfaz, upside es capaz de establecer expectativas en d1 y d2 directamente. Vale la pena comparar/contrastar las bibliotecas; ellos tienen filosofías diferentes Cambié de Rhino a Moq hace algún tiempo. – TrueWill

Cuestiones relacionadas