wfc visual test studio prueba crear cliente wcf unit-testing

visual - wcf c#



Prueba unitaria WCF (8)

Cómo probar los servicios WCF por unidad? ¿Hay herramientas de terceros disponibles?


¿Qué es exactamente lo que quieres probar? Conectividad o métodos de servicio?

Lo bueno de WCF es que solo puedes definir interfaces (por ejemplo, contratos) y probarlas como código normal. Entonces puede suponer que funcionarán a través de cualquier tipo de conexión compatible con WCF.

La conectividad se puede probar alojando su servicio directamente en UT o en el servidor web de desarrollo.

En cuanto a las herramientas, hay toneladas de marcos de prueba de unidades: NUnit, pruebas integradas en Visual Studio, xUnit, etc., etc.

Puede descargar " Visual Studio 2008 y .NET Framework 3.5 Training Kit " y " .NET Framework 3.5 Enhancements Training Kit " si recuerdo correctamente había muestras para pruebas de unidad WCF


Como dice aku, si está probando los métodos de servicio (es decir, el comportamiento del código), puede probar la unidad directamente y eludir la infraestructura de WCF. Por supuesto, si su código depende de las clases de contexto de WCF (como OperationContext), entonces sugiero introducir wrappers como ASP.NET MVC para HttpContext.

Para probar la conectividad, dependerá del tipo de puntos finales que haya configurado. En algunos casos, puede autoevaluar su servicio WCF dentro de la prueba unitaria (como lo haría con un Servicio WCF de Windows) y probarlo.

Sin embargo, puede necesitar activar el Servidor Web de Desarrollo ASP.NET o incluso IIS si desea probar el comportamiento WCF específico para esos entornos de alojamiento (es decir, SSL, métodos de autenticación). Esto se pone complicado y puede comenzar a exigir la configuración de la máquina de desarrollo de todos y los servidores de compilación, pero es factible.


Creo que el mejor enfoque es analizar por separado todas las preocupaciones; conectividad de prueba, llamadas de lib cliente (proxies) y método de servicio. La burla y la inyección de dependencia es una buena forma de probar la conectividad y el comportamiento del servicio de forma independiente, pero dudo que pueda evitar las pruebas de punto final dependientes del middleware.

Puede crear un host de servicio en su prueba (autohospedado) y cargar su servicio. Una vez que configure sus puntos finales, puede conectarse utilizando los servidores proxy de su cliente. Esto debería funcionar con HTTP simple y WSHTTP. En su prueba de unidad necesita crear una referencia de servicio a su servicio. Luego puede crear un host y conectar su cliente con el host de prueba juntos. Intentaría evitar cualquier prueba con el "host de servicio WCF" alias WcfSvcHost. (Menciono esto solo porque algunas personas hacen referencia a las utilidades de Visual Studio, lo que funcionará solo si solo ejecuta pruebas desde su IDE).

Si necesita verificar escenarios de autenticación exóticos o puntos finales que usan un middleware especial, deberá crear pruebas utilizando el middleware. Para comprobaciones simples de cordura, etc. es suficiente el uso de alojamiento propio. Las pruebas dependientes de Middleware pueden causar problemas de implementación de prueba si está utilizando un servidor de compilación.

Por puntos finales dependientes de middleware quiero decir puntos finales que usan, por ejemplo, MOM (MSMQ, RabbitMQ, etc.) o protocolos realmente exóticos, etc. Tal vez probar los proxies del cliente con un simulacro autohospedado y probar los exóticos puntos finales por separado es el camino a seguir.

Si desea utilizar la inyección de dependencia, existen algunos marcos bastante sofisticados que proporcionan funciones de "abstracción del servicio" que le permiten inyectar servicios simulados, etc. Utilicé Spring.NET con WCF varias veces. Castle Windsor tiene instalaciones WCF también.

Ejemplo de prueba autohospedado:

ServiceHost serviceHost = null; try { var baseAddress = new Uri("http://localhost:8000/TestService"); serviceHost = new ServiceHost(typeof (ServiceClass), baseAddress); Binding binding = new WSHttpBinding(); var address = new EndpointAddress("http://localhost:8000/TestService/MyService"); var endpoint = serviceHost .AddServiceEndpoint(typeof (IServiceContract), binding, address.Uri); var smb = new ServiceMetadataBehavior {HttpGetEnabled = true}; serviceHost.Description.Behaviors.Add(smb); using (var client = new ProxyClient(endpoint.Name, endpoint.Address)) { endpoint.Name = client.Endpoint.Name; serviceHost.Open(); // ... magic happens } serviceHost.Close(); } catch (Exception ex) { // ... tests } finally { if (serviceHost != null) { ((IDisposable) serviceHost).Dispose(); } }

Me gustaría señalar que las herramientas de prueba funcional no son lo mismo que las herramientas de prueba de la unidad. Las pruebas unitarias deben consistir en dividir su prueba en un conjunto de pruebas independientes, mientras que las pruebas funcionales se refieren principalmente a probar los flujos de trabajo de principio a fin.


He visto la prueba SOA utilizada para evaluar las pruebas de rendimiento y escalabilidad de los servicios de WCF, si esto es lo que busca. No tengo información sobre el costo o la lentitud.

En nuestro caso, capturamos los mensajes de nuestra UI para realizar pruebas automatizadas.


Puede usar Typemock Isolator para hacer eso. Aquí hay un par de publicaciones sobre el tema de probar el lado del cliente , y el lado del servidor . Puede hacerlo sin ninguna dependencia, incluido un archivo de configuración.

Gil Zilberfeld Typemock


Si desea probar el servicio actual, entonces SoapUI es gratuito y tiene algunas características excelentes. La única advertencia es que solo lo he intentado con el enlace HTTP básico.


Si uno realmente quiere probar los servicios de WCF, es mejor ir con las pruebas de integración que realmente ejercen la conectividad entre el cliente y el servidor.