Это все будет работать только для относительно простых завимостей, инстанциирование которых достаточно легкое и не требует настройки. Например, если у вас есть свой сериализатор, наверное не имеет большого смысла заменять его моком. Из моего опыта: обычно никто для таких объектов моки и не создает.
Ситуация меняется, когда зависимость имеет свои зависимости, часть из которых кстати может быть внешними. И в таком случае вам вместо того, чтобы например «замочить» один какой-нибудь вызов Validate, придется разобраться, что там этот Validate делает, к каким сервисам обращается и все это настроить. И приведет это к тому, что Arrange фаза такого теста может разрастись до огромных размеров.
Еще такой подход не будет работать или будет работать с большим трудом, когда над разными компонентами работают разные люди, так как кроме своих собственных проблем вам еще придется разгребать и проблемы коллег.
С коллекцией все ясно, я про нее ничего и не писал.
Я писал про то, что если возвращать пустую строку в качестве «null object», то это точно не про принцип наименьшего удивления. Нулевая ссылка гораздо понятнее и привычнее.
NullReferenceException хотя бы виден. А string.Empty ничем не отличается от любой другой строки: без вдумчивого чтения метода догадаться, что его нужно определенным образом обрабатывать, шансов мало.
AV1135
А чем в общем случае null строка в качестве результата хуже, чем пустая строка? Если пустая строка символизирует что-то определенное (например то, что что-нибудь не найдено), то уж лучше null, а еще лучше использовать AV1140 с null object или метод с out параметром.
Если мне не изменяет память, Марк в своей книге Dependency Injection in .NET описывал ваш подход как «внедрение зависимостей через свойства» (property injection) и допускал его использование как минимум в следующих случаях:
1) Зависимость нужна в большинстве классов (ваш случай, еще один хороший пример это какой-нибудь ILogger)
2) Зависимость имеет значение по умолчанию
3) Классы зависят друг от друга
Только я не понял, зачем во втором случае вы делаете свойства protected, сделайте их публичными, тогда они станут частью контракта класса без всякой магии.
А зачем это вам знать, какие свойства и как заданы? Это ответственность класса, он например может задекорировать какой-либо из переданных параметров прозрачно для вас, как для потребителя.
Это наверное может быть удобнее в случае каких-либо простых DTO с большим кол-вом необязательных свойств, но пример из статьи явно не об этом.
Из минусов обновления: расширение Resharper.StyleCop, которое работало в 9.1, в этой версии пока отстутствует в Extension Manager. Надеюсь, его создатели это исправят.
Совсем без плясок не получится, в реализации по умолчанию используется конструктор Mock без параметров. Чтобы это изменить, надо немного расширить AutoMoqCustomization: вместо MockConstructorQuery, который как раз и выбирает этот самый простой конструктор, написать свой, который выбирает правильный конструктор с параметром Strict.
По поводу F#: угу, я тоже заметил. У него и курсов на эту тему на PluralSite довольно много, и в блоге записей порядочно.
Запустить и проверить юнит-тест в IDE дело нескольких секунд, а всякие удобные штуки типа nCrunch вообще запускают их автоматически. А вот выполнить из UI какого-нибудь запрос, который в итоге создаст заказ и отправит это письмо, это точно не пара секунд. А потом вы меняете пару строк в этом сервисе и приходится опять лезть в этот UI и опять создавать заказ. Я уж не говорю о том, что UI может и не быть на данном этапе разработки, либо он разрабатывается параллельно и вообще не стабилен.
Абстракция уровня доступа к данных как раз об этом — бизнесу не должно быть важно, как берутся данные.
Ситуация меняется, когда зависимость имеет свои зависимости, часть из которых кстати может быть внешними. И в таком случае вам вместо того, чтобы например «замочить» один какой-нибудь вызов Validate, придется разобраться, что там этот Validate делает, к каким сервисам обращается и все это настроить. И приведет это к тому, что Arrange фаза такого теста может разрастись до огромных размеров.
Еще такой подход не будет работать или будет работать с большим трудом, когда над разными компонентами работают разные люди, так как кроме своих собственных проблем вам еще придется разгребать и проблемы коллег.
Я писал про то, что если возвращать пустую строку в качестве «null object», то это точно не про принцип наименьшего удивления. Нулевая ссылка гораздо понятнее и привычнее.
А чем в общем случае null строка в качестве результата хуже, чем пустая строка? Если пустая строка символизирует что-то определенное (например то, что что-нибудь не найдено), то уж лучше null, а еще лучше использовать AV1140 с null object или метод с out параметром.
1) Зависимость нужна в большинстве классов (ваш случай, еще один хороший пример это какой-нибудь ILogger)
2) Зависимость имеет значение по умолчанию
3) Классы зависят друг от друга
Только я не понял, зачем во втором случае вы делаете свойства protected, сделайте их публичными, тогда они станут частью контракта класса без всякой магии.
Это наверное может быть удобнее в случае каких-либо простых DTO с большим кол-вом необязательных свойств, но пример из статьи явно не об этом.
var house = new House{Kitchen=new Kitchen()};
Как минимум можно забыть / не знать про необходимость инициализации этого свойства и получить объект в несогласованном состоянии.
По поводу F#: угу, я тоже заметил. У него и курсов на эту тему на PluralSite довольно много, и в блоге записей порядочно.