Su problema aquí es que ha acoplado estrechamente Business Layer a su servicio WCF; en realidad crea una nueva instancia del cliente de servicio dentro de Business Layer, lo que significa que ahora es imposible llamar al método SendData sin llamar los métodos de servicio.
La mejor solución es introducir la inyección de dependencia en su arquitectura.
En su forma más simple, todo lo que hace es pasar una instancia de su clase de servicio en su Business Layer. Esto se hace a menudo en el tiempo de construcción de la clase usando un parámetro de constructor.
public class BusinessClass
{
private ISomeServiceClient _svc;
public BusinessClass(ISomeServiceClient svc)
{
_svc = svc;
}
public void SendData(DataUnit dataUnit)
{
_svc.SomeMethod(dataUnit);
}
}
Tenga en cuenta que el código anterior es un patrón de diseño, sin depender absolutamente de ningún marco como un contenedor de inversión de control.
Si la política de su empresa no es utilizar dichos marcos (por cierto, una política insana), puede inyectar manualmente sus instancias simuladas del servicio dentro de las pruebas de su unidad.
lo que hago estos casos a utilizar Moq para burlarse de la interfaz de servicio. – Yaur
Aquí no hay nada especial acerca de WCF (aunque el hecho de que la clase cliente implemente una interfaz puede ayudarlo). Este sería exactamente el mismo problema si 'SendData' necesita llamar a algún método de biblioteca de clases. –
@Yakur: ¿Cómo le digo a NUnit Framework que si se llama SomeServiceClient, use este objeto simulado? Como SomeServiceClient se crea dentro del BL, no sé cómo lo paso. – Asdfg