Korrekte Anwendung von Mock-Objekten in Unit Testing

Question

Ich habe eine PresenterFactory, die Presenter-Klassen basierend auf einem Role-Parameter erstellt. Insbesondere ist die Rolle Parameter eine externe Klasse, die ich nicht kontrollieren kann

Meine Fabrik sieht ungefähr so ​​aus (IE 3rd-Party.):

public class PresenterFactory { 
    public Presenter CreatePresenter(Role role, ...) { 
     if (role.IsUserA("Manager")) { 
      return new ManagerPresenter(...) 
     } 
     if (role.IsUserA("Employee")) { 
      return new EmployeePresenter(...) 
     } 
    } 
} 

Ich bin fest, wie das Gerät zu testen für diese schreiben seit dem Erstellen des Objekts Role erzwingt einen Datenbankzugriff. Ich dachte, ich könnte dieses Objekt verspotten. Mein Test sah wie folgt aus:

public void TestPresenterFactory() 
{ 
    var mockRole = new Mock<Role>(); 

    mockRole .Setup(role=> role.IsUserA("Manager")) 
     .Returns(true) 
     .AtMostOnce(); 

    PresenterFactory.CreatePresenter(mockRole.Object, ...); 

    mockUserInfo.VerifyAll(); 
} 

aber ich erhalte eine ArguementException:

Ungültige Setup auf einem Nicht-overridable Mitglied: role => role.IsUserA ("Manager")

Ich bin mir nicht sicher, wo ich hingehen soll und kann sicher eine Kurskorrektur verwenden. Was mache ich falsch?

Answer 1

Sie können ein Wrapper-Objekt für Role erstellen, das über dieselben Methoden und Eigenschaften verfügt, aber mockbar ist, und die Standardimplementierung gibt einfach die zugrunde liegende Role-Implementierung zurück.

Dann können Ihre Tests die Wrapper-Rolle verwenden, um das gewünschte Verhalten einzurichten.

Dies ist oft ein Weg, um konkrete Klassen zu umgehen, die wirklich spotten müssen.

Answer 2

Sie möchten ein Mock-Objekt erstellen und dann dieses Mock-Objekt in Ihre CreatePresenter-Methode übernehmen. Auf dem Mock würden Sie alle Eigenschaften festlegen, die erforderlich sind, um festzustellen, um welche Art von Benutzer es sich handelt. Wenn Sie an dieser Stelle noch noch Abhängigkeiten von der Datenbank haben, dann können Sie das Refactoring Ihres Role-Objekts betrachten.

Answer 3

Erwägen Sie die Verwendung eines Mocking-Frameworks, das keine künstlichen Einschränkungen auferlegt (z. B. Anforderungen für virtuelle Methoden, Klassen, die nicht versiegelt werden sollen), wie Ihr Code als mockbar geschrieben werden muss. Das einzige Beispiel, von dem ich im .NET-Kontext weiß, ist TypeMock.

Answer 4

In Java wenn EasyMock Erweiterungen verwenden würden Sie in der Lage sein, „echte“ Objekte und Methoden zu verspotten, wahrscheinlich gibt es äquivalente oder alternative mock Rahmen, die Sie für Ihre Zwecke