tdd - RhinoMocks: forma correcta de burlarse de propiedades getter

rhino-mocks

Question

Soy nuevo en RhinoMocks y trato de entender 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 vaya a ''falsificar'' la llamada al comprador de propiedades, y solo me devuelva la verdad. ¿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

Asegúrese de que IsAdministrator sea virtual.

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

Answer 2

_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.

Answer 3

Una nota rápida antes de saltar a 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 hicieras tú mismo, se vería así:

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

Como IsAdministrator es probablemente solo una propiedad pública en el tipo de Usuario, no puede anularlo en el tipo heredado.

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

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

Este es un enfoque aceptable, pero solo si planea heredar de su 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 se vería así:

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 lo desea utilizando inyección de dependencia y COI, 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.