Как выполнить тестирование WCF-клиента, созданного с помощью WCF Rest Starter Kit

Question

Я создал некоторые POX-сервисы, используя комплект REST Starter. Сначала было сложно создать единичные тесты для уровня сервиса, но в конце концов он был хорошо разработан и мне удалось издеваться над контекстом и установить ожидания.

Но теперь я начинаю с клиентской стороны, и у меня возникают проблемы с выяснением того, как насмехаться над вещами. Это не так прямо.

Итак, у меня есть этот образец метода, который отправляет через HTTP некоторые данные, используя datacontract и XML в качестве транспорта.

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

Этот метод работает и действительно публикует данные и сериализуется правильно.

Что я хочу сделать, это проверить его.

Мои вопросы:

1. Как сделать окурки/издевается для HttpContextExtensions, зная, что он не реализует любой интерфейс?

2. И для HttpClient? это худшее, так как он полон методов расширения, определенных в другом месте (Post и подобные методы являются расширениями).

В 2. Я думаю, что я могу придерживаться «Отправить», и это перегрузками, но та же проблема, как и в 1

То, что я думал сделать, чтобы извлечь интерфейсы для HttpContextExtensions и HttpClient, создайте для каждого ребенка и реализуйте интерфейсы, делегирующие родителям, а затем используя интерфейсы в моем коде.

Но это очень много работы ИМХО.

Я использую RhinoMocks в качестве моей издевательской структуры, поэтому я не могу издеваться над определенными классами, и я хотел бы придерживаться этого, потому что я действительно думаю, что насмешливые конкретные классы не очень элегантны.

Итак, есть ли более чистый/быстрый/более умный способ модульного тестового кода, как указано выше?

PD: Это для WCF Starter Kit просмотра 2

Answer 1

Если вы действительно хотите, чтобы дразнить этот код, такой подход, который мог бы работать для этого сценария является то, чтобы получить экземпляр HttpClient в классе ServiceClient. Класс HttpClient содержит конвейер обработки, который можно настроить с помощью настраиваемых обработчиков. Для ваших тестов вы можете вставлять обработчик в этот экземпляр httpclient, чтобы возвращать посмеянный ответ на тест до того, как реальный сервис вызывается в последнем обработчике (этап транспорта). Посмотрите на этот пост, чтобы получить представление о том, как это может быть реализовано,

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

С уважением, Пабло.

Answer 2

Я написал большую часть кода HttpClient. Предложение Пабло - это то, что я сделал в модульных тестах - см. FixedTransport.cs в исходной ZIP-версии.