RhinoMocks: la bonne façon de se moquer d'un getter de propriété

Question

Je suis nouveau dans RhinoMocks et j'essaie de comprendre la syntaxe en plus de ce qui se passe sous le capot.

J'ai un objet utilisateur, nous l'appellerons utilisateur, qui a une propriété appelée IsAdministrator. La valeur de IsAdministrator est évaluée via une autre classe qui vérifie les autorisations de sécurité de l'utilisateur et renvoie true ou false en fonction de ces autorisations. J'essaie de me moquer de cette classe d'utilisateurs et de simuler la valeur renvoyée pour IsAdministrator afin d'isoler certains tests unitaires.

C'est ce que je fais jusqu'à présent:

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

    // do something with my User object
} 

Maintenant, j'attends que Rhino "simule" l'appel de l'accesseur de propriétés, et me le retourne comme il convient. Est-ce incorrect? Actuellement, je reçois une exception en raison de dépendances dans la propriété IsAdministrator.

Quelqu'un peut-il expliquer comment je peux atteindre mon objectif ici?

Answer 1

Un petit mot avant de me lancer. En règle générale, vous souhaitez éviter l'utilisation d'un " Strict " se moquer parce que cela donne un test fragile. Un simulacre strict lancera une exception s'il se produit quelque chose que vous ne dites pas explicitement à Rhino. De plus, je pense que vous ne comprenez peut-être pas exactement ce que fait Rhino lorsque vous appelez pour créer une maquette. Considérez-le comme un objet personnalisé dérivé ou implémentant le System.Type que vous avez défini. Si vous le faisiez vous-même, cela ressemblerait à ceci:

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

IsAdministrator n'étant probablement qu'une propriété publique du type User, vous ne pouvez pas le remplacer dans le type hérité.

En ce qui concerne votre question, vous pouvez gérer cela de plusieurs manières. Vous pouvez implémenter IsAdministrator en tant que propriété virtuelle sur votre classe d'utilisateurs sous la forme aaronjensen mentionné comme suit:

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

Cette approche est correcte, mais uniquement si vous envisagez d’hériter de votre classe User. De plus, si vous ne voulez pas imiter d'autres membres de cette classe, ils devront également être virtuels, ce qui n'est probablement pas le comportement souhaité.

L’utilisation d’interfaces constitue un autre moyen d’y parvenir. Si c'est vraiment la classe utilisateur que vous voulez simuler, j'en extraire une interface. Votre exemple ci-dessus ressemblerait à quelque chose comme ceci:

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
}

Vous pouvez vous perfectionner si vous le souhaitez en utilisant injection de dépendance et IOC , mais le principe de base est le même à travers le conseil. En règle générale, vous voulez que vos classes dépendent d’interfaces plutôt que d’implémentations concrètes.

J'espère que cela aide. J'utilise RhinoMocks depuis longtemps sur un projet majeur, alors n'hésitez pas à me poser des questions sur le TDD et les moqueries.

Answer 2

Assurez-vous que IsAdministrator est virtuel.

Assurez-vous également d'appeler _mocks.ReplayAll ()

Answer 3

_mocks.ReplayAll () ne fera rien. C'est simplement parce que vous utilisez SetupResult.For () que cela ne compte pas. Utilisez Expect.Call () pour vous assurer que votre code réponde à toutes les exigences.