RhinoMocks: forma correcta de burlarse del getter de propiedad

Question

Soy nuevo en RhinoMocks y trato de comprender la sintaxis además de lo que sucede bajo el capó.

Tengo un objeto de usuario, lo llamaremos Usuario, que tiene una propiedad llamada IsAdministrator. El valor de IsAdministrator se evalúa a través de otra clase que verifica los permisos de seguridad del Usuario y devuelve verdadero o falso en función de esos permisos. Intento burlarme de esta clase de Usuario y falsificar el valor de retorno de IsAdministrator para aislar algunas Pruebas Unitarias.

Esto es lo que estoy haciendo hasta ahora:

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

    // do something with my User object 
} 

Ahora, estoy esperando que Rhino va a 'falsa' la llamada a la propiedad de captador, y acaba de regresar fiel a mí. ¿Es esto incorrecto? Actualmente recibo una excepción debido a dependencias en la propiedad IsAdministrator.

¿Alguien puede explicar cómo puedo lograr mi objetivo aquí?

Answer 1

Una nota rápida antes de saltar en esto. Por lo general, desea evitar el uso de un simulacro "Estricto" porque es una prueba frágil. Una simulación estricta arrojará una excepción si ocurre algo que no le indique explícitamente a Rhino que sucederá. También creo que es posible que esté malinterpretando exactamente lo que está haciendo Rhino cuando realiza una llamada para crear un simulacro. Piénselo como un Objeto personalizado que se haya derivado de, o implemente, el Tipo de Sistema que usted definió. Si lo hizo usted mismo se vería así:

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

Desde IsAdministrator es probablemente sólo una propiedad pública del tipo de usuario que no puede anularlo en el tipo heredera.

En lo que respecta a su pregunta, existen varias maneras en que puede manejar esto. Se podría implementar IsAdministrator como una propiedad virtual en su clase de usuario tal como se ha mencionado aaronjensen de la siguiente manera:

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

Este es un enfoque bien, pero sólo si usted planea en la que hereda de la clase de usuario. Además, si no quieres falsificar a otros miembros de esta clase, también deberían ser virtuales, lo que probablemente no sea el comportamiento deseado.

Otra forma de lograr esto es mediante el uso de interfaces. Si realmente es la clase de Usuario que quieres simular, yo extraería una interfaz de ella. Su ejemplo anterior sería algo como esto:

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 
} 

Puede obtener más elegante si se desea usando dependency injection and IOC pero el principio básico es el mismo en todos los ámbitos. Normalmente, desea que sus clases dependan de las interfaces en lugar de las implementaciones concretas de todos modos.

Espero que esto ayude. He estado usando RhinoMocks durante mucho tiempo en un proyecto importante ahora, así que no dude en hacerme preguntas sobre TDD y burlas.

Answer 2

Asegúrate de que IsAdministrator sea virtual.

Además, asegúrese de llamar _mocks.ReplayAll()

Answer 3

_mocks.ReplayAll() no hará nada. Es solo porque usa SetupResult.For() que no cuenta. Use Expect.Call() para asegurarse de que su código haga todo lo correcto.