Как издеваться над веб-сервисом

Что я обычно делаю, так это создаю оболочку или адаптер вокруг своего веб-сервиса и просто издеваюсь над этим.

например:

public class ServiceAdapter: IServiceAdapter
{
    public void CallSomeWebMethod()
    {
        var someService = new MyWebService();
        someService.SomeWebMethod();
    }
}

Затем я просто заглушаю сервисный адаптер.

[Test]    
public void SomeMethod_Scenario_ExpectedResult()
{
    var adapterMock = new Mock<IServiceAdapter>();
    //do your test
}

в последнее время писал пару ответов о модульном тестировании и насмешках. В другом месте я писал, что важно спросить себя, что точно вы тестируете. Что касается вашей конкретной ситуации, я надеюсь, что ответ будет "Я тестирую бизнес-логику, которую раскрывает мой WebService", а не "Я тестирую свой WebService" - есть разница.

Если вас беспокоит на стороне сервера

Вам не нужно тестировать WebServices в целом. МС это уже сделал. Миллионы людей сделали это. Тестирование транспортного уровня, протокола, определения WebServices — пустая трата времени.

Вам нужно ориентироваться на свою бизнес-логику. Лучший способ сделать это — отделить бизнес-логику от веб-службы. Рассмотрим следующее

public class MyWebSevice : System.Web.Services.WebService
{
    private AuthenticationService _auth = new AuthenticationService ();
    private int _count = 0;
    [WebMethod]
    public string DoSomething ()
    {
        // embedded business logic, bad bad bad
        if (_auth.Authenticate ())
        {
            _count++;
        }
        return count.ToString ();
    }
}

нет способа проверить эту логику без прямого вызова WebService. То, что вы действительно хотите, это

public class MyService 
{
    // keeners will realise this too should be injected
    // as a dependency, but just cut and pasted to demonstrate
    // isolation
    private AuthenticationService _auth = new AuthenticationService ();
    private int _count = 0;
    public string DoSomething ()
    {
        if (_auth.Authenticate ())
        {
            _count++;
        }
        return count.ToString ();
    }
}

в производстве

// this web service is now a consumer of a business class,
// no embedded logic, so does not require direct testing
public class MyWebSevice : System.Web.Services.WebService
{
    private readonly MyService _service = new MyService ();

    [WebMethod]
    public string DoSomething ()
    {
        _service.DoSomething ();
    }
}

в тесте

// test business logic without web service! yay!
[Test]
public void Test_DoSomething ()
{
    MyService service = new MyService ();
    string actual = service.DoSomething ();
    // verify results
}

управление зависимостями [такими как член AuthenticationService] — это отдельная проблема. Однако, делая ваши WebMethods простыми переходами к соответствующим базовым бизнес-классам и полностью удаляя логику из них, вы можете нацеливаться на "реальный" пользовательский код, а не на сантехнику вашей типичной реализации WebService.

Если вас беспокоит клиентская сторона

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

public partial class MyWebService :
    System.Web.Services.Protocols.SoapHttpClientProtocol 
{
    ...
    public string DoSomething () { ... }
}

public class MyClient
{
    public void CallService ()
    {
        MyWebService client = new MyWebService ();
        client.DoSomething ();
    }
}

Здесь у вас есть проблемы с зависимостями, а именно вы не можете протестировать MyClient.CallService без создания экземпляра и размещения вашего веб-сервиса. Особенно неприятно, если вы не владеете или не размещаете указанную удаленную службу. В этом случае да, вы должны писать против интерфейса — еще раз, чтобы разделить и изолировать бизнес-логику.

public interface IMyWebService
{
    string DoSomething ();
}

public class MyWebServiceWrapper : IMyWebService
{
    public string DoSomething () 
    {
        MyWebService client = new MyWebService ();
        client.DoSomething ();
    }
}

public class MyClient
{
    private readonly IMyWebService _client = null;
    public MyClient () : this (new MyWebServiceWrapper ()) { }
    public MyClient (IMyWebService client)
    {
        _client = client;
    }
    public void CallService ()
    {
        _client.DoSomething ();
    }
}

в тесте

[Test]
public void Test_CallService ()
{
    IMyWebService mockService = null;
    // instantiate mock with expectations
    MyClient client = new MyClient (mockService);
    client.CallService ();
    // verify results
}

В общем, если зависимости класса являются внутрипроцессными службами, решение о применении шаблона, такого как внедрение зависимостей [DI] или инверсия управления [IoC], зависит от вас — и ваше желание изолировать и модульно протестировать эти службы будет информировать ваш дизайн. Однако, если зависимости класса выходят за границы процесса, например базы данных или веб-службы, я настоятельно рекомендую применять эти шаблоны, как мы делали выше.

На самом деле, это просто старая добрая разработка интерфейса. Вы, наверное, уже видите, как это окупается.

:)

Я написал об этом в блогедавным-давно. В основном, используя частичные классы и немного усилий (автоматизированных или ручных, в зависимости от того, как часто вы собираетесь изменять веб-службу), вы можете реализовать интерфейс прокси-класса веб-службы. Затем вы можете издеваться над ним, как обычно.

есть простой способ. например, если у нас есть класс WebService с именем DbService, сначала создайте для него интерфейс (например, IService) и используйте этот интерфейс для насмешек, затем добавьте класс в свой проект и поместите это:

public partial class DbService:IService {

}

оставьте класс пустым, поскольку веб-сервисы являются частичным классом, мы используем эту реализацию. (ранее