Cómo realizar una prueba unitaria de un cliente WCF creado con WCF Rest Starter Kit

Question

Creé algunos servicios de POX usando el kit REST Starter. Al principio, fue un poco complicado crear las pruebas unitarias para la capa de servicio, pero al final, estaba bien diseñado y logré burlarme del contexto y establecer expectativas.

Pero, ahora estoy comenzando con el lado del cliente, y tengo algunos problemas para descubrir cómo burlarme de las cosas. No es tan sencillo.

Entonces, tengo este método de muestra que publica a través de HTTP algunos datos usando un contrato de datos y XML como transporte.

public class ServiceClient: IService

{
    private const string uri_template = "http://{0}:{1}/SomeService.svc/";
    private readonly HttpClient http = new HttpClient();

    public ServiceClient(string host, int port)
    {
        http.BaseAddress = new Uri(string.Format(uri_template , host, port));
    }

    public void Create(MyDataContract my_data_contract)
    {
        var content = HttpContentExtensions
                        .CreateDataContract(
                          my_data_contract, 
                          Encoding.Default, 
                          "text/xml", 
                          null);
        var response = http.Post("Create", content);
        if (response.StatusCode != HttpStatusCode.Created) {
            throw new Exception("something is not right");
        }
    }
}

Este método funciona y, de hecho, publica los datos y serializa correctamente.

Lo que quiero hacer, es probarlo por unidad.

Mis preguntas son:

1. ¿Cómo hago stubs / simulacros para HttpContextExtensions sabiendo que no implementa ninguna interfaz?

2. ¿Y para HttpClient? esto es peor ya que está lleno de métodos de extensión definidos en otra parte (los métodos de publicación y similares son extensiones).

En 2. Supongo que puedo seguir con 'Enviar' y sus sobrecargas, pero entonces es el mismo problema que en 1

Lo que estaba pensando hacer es extraer interfaces para HttpContextExtensions y HttpClient, crear un elemento secundario para cada una e implementar las interfaces delegando en el padre y luego usar las interfaces en mi código.

Pero eso es mucho trabajo en mi humilde opinión.

Estoy usando RhinoMocks como mi marco de trabajo burlón, así que no puedo burlarme de las clases concretas, y me gustaría seguir, porque realmente creo que burlarse de las clases concretas no es muy elegante.

Entonces, ¿hay una forma más limpia / rápida / inteligente de unificar el código de prueba como el anterior?

PD: Esto es para la versión preliminar 2 del kit de inicio de WCF

Answer 1

Si realmente desea burlarse de ese código, un enfoque que podría funcionar para este escenario es recibir una instancia de HttpClient en la clase de ServiceClient. La clase HttpClient contiene una canalización de procesamiento que puede personalizar con controladores personalizados. Para sus pruebas, básicamente puede inyectar un controlador en esa instancia de httpclient para devolver una respuesta simulada a la prueba antes de llamar al servicio real en el último controlador (Etapa de transporte). Eche un vistazo a esta publicación para tener una idea de cómo se puede implementar esto,

http://weblogs.asp.net/cibrax/archive/2009/03/18/negotiating-a-saml-token-for-rest-clients-with-httpclient.aspx

Saludos, Pablo

Answer 2

Escribí la mayoría del código HttpClient. La sugerencia de Pablo es lo que hice en las pruebas unitarias: consulte FixedTransport.cs en el código postal fuente.