Usa Moq per simulare Constructor?

Ho un tale insieme di Costruttori:Usa Moq per simulare Constructor?

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) { }

Tuttavia quando test/Mocking devo dell'oggetto senza uno dei parametri della stringa di connessione. Come posso fare questo - preferibilmente in Moq?

È possibile?

fonte

2010-06-04 Frank Michael Kraft

Sembra che si abbia un odore di codice: lo constructor is doing too much work. L'articolo include una serie di correzioni per tali scenari. Fondamentalmente la risposta è solo eseguire l'assegnazione nei costruttori, non eseguire la business logic.

fonte

2010-06-04 16:40:05 Finglas

Hrrm. Vedo l'argomento in questo concetto. D'altro canto volevo proteggere l'utente dell'oggetto GenericBusinessObject dal pensare al contesto dell'origine dati. Se seguo i tuoi argomenti, l'utente di GenericBusinessObject deve pensarci. Questa è meno l'astrazione. Forse non c'è altro modo, ma qualcosa mi fa esitare. –

Fabbrica una fabbrica o utilizza un Conatainer IOC per rimuovere questa necessità che l'utente si preoccupi del contesto dati. – Finglas

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

Questo passerà i valori nulli per i due parametri.

Un altro approccio potrebbe essere quello di creare un costruttore interno destinato esclusivamente all'uso di test e utilizzare InternalsVisibleTo per consentire al gruppo di test di utilizzarlo. Sfortunatamente questo ha un grosso inconveniente nel fatto che se si firmano i propri assembly, Moq is unable to use the constructor. Questo dovrebbe essere affrontato nella versione 4.0 di Moq però.

fonte

2010-06-04 16:36:09 womp

Lo svantaggio di un costruttore interno è che ora si sta scrivendo il codice per supportare i test dell'unità. –

Direi che è accettabile quando c'è un requisito intenzionale che l'API * public * non sia iniettabile. L'unica volta che presenterebbe i problemi sarebbe se i tuoi costruttori non fossero semplicistici e contenessero la logica di business - quindi, come si suol dire, avresti due problemi ... – womp

Soluzione molto semplice! Mi ha aiutato molto! –

risposta

Problemi correlati