2010-06-04 2 views
21

У меня есть такой набор Конструкторов:Используйте Moq, чтобы высмеять конструктор?

public BusinessObjectContext() 
     : this(CloudStorageAccount.FromConfigurationSetting("DataConnectionString").TableEndpoint.ToString(), 
       CloudStorageAccount.FromConfigurationSetting("DataConnectionString").Credentials) {} 

public BusinessObjectContext(string dataConnectionString) 
     : this(CloudStorageAccount.Parse(dataConnectionString).TableEndpoint.ToString(), 
       CloudStorageAccount.Parse(dataConnectionString).Credentials) { } 

public BusinessObjectContext(String baseAddress, StorageCredentials credentials) 
     : base(baseAddress, credentials) { } 

Однако при тестировании/Дразнящей мне нужна объект без какого-либо из параметров строки соединения. Как я могу это сделать - предпочтительнее в Moq?

Возможно ли это вообще?

ответ

17

Звучит так, как будто у вас есть запах кода - constructor is doing too much work. Статья содержит набор исправлений для таких сценариев. В основном ответ только выполнять назначение в конструкторах, а не выполнять бизнес-логику.

+0

Hrrm. Я вижу аргумент в этой концепции. С другой стороны, я хотел защитить пользователя объекта GenericBusinessObject от размышлений о контексте источника данных. Если я следую вашим аргументам, пользователь GenericBusinessObject должен подумать об этом. Это меньше абстракции. Может быть, нет другого пути, но что-то заставляет меня стесняться. –

+1

Создайте завод или используйте Conacainer IOC, чтобы устранить эту проблему, чтобы пользователь мог беспокоиться о контексте данных. – Finglas

26
var myMockBOC = new Mock<BusinessObjectContext>(null, null); 

Это приведет к нулевым значениям для двух параметров.

Другим подходом было бы создание внутреннего конструктора, предназначенного только для использования тестов, и использовать InternalsVisibleTo, чтобы ваша тестовая сборка использовала его. К сожалению, это имеет большой недостаток в том, что если вы подписываете свои сборки, Moq is unable to use the constructor. Это, как предполагается, будет рассмотрено в 4.0 релизе Moq.

+6

Недостатком внутреннего конструктора является то, что теперь вы пишете код для поддержки ваших модульных тестов. –

+2

Я бы сказал, что это приемлемо, если существует целенаправленное требование, чтобы * public * API не был инъекционным. Единственный раз, когда будут возникать проблемы, было бы, если бы ваши конструкторы не были упрощенными и содержали бизнес-логику, - тогда, как говорится, у вас возникнут две проблемы ... – womp

+0

Очень простое решение! Помог мне много! –

Смежные вопросы