El uso de burla de Rhino para burlarse de un parámetro de salida, que se crea en el método que estoy probando

Question

Tratar de burlar el siguiente método:

bool IsLoginValid(LoginViewModel viewModel, out User user); 

probado este principio:

dependency<ILoginService>() 
.Stub(serv => 
     serv.IsLoginValid(
      Arg<LoginViewModel>.Is.Equal(a_login_viewmodel), 
      out Arg<User>.Is.Anything) 
.Return(false); 

embargo, que no logra , ya que es un parámetro de salida. Hice un poco de búsqueda y alteré mi código como tal:

dependency<ILoginService>() 
.Stub(serv => 
     serv.IsLoginValid(
      Arg<LoginViewModel>.Is.Equal(a_login_viewmodel), 
      out Arg<User>.Out(new User()).Dummy)) 
.Return(false); 

Eso también falla. Necesito que 'nuevo usuario()' sea una especie de argumento 'Cualquier cosa'. Como creo que está esperando una instancia específica.

¿Alguna idea de cómo evitar esto? Gracias chicos.

Answer 1

Pruebe la opción "OutRef". Acepta un objeto params [] que define el resultado para cada parámetro de salida. Como solo tienes uno, solo necesitas un resultado. He aquí una rápida maqueta de lo que he intentado eso debería funcionar en su situación:

var foo = MockRepository.GenerateStub<IFoo>(); 
var viewModel = new LoginViewModel(); 
User temp; 
foo.Stub(f => f.IsLoginValid(viewModel, out temp)).OutRef(new User()).Return(false); 

User outparam; 
Assert.IsFalse(foo.IsLoginValid(viewModel, out outparam)); 

Answer 2

Cambio de la respuesta aceptada (por @Patrick Steele) para que coincida con los nombres de las variables y espacios en blanco en la pregunta:

.Stub(serv => serv.IsLoginValid(
      a_login_viewmodel, 
      out temp)).OutRef(new User()) 
.Return(false); 

... a continuación, cambiar la sintaxis (pero no la semántica) a la fluidez Args sintaxis:

.Stub(serv => serv.IsLoginValid(
      Arg<LoginViewModel>.Is.Equal(a_login_viewmodel), 
      out Arg<User>.Out(new User()).Dummy)) 
.Return(false); 

... entonces nos encontramos con exactamente la misma sintaxis que el segundo intento de la OP, whic h aparentemente "falla". Personalmente, prefiero el estilo fluido de 'Args', aunque es un poco más detallado.

TL; DR el segundo intento del OP es semánticamente equivalente a la respuesta aceptada, simplemente utiliza una sintaxis diferente.