Инъекция зависимостей и макет для .net

Question

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

Class Car {

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

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

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

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

Answer 1

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

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

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

    public IEngine Engine { get; private set; }
}

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

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

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

Answer 2

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

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