RhinoMocks: Richtige Art und Weise Eigenschaft Getter zu verspotten

Question

Ich bin neu in RhinoMocks, und versuche, ein Verständnis für die Syntax zusätzlich zu dem, was unter der Haube geschieht.

Ich habe einen User zum Gegenstand haben, werden wir es Benutzer, rufen die eine Eigenschaft namens IsAdministrator. Der Wert für IsAdministrator wird über eine andere Klasse ausgewertet, der die Benutzersicherheitsberechtigungen überprüft, und gibt entweder wahr oder falsch ist, basierend auf diesen Berechtigungen. Ich versuche, diese User-Klasse zu verspotten und gefälschten den Rückgabewert für IsAdministrator um einige Unit-Tests zu isolieren.

Das ist, was ich tue so weit:

public void CreateSomethingIfUserHasAdminPermissions()
{
    User user = _mocks.StrictMock<User>();
    SetupResult.For(user.IsAdministrator).Return(true);

    // do something with my User object
} 

Nun, ich erwarte, dass Rhino den Anruf an der Eigenschaft Getter ‚fake‘ wird, und kehrt nur mir treu. Ist das nicht richtig? Derzeit eine Ausnahme erhalte ich aufgrund von Abhängigkeiten in der IsAdministrator Eigenschaft.

Kann mir jemand erklären, wie ich hier mein Ziel erreichen?

Answer 1

Eine kurze Notiz, bevor ich in diesen springen. Normalerweise sollten Sie die Verwendung eines „Strenge“ mock vermeiden, weil es für einen spröden Test macht. Eine strenge Mock wird eine Ausnahme, wenn etwas geschieht werfen, dass Sie nicht explizit sagen Rhino passieren wird. Ich denke auch, dass Sie genau sein Unverständnis, was Rhino tut, wenn Sie einen Anruf tätigen ein Mock zu erstellen. Betrachten Sie es als ein benutzerdefiniertes Objekt, das entweder von abgeleitet wurde oder implementiert die System.Type Sie definiert. Wenn Sie es selbst täte, würde es so aussehen:

public class FakeUserType: User
{
    //overriding code here
}

Da IsAdministrator ist wahrscheinlich nur ein öffentliches Eigentum auf dem Benutzertyp Sie können es in dem Vererbungstyp nicht außer Kraft setzen.

Was Ihre Frage betrifft, gibt es mehrere Möglichkeiten, wie Sie damit umgehen können. Sie könnten IsAdministrator als virtuelles Eigentum auf Ihrer Benutzerklasse als aaronjensen erwähnt wie folgt:

public class User
{
    public virtual Boolean IsAdministrator { get; set; }
}

Dies ist ein oker Ansatz, aber nur, wenn Sie auf erben von Ihrer Benutzerklasse planen. Auch wenn Sie zu fälschen andere Mitglieder dieser Klasse wan't würden sie auch virtuell sein müssen, das ist wahrscheinlich nicht das gewünschte Verhalten.

Eine andere Möglichkeit, dies zu tun ist durch die Verwendung von Schnittstellen. Wenn es wirklich die Klasse User sind Sie wollen verspotten, dann würde ich eine Schnittstelle daraus extrahieren. Ihr obige Beispiel wie folgt aussehen würde:

public interface IUser
{
    Boolean IsAdministrator { get; }
}

public class User : IUser
{
    private UserSecurity _userSecurity = new UserSecurity();

    public Boolean IsAdministrator
    {
        get { return _userSecurity.HasAccess("AdminPermissions"); }
    }
}

public void CreateSomethingIfUserHasAdminPermissions()
{
    IUser user = _mocks.StrictMock<IUser>();
    SetupResult.For(user.IsAdministrator).Return(true);

    // do something with my User object
}

können Sie erhalten schicker, wenn Sie mit Hilfe wollen Dependency Injection und IOC aber das Grundprinzip ist die auf der ganzen Linie gleich. Normalerweise wollen Sie Ihre Klassen auf Schnittstellen hängen, anstatt konkrete Implementierungen sowieso.

Ich hoffe, das hilft. Ich habe an einem Großprojekt RhinoMocks für eine lange Zeit jetzt mit so zögern Sie nicht, mir Fragen über TDD und spöttisch zu fragen.

Answer 2

Stellen Sie sicher, IsAdministrator ist virtuell.

Auch sicher sein, rufen Sie _mocks.ReplayAll ()

Answer 3

_mocks.ReplayAll () wird nichts tun. Es ist nur, weil Sie verwenden SetupResult.For (), die zählt nicht. Verwenden Sie Expect.Call () sicher sein, dass Ihr Code tun alles korrekt ist.