que imita sin inyección

Question

(C#, Servicio WCF, burla de Rhino, MbUnit)

he estado escribiendo las pruebas de código ya en su lugar (sí sé que es al revés, pero así es como su funcionó en mi contrato vigente) He hecho un poco de refactorización para admitir burla: inyecciones, agregar interfaces adicionales, etc., lo que ha mejorado el diseño. En general, mi experiencia en pruebas ha ido bien (exponiendo la fragilidad y mejorando el desacoplamiento). Para cualquier objeto he estado creando los burdos dependientes y esto me sienta bien y tiene sentido.

La aplicación esencialmente tiene 4 capas físicas. La base de datos, una capa de repositorio para el acceso a los datos, un servicio WCF que está conectado al repositorio a través de una capa de gestión (o lógica comercial), por lo que desde arriba hacia abajo se ve así;

WCF Managers Repository Base de datos

Testing los gerentes y capa de repositorio ha sido bastante simple, el imitar las dependencias con Rhino Mocks e inyectarlas en la capa bajo prueba como tal.

Mi problema está en probar la capa superior de WCF. Como mi servicio no tiene el constructor que me permita inyectar las dependencias, no estoy seguro de cómo hago para burlarme de una dependencia al probar los métodos públicos (ServiceContracts) en el servicio.

Espero que tenga sentido y cualquier ayuda muy apreciada. Soy consciente de TypeMockIsolator, etc., pero realmente no quiero ir por esa ruta tanto por razones de presupuesto como por otras razones por las que no entraré aquí. Además, estoy seguro de que hay muchos "Stackers" inteligentes que tienen la información que necesito.

Gracias de antemano.

Answer 1

¿Hay alguna razón específica no se puede tener un constructor en su servicio?

De lo contrario, puede tener constructores sobrecargados con un cable de constructor predeterminado encima de los valores predeterminados y un constructor parametrizado con sus dependencias. Ahora puede probar el ctor parametrizado y confiar en el ctor predeterminado para crear la instancia en producción.

public MyService() : this(new DefaultDep1(), new DefaultDep2()) 
{ 
} 

public MyService(IDep1 d1, IDep2 d2) 
{ 
} 

Una mejor solución si se utiliza la inyección de dependencia sería el uso de la WCF IInstanceProvider interface para crear la instancia de servicio y proporcionar las dependencias necesarias a través de ese punto de inyección. Se puede encontrar un ejemplo usando Structure Map here.

Answer 2

Puede hacer que los servicios WCF sean una capa delgada sobre los "gerentes", por lo que tienen poca o ninguna lógica en ellos que requiera pruebas. Entonces no los pruebes y simplemente prueba a los gerentes. Alternativamente, podría lograr un efecto similar al tener otra capa de 'servicio' que contenga la lógica de los servicios, la cual puede ser probada, y hacer que el código WCF real simplemente pase a través de eso.

Answer 3

Nuestro servicio WCF obtiene todas sus dependencias de un objeto Factory, y le damos al servicio un constructor que toma IFactory. Entonces, si queremos escribir una prueba que se burla de una de las dependencias, digamos una IDependencia, solo tenemos que inyectar una fábrica simulada, que está programada para devolver al servicio el objeto IDependency imputado.

Answer 4

Si utiliza una inversión de control (IoC), como Unity, AutoFac o Castle Windsor, y un marco de burla (por ejemplo, Moq, NMock, RhinoMocks) esto es bastante simple siempre que tenga el diseño correcto.

Para un buen tutorial sobre cómo hacerlo con RhinoMock y Windsor, echar un vistazo a este artículo de blog - http://ayende.com/Blog/archive/2007/02/10/WCF-Mocking-and-IoC-Oh-MY.aspx

Answer 5

Si está utilizando Castle Windsor, eche un vistazo a WCF facility, le permite usar dependencias no predeterminadas e inyectar dependencias en sus servicios, entre otras cosas.