Тестирование конфигурации среды выполнения Unity

Question

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

Большинство моих вызовов разрешения происходят во время инициализации программы, поэтому проблема не так велика. Но я все еще хотел бы проверить это, идея могла бы состоять в том, чтобы настроить регистрацию контейнера и затем сканировать сборки для вызовов в container.resolve.

Я никогда не видел ничего подобного, поэтому я иду по неверному пути? и должен ли вместо этого блок / интеграционный тест это?

Answer 1

В некоторых контейнерах (StructureMap IIRC) есть методы, которые вы можете вызывать, чтобы попросить их самодиагностировать себя, но AFAIR Unity не имеет такого метода.

Я всегда сомневался, что самодиагностикаМетод обеспечивает большую ценность.Это только говорит о том, что компоненты, которые вы уже зарегистрировали, внутренне согласованы , но вы все равно можете попросить контейнер разрешить что-то, что никогда не было настроено с самого начала.Допустим, у вас настроены Foo, Bar и Baz.Они могут быть согласованы, но что, если вы попросите Qux?

Самодиагностика никогда не уловит такой сценарий.

Я бы скорее рекомендовал набор интеграционных тестов который пытается разрешить все соответствующие входные данные.Если следовать шаблону Register Resolve Release , набор входных данных для метода Resolve должен быть четко определен для данного приложения.