Как протестировать Ninject ConstructorArguments с помощью объектов MOQ?

Есть несколько проблем с тем, как вы разрабатываете свое приложение. Прежде всего, вы вызываете ядро ​​Ninject прямо из своего кода. Это называется шаблоном локатора службы и считается анти-шаблоном. Это значительно усложняет тестирование вашего приложения, и вы уже сталкиваетесь с этим. Вы пытаетесь имитировать контейнер Ninject в своем модульном тесте, что чрезвычайно усложняет ситуацию.

Затем вы вводите примитивные типы (string, bool) в конструктор вашего DirEnum типа. Мне нравится, как MNrydengren заявляет об этом в комментариях:

принимать зависимости "времени компиляции" через параметры конструктора и зависимости "времени выполнения" через параметры метода

Мне сложно угадать, что должен делать этот класс, но поскольку вы вводите эти переменные, которые изменяются во время выполнения, в конструктор DirEnum, вы получаете приложение, которое трудно тестировать.

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

При использовании внедрения метода ваш класс Configurator будет выглядеть так:

class Configurator
{
    private readonly IDirEnum dirEnum;

    // Injecting IDirEnum through the constructor
    public Configurator(IDirEnum dirEnum)
    {
        this.dirEnum = dirEnum;
    }

    public ConfigureServices(string[] args)
    {
        var parser = new ArgParser(args);

        // Inject the arguments into a method
        this.dirEnum.SomeOperation(
            argParser.filePath
            argParser.fileFilter
            argParser.subDirs);
    }
}

Используя фабрику, вам нужно будет определить фабрику, которая знает, как создавать новые IDirEnum типы:

interface IDirEnumFactory
{
    IDirEnum CreateDirEnum(string filePath, string fileFilter, 
        bool includeSubDirs);
}

Ваш Configuration класс теперь может зависеть от IDirEnumFactory интерфейса:

class Configurator
{
    private readonly IDirEnumFactory dirFactory;

    // Injecting the factory through the constructor
    public Configurator(IDirEnumFactory dirFactory)
    {
        this.dirFactory = dirFactory;
    }

    public ConfigureServices(string[] args)
    {
        var parser = new ArgParser(args);

        // Creating a new IDirEnum using the factory
        var dirEnum = this.dirFactory.CreateDirEnum(
            parser.filePath
            parser.fileFilter
            parser.subDirs);
    }
}

Посмотрите, как в обоих примерах зависимости вводятся в класс Configurator. Это называется шаблоном внедрения зависимостей, в отличие от шаблона Service Locator, где Configurator запрашивает его зависимости, вызывая ядро ​​Ninject.

Теперь, поскольку ваш Configurator полностью свободен от какого-либо контейнера IoC, вы можете легко протестировать этот класс, внедрив имитируемую версию зависимости, которую он ожидает.

Осталось настроить контейнер Ninject в верхней части вашего приложения (в терминологии DI: корень композиции). В примере внедрения метода конфигурация вашего контейнера останется прежней, в примере с фабрикой вам нужно будет заменить строку Bind<IDirEnum>().To<DirEnum>() на что-то вроде следующего:

public static void Bootstrap()
{
    kernel.Bind<IDirEnumFactory>().To<DirEnumFactory>();
}

Конечно, вам нужно будет создать DirEnumFactory:

class DirEnumFactory : IDirEnumFactory
{
    IDirEnum CreateDirEnum(string filePath, string fileFilter, 
        bool includeSubDirs)
    {
        return new DirEnum(filePath, fileFilter, includeSubDirs);
    }        
}

ВНИМАНИЕ: обратите внимание, что фабричные абстракции в большинстве случаев не являются лучшим дизайном, как объяснялось в здесь.

Последнее, что вам нужно сделать, это создать новый экземпляр Configurator. Вы можете просто сделать это следующим образом:

public static Configurator CreateConfigurator()
{
    return kernel.Get<Configurator>();
}

public static void Main(string[] args)
{
    Bootstrap():
    var configurator = CreateConfigurator();

    configurator.ConfigureServices(args);
}

Здесь мы называем ядро. Хотя вызов контейнера напрямую следует предотвратить, в вашем приложении всегда будет хотя бы одно место, где вы вызываете контейнер, просто потому, что он должен все связать. Однако мы стараемся минимизировать количество прямых вызовов контейнера, потому что это улучшает, помимо прочего, тестируемость нашего кода.

Посмотрите, как я не ответил на ваш вопрос, но показал способ очень эффективного решения проблемы.

Возможно, вы все равно захотите протестировать свою конфигурацию DI. Это очень актуально, ИМО. Я делаю это в своих приложениях. Но для этого вам часто не нужен контейнер DI, или даже если он у вас есть, это не означает, что все ваши тесты должны иметь зависимость от контейнера. Эта связь должна существовать только для тестов, которые проверяют саму конфигурацию DI. Вот тест:

[TestMethod]
public void DependencyConfiguration_IsConfiguredCorrectly()
{
    // Arrange
    Program.Bootstrap();

    // Act
    var configurator = Program.CreateConfigurator();

    // Assert
    Assert.IsNotNull(configurator);
}

Этот тест косвенно зависит от Ninject и завершится ошибкой, если Ninject не сможет создать новый Configurator экземпляр. Когда вы очищаете свои конструкторы от какой-либо логики и используете их только для хранения взятых зависимостей в частных полях, вы можете запускать это без риска обращения к базе данных, веб-сервису или чему-то еще.

Надеюсь, это поможет.