Переопределить привязку Ninject локально внутри тестового метода для привязки фиктивных объектов

Question

У меня следующая проблема, я хочу использовать Ninject в своих модульных тестах. Мои мысли об этом были такими:

1) Определить глобальную схему привязки внутри модуля для привязки моих поддельных объектов, которые я использую в тестах

2) При использовании макета привязать его локально внутри теста

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

Как мне это сделать, я использую c # и nunit. Если моя методология неверна, я бы хотел услышать правильную.

Answer 1

У меня та же проблема, и я понимаю, что это не очень хороший способ, но, со своей стороны, я делаю интеграционные тесты;не юнит-тесты.

Вот мое решение:

Kernel.Rebind<TypeToBind>().ToConstant(Mock.Object);

Где Kernel - это объект, который вы использовали для создания привязки.TypeToBind - это тип, который вы хотите внедрить в зависимость.Mock.Object - это объект, который вы предварительно настроили.

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

Answer 2

Вы не должны использовать свой контейнер IoC для создания объекта, который вы хотите протестировать в своих модульных тестах. Вместо этого создайте его вручную, используя new, и передайте объект-заглушку для каждого аргумента конструктора.

Answer 3

Я думаю, что использование IoC Framework для тестов - это идеальный способ сделать это.Фактически, именно поэтому IoC существовал в первую очередь, а затем появились фреймворки.Guice (платформа Google DI-инъекций Java) на самом деле поддерживает эту функцию, когда вы передаете в Модуль с производственными привязками, а затем передаете TestModule, который может переопределить определенные привязки с помощью mockobjects, а затем вы можете выполнить тестирование.Мы занимались этим, и это было очень чисто в течение длительного времени в Java.Я сейчас вхожу в себя, пытаясь заставить мои тесты перепривязывать вещи, сохраняя при этом оставшиеся привязки ....

Существуют также фреймворки, такие как AtUnit, где вы должны использовать фреймворк DI для тестированияобъекты и НЕ используют новое ключевое слово вообще. (к сожалению, я пока не вижу порт этой платформы для C # land :().

ПРИМЕЧАНИЕ. Причина этого желательна, когда люди добавляютновое связывание в производственном модуле, а затем использовать его в одной из моих тестируемых систем, оно не перестает работать с исключениями nullpointer, потому что интерфейс не был связан в тесте. люди продолжают добавлять, а тест продолжает работать. На мой взгляд, выследует использовать только ключевое слово «new» с dtos и тому подобное, и вся логика biz должна быть связана с DI, что позволяет легко добавлять тесты сейчас или в более поздний момент, а также довольно легко (хотя я сам сначала добавляю тесты).