Используя систему внедрения зависимостей, как вы тестируете свой код

Question

Насколько я вижу, есть два пути, оба со своими недостатками.

1. Получите объект, который вы тестируете, из системы внедрения зависимостей. Это низкие эксплуатационные расходы, так как вам не нужно ничего управлять, когда вы меняете структуру. Но вы, по сути, тестируете всю систему с точки зрения вашего объекта: если какой-либо компонент выходит из строя, он может взорвать множество модульных тестов и может не быть ясно, какой из них не работает.

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

Правильный или неправильный подход? Следует ли использовать компромисс? У кого-нибудь были истории успеха в любом случае.

Answer 1

Если вы пишете тест unit , вы должны использовать mocks для ваших зависимостей, и контейнер IoC не должен входить в картину. Вы должны создать экземпляр тестируемого класса с помощью макетов для зависимостей, введенных вручную.

Если вы получаете объект из контейнера IoC, уже подключенного, то вы пишете интеграционные тесты, которые сильно отличаются.

Ваша цель для написания модульного теста должна состоять в том, чтобы написать свой тест в изоляции от остальной системы.

Answer 2

Вы хотите использовать контейнер автоматической проверки для управления зависимостями для вас. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *] [2] В «StructureMap» встроен .

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

По моему мнению, первый подход неправильный, поскольку, как вы упомянули, тестируемый объект не обязательно приведет к сбою теста.