Почему не работает следующая насмешка с Ninject.Moq? - PullRequest
1 голос
/ 15 августа 2010

Я пытаюсь запустить следующий код с Ninject.Moq:

[TestMethod]
public void TestMethod1()
{
    var kernel = new MockingKernel();
    var engine = kernel.Get<ABC>();

   //as I don't need to actually use the interfaces, I don't want
   //to even have to bother about them.

    Assert.AreEqual<string>("abc", engine.ToString());
}

А вот определение класса ABC:

public class ABC {
    IA a;
    IB b;

    public ABC(IA a, IB b)
    {
        this.a = board;
        this.b = war;
    }

    public override string ToString()
    {
        return "abc";
    }
}

Я получаю следующее исключение:

System.ArgumentException: Соответствующий конструктор для заданных аргументов не был найден в макетированном типе.---> System.MissingMethodException: конструктор для типа 'AbcProxya759aacd0ed049f3849aaa75e2a7bade' не найден.

Ответы [ 2 ]

3 голосов
/ 19 августа 2010

Хорошо, это заставит код работать:

[TestMethod]
public void TestMethod1()
{
    var kernel = new MockingKernel();
    kernel.Bind<Abc>().ToSelf();
    var engine = kernel.Get<ABC>();

   //as I don't need to actually use the interfaces, I don't want
   //to even have to bother about them.

    Assert.AreEqual<string>("abc", engine.ToString());
}

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

2 голосов
/ 16 августа 2010

Это немного похоже на понимание DI в первом place : - маленькие сэмплы на самом деле не отражают всю суть.

Контейнер для автоматической блокировки, такой как Ninject.Moq (или подобные библиотеки инфраструктуры тестирования, такие как AutoFixture ), трудно объяснить на простом примере. Я бы посоветовал прочитать все посты Марка Симанса о AutoFixture , чтобы почувствовать требование.

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

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

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

...