Verwenden Sie Moq zum Mock Constructor?

Ich habe so einen Satz von Konstruktoren:Verwenden Sie Moq zum Mock 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) { }

jedoch bei der Prüfung/Verspottender ich das Objekt ohne eine der Verbindungszeichenfolge Parameter benötigen. Wie kann ich das machen - am besten in Moq?

Ist das überhaupt möglich?

Quelle

2010-06-04 Frank Michael Kraft

Es klingt, als ob Sie einen Code riechen - die constructor is doing too much work. Der Artikel enthält eine Reihe von Fixes für solche Szenarien. Grundsätzlich ist die Antwort zu nur führen Sie Zuweisung in den Konstruktoren durch, führen Sie Geschäftslogik nicht durch.

Quelle

2010-06-04 16:40:05 Finglas

Hrrm. Ich sehe das Argument in diesem Konzept. Auf der anderen Seite wollte ich den Benutzer des Objekts GenericBusinessObject davor schützen, über den Datenquellenkontext nachzudenken. Wenn ich Ihren Argumenten folge, dann muss der Benutzer des GenericBusinessObject darüber nachdenken. Das ist weniger Abstraktion. Vielleicht gibt es keinen anderen Weg, aber etwas lässt mich zögern. –

Stellen Sie eine Fabrik her oder verwenden Sie einen IOC-Conatainer, um diese Notwendigkeit für den Benutzer zu beseitigen, sich um den Datenkontext zu sorgen. – Finglas

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

Dies wird Null für Ihre zwei Parameter übergeben.

Ein anderer Ansatz wäre, einen internen Konstruktor zu erstellen, der nur für die Testverwendung gedacht ist, und InternalsVisibleTo zu verwenden, damit Ihre Testbaugruppe ihn verwenden kann. Leider hat dies einen großen Nachteil, wenn Sie Ihre Baugruppen signieren, Moq is unable to use the constructor. Dies soll jedoch in der 4.0 Version von Moq angesprochen werden.

Quelle

2010-06-04 16:36:09 womp

Der Nachteil eines internen Konstruktors ist, dass Sie jetzt Code schreiben, um Ihre Komponententests zu unterstützen. –

Ich würde argumentieren, dass das akzeptabel ist, wenn es eine absichtliche Anforderung gibt, dass die * public * API nicht injizierbar sein soll. Die einzige Zeit, in der Probleme auftreten würden, wäre, wenn Ihre Konstruktoren nicht einfach wären und Geschäftslogik enthielten - dann, wie das Sprichwort sagt, hätten Sie zwei Probleme ... – womp

Sehr einfache Lösung! Hat mir viel geholfen! –

Verwenden Sie Moq zum Mock Constructor?

Antwort

Verwandte Themen