Твердость Внедрения зависимости и поблочное тестирование
Как указал Невилл; Это дискуссионная тема, и нет ничего действительно правильного или неправильного.
Мое мнение таково, что API должен быть независимым от пользовательского интерфейса. Так что, если исключение выдает исключение ... все в порядке, чтобы отбросить его обратно ... и пусть клиент справится с этим или решит, что делать с этим исключением. Потому что некоторые клиенты могут захотеть показать красивое удобное для пользователя сообщение; в то время как другому клиенту может потребоваться фактическое сообщение (например, если другой API вызывает этот API).
5 ответов
Это плохая практика - вызывать решимость для контейнера? Я мог бы создать экземпляр ServiceValidator в Main () и передать объект, но это кажется глупым, поскольку это вызвало бы множество параметров для объектов, которые просто передаются следующему методу.
Когда вы используете внедрение зависимостей, все Кстати, тогда вам не нужно будет передавать множество параметров объектам. Конструктор каждого объекта должен иметь в качестве параметров только те зависимости, которые он сам использует напрямую - он не будет знать о транзитивных зависимостях своих прямых зависимостей.
Так что если у вас есть класс X, который требует ServiceValidator, то класс X будет иметь параметр конструктора типа ServiceValidator. Тогда, если некоторый класс Y использует класс X, тогда класс Y будет иметь параметр конструктора типа X. Обратите внимание, что Y ничего не знает о ServiceValidator, поэтому вам не нужно передавать ServiceValidator из одного класса в другой - единственное место, где он используется, - это конструирование X, и это часто делается DI. каркас или только в одном месте на рукописной фабрике.
Некоторые ссылки для получения дополнительной информации:
- http://martinfowler.com/articles/injection.html
- http://www.youtube.com / watch? v = RlfLCWKxHJ0 - на ваш вопрос о прохождении объектов ответили, начиная с 19:20 "Миф о DI"
I usually allow calls to resolve dependencies from the container in places like main although I still try to keep them to a minimum. What I then do is configure the container in an initialization method of a test class. I have it initialized with fake implementations for any test class which needs to call the container.
Test classes which don't call anything requiring the container be initialized are then able to ignore it and not use the fakes. I usually use mocks in those instances.
I also use the Microsoft Service Locator so that the dependency that I am taking is on something from the .NET Framework instead of on a specific container. This allows me to down the road use anything I want even a home brewed container.
Вы можете использовать статический класс в качестве инициализатора для вашего контейнера. Что-то вроде BootStrapper.cs будет хорошо. Затем вы можете ссылаться на методы класса как в своем коде, так и в тестах.
Что вы делаете технически, так это расположение службы в вашем классе. .
Я помню, как читал эту статью некоторое время назад:
http://martinfowler.com/articles/injection.html
Для своих занятий я никогда не пытаюсь использовать в них Resolve. Я создаю объекты через контейнер, когда они мне нужны. Для модульного тестирования я использую некоторые фиктивные библиотеки и классы-заглушки.
Проблема заключается в том, что вы пытаетесь протестировать метод Main. Этот метод практически невозможно для модульного тестирования.
Я бы сказал, что лучше не проводить модульное тестирование вашего метода Main, потому что:
- Основное внимание в модульном тестировании уделяется проектированию
- . Вы должны минимизировать зависимость от конфигурации в модульных тестах. Конфигурация может быть проверена с помощью дыма или интеграционных тестов.