Носорог и объекты, созданные с помощью операторов - PullRequest
Новая
       7

Носорог и объекты, созданные с помощью операторов

1 голос
/ 03 декабря 2010

Большую часть времени, когда мы используем макеты Rhino, это работает хорошо, но у нас есть проблемы с имитацией объектов, созданных с помощью с использованием операторов .

У нас есть прокси WCF, который реализован следующим образом: 

public class MyProxy : System.ServiceModel<IMyProxy>, IMyProxy
{
    public Response DoWork(Request request)
    {
         return base.Channel.DoWork(request);
    }
}

Обычно на нашем бизнес-уровне у нас было бы свойство: 

 IProxy MyProxy;

, которое мы могли бы установить как поддельный интерфейс.

Но когда мы используемС помощью выражения using наш бизнес-уровень выглядит следующим образом: 

using (MyProxy proxy = new MyProxy())
{
}

, который создает конкретную реализацию класса.

Как заставить бизнес-уровень использовать макет, созданный с помощью макетов Rhino??

Редактировать

Оказалось, что вы не должны использовать использование операторов с прокси wcf http://msdn.microsoft.com/en-us/library/aa355056.aspx

Ответы [ 3 ]

3 голосов
/ 03 декабря 2010

Введите Func<IProxy> в свой класс и сохраните его в поле.

Ваш код станет 

public class MyClass
{
    private readonly Func<IProxy> createProxy;

    public MyClass(Func<IProxy> createProxy)
    {
        if (createProxy == null)
            throw new ArgumentNullException("createProxy");
        this.createProxy = createProxy;
    }

    public void DoSomething()
    {
        using (IProxy proxy = this.createProxy())
        {
            ...
        }
    }
}

Ваш модульный тест будет выглядеть следующим образом: 

[Test]
void MyClass_does_something()
{
    var proxyStub = MockRepository.CreateStub<IProxy>();
    var myClass = new MyClass(delegate { return proxyStub; });

    myClass.DoSomething();

    // make assertions...
}

Обратите внимание, что больше связей , кроме простых "A требует B" и "A создает B".

Я предположил, что IProxy происходит от IDisposable здесь.Это немного упрощает: экземпляр прокси может также иметь собственные одноразовые зависимости, созданные контейнером.Вы не всегда можете просто предположить, что эти зависимости должны быть расположены одновременно с запрошенным объектом.Вот почему лучше использовать Owned<T>, как показано в сообщении в блоге, на которое я ссылался выше.

2 голосов
/ 03 декабря 2010

Я бы изменил код для использования системы IoC, чтобы он выглядел больше как: 

using (IMyProxy proxy = IoC.Resolve<IMyProxy>())
{
}

С IMyProxy наследованием IDisposable. Затем в тестовой среде настройте IoC для возврата макета вместо типа времени выполнения.

2 голосов
/ 03 декабря 2010

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

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

...