Come testare un'unità di un client WCF realizzato con Starter di riposo WCF

Question

Ho creato alcuni servizi POX utilizzando lo Starter kit REST. Inizialmente, è stato un po 'complicato creare i test unitari per il livello di servizio, ma alla fine è stato ben progettato e riesco a deridere il contesto e fissare aspettative.

Ma ora sto iniziando con il lato client e sto riscontrando dei problemi nel capire come deridere le cose. Non è così semplice.

Quindi, ho questo metodo di esempio che pubblica via HTTP alcuni dati usando un datacontract e XML come trasporto.

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");
        }
    }
}

Questo metodo funziona e in effetti pubblica i dati e serializza correttamente.

Quello che voglio fare è provare l'unità.

Le mie domande sono:

1. Come posso creare stub / mock per HttpContextExtensions sapendo che non implementa alcuna interfaccia?

2. E per HttpClient? questo è peggio perché è pieno di metodi di estensione definiti altrove (Post e metodi simili sono estensioni).

In 2. Immagino di poter attenermi a "Invia" ed è sovraccarico, ma poi è lo stesso problema di 1

Quello che stavo pensando di fare è estrarre le interfacce per HttpContextExtensions e HttpClient, creare un figlio per ognuno e implementare le interfacce delegando al genitore, quindi usando le interfacce nel mio codice.

Ma questo è molto lavoro IMHO.

Sto usando RhinoMocks come il mio framework beffardo, quindi non posso deridere / stub classi di calcestruzzo, e mi piacerebbe attenermi ad esso, perché penso davvero che deridere le classi di calcestruzzo non sia molto elegante.

Quindi, esiste un modo più pulito / più veloce / più intelligente per testare il codice dell'unità come sopra?

PD: è per l'anteprima del kit di base WCF 2

Answer 1

Se vuoi davvero deridere quel codice, un approccio che potrebbe funzionare per questo scenario è quello di ricevere un'istanza HttpClient nella classe ServiceClient. La classe HttpClient contiene una pipeline di elaborazione che è possibile personalizzare con gestori personalizzati. Per i tuoi test, puoi sostanzialmente iniettare un gestore in quell'istanza di httpclient per restituire una risposta derisa al test prima che il servizio reale venga chiamato nell'ultimo gestore (Transport Stage). Dai un'occhiata a questo post per avere un'idea di come implementarlo,

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

Saluti, Pablo.

Answer 2

Ho scritto la maggior parte del codice HttpClient. Il suggerimento di Pablo è quello che ho fatto nei test unitari - vedi FixedTransport.cs nel codice sorgente zip.