So testen Sie einen WCF-Client, der mit WCF Rest Starter Kit erstellt wurde:

Question

Ich habe einige POX-Dienste mit dem REST-Starterkit erstellt. Zuerst war es ein wenig kompliziert, die Komponententests für die Serviceebene zu erstellen, aber am Ende war es gut gestaltet und es gelang mir, den Kontext zu verspotten und Erwartungen zu setzen.

Aber ich beginne jetzt mit der Client-Seite, und ich habe einige Probleme herauszufinden, wie man Dinge verspotten kann. Es ist nicht so geradlinig.

Also habe ich diese Beispielmethode, die via HTTP einige Daten mit einem Datenvertrag und XML als Transport buchen.

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 funktioniert und tatsächlich die Daten und die Serialisierung ordnungsgemäß veröffentlichen.

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

Meine Fragen sind:

1. Wie mache ich Stubs/für HttpContextExtensions verspottet zu wissen, dass es keine Schnittstelle nicht implementieren?

2. Und für HttpClient? Dies ist am schlimmsten, da es voll von an anderer Stelle definierten Erweiterungsmethoden ist (Post- und ähnliche Methoden sind Erweiterungen).

In 2. Ich glaube, ich bleibe kann auf ‚Senden‘ und es ist Überlastungen, aber dann ist das gleiche Problem wie in 1

Was ich zu tun, dachte ist Schnittstellen für HttpContextExtensions zu extrahieren und HttpClient, erstellen Sie untergeordnete Elemente für jedes Element und implementieren Sie die Schnittstellen, die an das übergeordnete Element delegieren, und verwenden Sie dann die Schnittstellen in meinem Code.

Aber das ist eine Menge Arbeit IMHO.

Ich benutze RhinoMocks als mein spöttisches Framework, also kann ich keine konkreten Klassen stempeln/stubben, und ich würde gerne dabei bleiben, weil ich wirklich denke, dass das Spotten konkreter Klassen nicht sehr elegant ist.

Gibt es also eine sauberere/schnellere/intelligentere Methode, den Testcode wie oben beschrieben zu testen?

PD: Dies ist für WCF Starter Kit Vorschau 2

Answer 1

Wenn Sie wirklich, dass Code verspotten wollen, einen Ansatz, der für dieses Szenario funktionieren konnte, ist eine Httpclient-Instanz in der ServiceClient Klasse zu erhalten. Die HttpClient-Klasse enthält eine Verarbeitungspipeline, die Sie mit benutzerdefinierten Handlern anpassen können. Für Ihre Tests können Sie grundsätzlich einen Handler in diese httpclient-Instanz einfügen, um eine verspottete Antwort auf den Test zurückzugeben, bevor der reale Dienst im letzten Handler (Transport Stage) aufgerufen wird. Werfen Sie einen Blick auf diesen Beitrag eine Vorstellung darüber zu bekommen, wie diese umgesetzt werden kann,

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

Grüße, Pablo.

Answer 2

Ich schrieb den größten Teil des HttpClient-Codes. Pablos Vorschlag ist, was ich in den Unit-Tests gemacht habe - siehe FixedTransport.cs in der Source-Zip-Datei.