RhinoMocks:Modo corretto di mock proprietà getter

Question

Sono nuovo di RhinoMocks, e cercando di ottenere una comprensione della sintassi in aggiunta a ciò che sta accadendo sotto il cofano.

Ho un oggetto utente, chiameremo Utente, che ha una proprietà chiamata IsAdministrator.Il valore per IsAdministrator è valutata per mezzo di un'altra classe che controlla le autorizzazioni di sicurezza, che restituisce true o false in base a tali autorizzazioni.Sto cercando di mock questa classe di Utenti, e falso il valore di ritorno per IsAdministrator al fine di isolare alcuni Test di Unità.

Questo è quello che sto facendo finora:

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

    // do something with my User object
} 

Ora, mi aspetto che Rhino è intenzione di 'falso' la chiamata alla proprietà getter, e appena di ritorno vero per me.Questo è errato?Attualmente sto diventando un'eccezione a causa di dipendenze nel IsAdministrator proprietà.

Qualcuno può spiegare come posso raggiungere il mio obiettivo?

Answer 1

Una breve nota prima di saltare in questo.In genere si desidera evitare l'uso di una "Rigorosa" finto perché rende fragile e test.Una rigorosa mock genererà un'eccezione se accade qualcosa che non si dica esplicitamente Rhino accadrà.Anche io penso che potrebbe essere equivoco esattamente quello che Rhino sta facendo quando si effettua una chiamata a creare una finta.Pensate a come un Oggetto personalizzato che è stato derivato da, o implementa il Sistema.Tipo definito.Se lo hai fatto anche tu, sarebbe simile a questa:

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

Dal IsAdministrator probabilmente è solo una proprietà pubblica il tipo di Utente non può ignorare in eredita tipo.

Per quanto riguarda la vostra domanda è interessato ci sono diversi modi si potrebbe gestire questo.Si potrebbe implementare IsAdministrator virtuale proprietà di classe utente aaronjensen menzionato come segue:

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

Questo è un buon approccio, ma solo se hai intenzione di ereditare dalla classe User.Anche se volete falso gli altri membri di questa classe dovranno anche essere virtuale, che probabilmente non è il comportamento desiderato.

Un altro modo per farlo è attraverso l'uso di interfacce.Se è veramente la classe Utente si vogliono Mock poi mi avrebbe estratto un'interfaccia da esso.Il tuo esempio precedente sarebbe simile a questa:

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
}

Si può ottenere di più carino se si desidera utilizzando l'iniezione di dipendenza e CIO ma il principio di base è la stessa su tutta la linea.In genere si desidera che le classi dipendono interfacce invece implementazioni concrete in ogni caso.

Spero che questo aiuta.Sono stato con RhinoMocks per un lungo periodo di tempo su un progetto importante, ora, non esitate a farmi domande sul TDD e beffardo.

Answer 2

Assicurarsi IsAdministrator è virtuale.

Inoltre, assicurarsi di chiamare, _mocks.ReplayAll()

Answer 3

_mocks.ReplayAll (), non fa nulla.Solo perché si utilizza SetupResult.Per() che non conta.Uso Previsto.Call() per essere sicuri che il codice non del tutto corretta.