Конфигурация времени тестирования Unity

Question

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

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

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

Answer 1

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

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

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

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