Comment tester à l'unité un client WCF construit avec le kit de démarrage WCF Rest

Question

J'ai créé certains services POX à l'aide du kit de démarrage REST. Au début, la création des tests unitaires pour la couche de services était un peu compliquée, mais au final, elle était bien conçue et je réussis à me moquer du contexte et à définir des attentes.

Mais, je commence avec le côté client maintenant, et j’ai du mal à comprendre comment se moquer des choses. Ce n'est pas si simple.

Donc, j’ai cet exemple de méthode qui publie via HTTP des données utilisant un contrat de données et XML comme moyen de transport.

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

Cette méthode fonctionne et enregistre les données et la sérialisation correctement.

Ce que je veux faire, c'est de le tester à l'unité.

Mes questions sont les suivantes:

1. Comment créer des stubs / mocks pour HttpContextExtensions tout en sachant qu’il n’implémente aucune interface?

2. Et pour HttpClient? c’est pire car elle regorge de méthodes d’extension définies ailleurs (les méthodes Post et similaires sont des extensions).

Dans 2. Je suppose que je peux m'en tenir à "Envoyer" et que c'est surchargé, mais c'est le même problème que dans 1

Ce que je pensais faire est d’extraire les interfaces pour HttpContextExtensions et HttpClient, de créer un enfant pour chacun d’eux et de mettre en œuvre les interfaces qui délèguent au parent, puis d’utiliser les interfaces de mon code.

Mais c'est beaucoup de travail à mon humble avis.

J'utilise RhinoMocks comme cadre moqueur pour que je ne puisse pas me moquer de cours concrets, et j'aimerais m'y tenir, car je pense vraiment que se moquer de cours concrets n'est pas très élégant.

Alors, existe-t-il un moyen plus propre / plus rapide / plus intelligent de code de test unitaire comme ci-dessus?

PD: Ceci est pour l'aperçu 2 du kit de démarrage WCF

Answer 1

Si vous voulez vraiment vous moquer de ce code, une approche qui pourrait fonctionner pour ce scénario consiste à recevoir une instance HttpClient dans la classe ServiceClient. La classe HttpClient contient un pipeline de traitement que vous pouvez personnaliser à l'aide de gestionnaires personnalisés. Pour vos tests, vous pouvez en principe injecter un gestionnaire dans cette instance httpclient pour renvoyer une réponse fictive au test avant que le service réel ne soit appelé dans le dernier gestionnaire (Transport Stage). Jetez un coup d’œil à cet article pour avoir une idée de la façon dont cela peut être implémenté,

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

Cordialement, Pablo.

Answer 2

J'ai écrit la plupart du code HttpClient. La suggestion de Pablo est ce que j'ai fait dans les tests unitaires - voir FixedTransport.cs dans le code source.