Создайте класс, который можно протестировать

Question

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

Answer 1

Ну, есть разница между "прокси-класс знает, как создать экземпляр себя" и "класс знает, как создать экземпляр прокси-класса".Второе значительно усложняет модульное тестирование (если не невозможно), если вы упаковываете эти знания внутрь.

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

Answer 2

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

public class MyProxy : IProxiedInterface
{
    private IProxiedInterface _Target;

    public MyProxy(IProxiedInterface target)
    {
        if(target == null)
            throw new ArgumentNullException("target");

        _Target = target;
    }

    // ToDo: Implement all functions from IProxiedInterface
    //       and delegate them to the target
    public bool DoSomething()
    {
        return _Target.DoSomething();
    }
}

Answer 3

Вы должны предоставить зависимости класса для класса посредством внедрения зависимости (конструктор, свойство, параметр). Это делает ваш класс тестируемым и позволяет имитировать все эти зависимости.

UPDATE: Введите сервисный прокси:

class Foo
{
   private IServiceProxy _serviceProxy;
   public Foo(IServiceProxy _serviceProxy)
   {
        _serviceProxy = serviceProxy;
   }

   public void Bar()
   {
       var staff = _serviceProxy.GetStaff();
   }
} 

Кстати, попробуйте скрыть информацию о прокси от вашего класса. Например. реализовать через прокси-интерфейс тот же интерфейс, который есть у реальной службы, и предоставить IService вашему классу.

ОБНОВЛЕНИЕ 2 (шлюз):

Все наши доменные нужды - набрать персонал. Итак, мы определяем интерфейс:

interface IStaffService
{
  Staff GetStaff();
}

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

Далее создайте шлюз (см. Определение на сайте Мартина Фаулера) для вашей услуги:

public MyServiceProxyGateway : IStaffService
{
    public Staff GetStaff()
    {
       var proxy = new YourProxyType();
       proxy.X = value;
       proxy.Y = value;
       var response = proxy.CallActualServiceMethod();
       Staff staff = new Staff();
       staff.Value = response.Something;
       return staff;
    }
} 

Ваш код теперь совершенно не знает обо всей этой инфраструктуре связи. И вы используете удобный интерфейс GetStaff вместо CallActualServiceMethod.