Юнит-тестирование регистрации IoC?

Question

Стоит ли тестировать код, который регистрирует компоненты в вашем контейнере IoC?

Если да, то как?

Answer 1

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

Обычно я использую операторы Debug.Assert в процедурах инициализации моих классов. Это дает мне систему раннего предупреждения об ошибках, связанных с IoC, а также помогает лучше определять зависимости в моем коде.

Answer 2

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

Answer 3

Что я делаю с контейнером IoC Guice , так это то, что сначала я создаю классы для некоторой функции, использующей TDD без Guice (это модульные тесты). Затем я создаю интеграционный тест для этой функции с Guice. В этот момент конфигурация IoC (модуль Guice) является неполной, поэтому проверка интеграции не будет выполнена. Используя TDD, я добавляю конфигурацию IoC шаг за шагом, пока тест интеграции не пройдет. Я не буду добавлять аннотацию @Inject, строку конфигурации или объявление области видимости, если только это не требуется для прохождения теста. В результате у меня будут интеграционные (или приемочные) тесты, чтобы убедиться, что конфигурация IoC верна и завершена.

Этот же метод должен работать с любым контейнером IoC или другой системой, конфигурация которой настолько сложна, что может сломаться - не пишите никакую конфигурацию, если не требуется пройти тест.

Answer 4

@ aku, @krosenvold и @mookid приводят веские аргументы для проверки правильности конфигурации зависимостей.
Я не думаю, что это юнит тестирование, хотя.
Что ты тестируешь? Вы не пытаетесь выполнить модульное тестирование самого контейнера (возможно, это не тот код, который вы написали или используете).
То, что вы пытаетесь проверить, - это то, что все зависимости определенного типа могут быть созданы и что тип может быть разрешен. Это звучит как довольно полезный системный тест или интеграционный тест для вашей среды непрерывной интеграции.
Поэтому, когда у вас есть исполняемые файлы, которые проходят модульное тестирование, вы можете создать контейнер и запустить настройку для контейнера на машине, которая отражает вашу производственную среду, и проверить, что каждый из типов, которые контейнер должен разрешить, может быть действительно создан и все их зависимости могут быть созданы.
Было бы неплохо запустить это на новой виртуальной машине, к которой вы применили свой последний установщик.

Answer 5

Ответ на этот вопрос специально для Замок Виндзор :

Замок Виндзор: Как проверить, что все зарегистрированные компоненты разрешимы?

Answer 6

Это может быть полезно, потому что некоторые инфраструктуры внедрения зависимостей (например, Unity) имеют странные правила для выбора конструктора для вызова. Я определенно рекомендую юнит-тестирование, чтобы убедиться, что регистрация и создание вашего типа прошло успешно.

Answer 7

Я использую Windsor в проекте ASP.NET MVC, где я написал простой тест для проверки возможности создания всех контроллеров (т. Е. Их зависимости могут быть разрешены).

У меня есть тест для каждой конфигурации веб-сайта (например, «разработка», «тест», «someProductionSite» и т. Д.), Где я создаю свой контейнер Windsor с этой конкретной конфигурацией и перебираю все неабстрактные реализации IController, проверяя, могу ли я разрешить экземпляр каждого.

Поскольку фабрика контроллеров является единственной точкой входа в приложение, которая приведет к созданию контейнера. Решение (...), я на 100% уверен, что все конфигурации действительны.

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

например. Я также утверждаю, что все действия контроллера являются виртуальными, что является обязательным требованием, поскольку я использую автоматическое управление транзакциями Касла для окружения действий контроллера транзакциями.

Answer 8

Поскольку ваши компоненты могут иметь свои собственные зависимости или выполнять некоторую инициализацию, я бы охватил этот сценарий с помощью UT.

Что-то вроде

iocContainer.Register(typeof(MyService1));
service = iocContainer.Get(typeof(MyService));
Debug.AssertNotNull(service);