Wie man Einheit testet Ein WCF -Client, der mit WCF REST Starter Kit erstellt wurde

Question

Ich habe einige Pockendienste mit dem Rest Starter Kit erstellt. Zunächst war es etwas kompliziert, die Unit -Tests für die Serviceschicht zu erstellen, aber am Ende war es gut gestaltet, und es gelingt mir, den Kontext zu verspotten und die Erwartungen zu setzen.

Aber ich fange jetzt mit der Kundenseite an und habe einige Probleme, herauszufinden, wie man Dinge verspottet. Es ist nicht so einfach.

Ich habe also diese Beispielmethode, die über HTTP einige Daten unter Verwendung eines DataContract und XML als Transport veröffentlicht wird.

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

Diese Methode arbeitet und veröffentlichen tatsächlich die Daten und serialisieren korrekt.

Was ich tun möchte, ist, es zu testen.

Meine Fragen sind:

1. Wie mache ich Stubs/Mocks für httpcontextextensions, wenn ich weiß, dass es keine Schnittstelle implementiert?

2. Und für httpclient? Dies ist am schlimmsten, da es voller Erweiterungsmethoden ist, die an anderer Stelle definiert sind (Post und ähnliche Methoden sind Erweiterungen).

In 2. Ich denke, ich kann mich an "senden" und es sind Überladungen, aber dann ist das gleiche Problem wie in 1

Ich dachte, es ist, Schnittstellen für httpcontextextesions und httpclient zu extrahieren, ein Kinder für jeden einzelnen zu machen und die an den übergeordneten Delegieren zu delegierten Schnittstellen zu implementieren und dann die Schnittstellen in meinem Code zu verwenden.

Aber das ist eine Menge Arbeit imho.

Ich benutze Rhinomocks als mein spöttisches Gerüst, also kann ich konkrete Klassen nicht verspotten/stummschern und ich würde gerne daran halten, weil ich wirklich denke, dass verspottete Betonklassen nicht sehr elegant sind.

Gibt es also eine sauberere/schnellere/intelligentere Methode, um wie die oben genannten Einheiten zu testen?

PD: Dies gilt für das WCF Starter Kit Preview 2

Answer 1

Wenn Sie diesen Code wirklich verspotten möchten, besteht ein Ansatz, der für dieses Szenario funktionieren könnte, darin, eine httpclient -Instanz in der Dienstenklasse zu erhalten. Die HTTPClient -Klasse enthält eine Verarbeitungspipeline, die Sie mit benutzerdefinierten Handlern anpassen können. Für Ihre Tests können Sie im Grunde genommen einen Handler in diese httpclient -Instanz injizieren, um eine verspottete Antwort auf den Test zurückzugeben, bevor der reale Dienst in der letzten Handlerin (Transportstufe) aufgerufen wird. Schauen Sie sich diesen Beitrag an, um eine Vorstellung davon zu bekommen, wie dies implementiert werden kann.

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

Grüße, Pablo.

Answer 2

Ich habe den größten Teil des Httpclient -Codes geschrieben. Der Vorschlag von Pablo ist das, was ich in den Unit -Tests gemacht habe - siehe FixedTransport.cs im Quellgebiet.