Зависимость инъекции и макет рамки для .net

Я пытаюсь установить ожидания по методам издевающегося объекта в Moq. В то же время, используя Ninject, я стараюсь, чтобы ядро возвращало мою настроенную макет, всякий раз, когда вызывающему пользователю нужен соответствующий интерфейс. Для большей ясности, вот некоторые псевдокодЗависимость инъекции и макет рамки для .net

Class Car { 

    Void buildChassis() { 
     Engine = ObjectBuilder.get<Iengine>() 
     Engine.performCheckup() 
    } 
}

При тестировании buildChassis, я хочу, чтобы подключить издевались Engine.

Mock<Iengine>().setup().etc.etc.etc

Однако, Moq не играет с Ниндеком, я не могу этого добиться. Мне интересно, есть ли какие-нибудь надежные пакеты программного обеспечения, вокруг которых интегрируются DI и насмехаются. Я не могу заставить пакет ninject.moq работать и не кажется зрелым.

источник

2010-06-30 Andrei Tanasescu

Я использую и люблю Moq, но использую другой контейнер IoC, чем Ninject. Я никогда не чувствовал необходимости интегрировать фальшивые/изоляционные и контейнерные рамки IoC. Я использую инжектор конструктора, а затем просто передаю макет объектов моим классам в модульных тестах. Только производственный код использует контейнер.

ИМХО реальная проблема здесь в том, что автомобиль знает об объекте. Вместо использования контейнера в качестве локатора службы, почему бы не сделать инъекцию конструктора? Таким образом, только один класс верхнего уровня должен знать что-либо о контейнере IoC.

class Car 
{ 
    public Car(IEngine engine) 
    { 
     // May want a null check here 
     Engine = engine; 
    } 

    public IEngine Engine { get; private set; } 
}

Испытание автомобиля в изоляции очень просто; создайте mock IEngine и передайте его конструктору.

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

Если вы решили перейти на другую структуру IoC, вам нужно только изменить один или два класса верхнего уровня.

источник

2010-06-30 17:45:11 TrueWill

Ну, а в некоторых случаях вы действительно нужен эквивалент создания нового экземпляра класса, только чтобы добавить его в список, например. Как бы вы протестировали в этих случаях? (У меня есть эта потребность ...) –

@Andrei: Внесите IEngineFactory с помощью метода, который создает экземпляры IEngine (в одном случае, вы также можете ввести делегата). Moq может издеваться над фабрикой, после чего вы устанавливаете возвращаемое значение метода create, чтобы вернуть еще один макет. – TrueWill

См. Также http://www.tavaresstudios.com/Blog/post/Unity-20-Automatic-Factories.aspx - не уверен, что Ninject имеет эту функцию. – TrueWill

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

Но есть http://github.com/ninject/ninject.moq

источник

2010-07-01 08:47:01

Зависимость инъекции и макет рамки для .net

ответ

Смежные вопросы