Burlarse usando 'tradicional' Grabar/Reproducir frente al modelo Moq

Question

Soy nuevo en los simulacros y estoy decidiendo sobre un marco simulado. Las cotizaciones Moq home

Actualmente, es el biblioteca sólo burlona que va en contra de los (especialmente para los novatos) generalizadas y algo poco intuitivos Grabar/Responder enfoque de todos los otros marcos.

¿Alguien puede explicar simplemente qué es el enfoque Record/Replay y cómo difiere Moq? ¿Cuáles son los pros y los contras de cada uno especialmente desde el punto de vista de la decisión de un marco?

Gracias.

Answer 1

El enfoque Record/Replay es compatible con RhinoMocks. La idea básica es que la ejecución de la prueba se divide en dos fases, la fase de grabación y la fase de reproducción. Para ser un poco más concreto

var repo = new MockRepository(); 
var dependency = repo.DynamicMock<IDependency>(); 
With.Mocks(repo).Expecting(delegate { 
     Expect.Call(dependency.AMethod(1)).Return(result);      
     }).Verify(delegate { 
     var sut = new Sut(wrappee); 
     sut.DoStuffThatCallsAMethod(); 
     Assert.IsTrue(sut.ResultState); 
     }); 

Así el bloque Esperar es la fase de registro y el bloque Verify es la fase de reproducción.

La variante Moq de este código sería

var dependency = new Mock<IDependency>(); 
dependency.Expect(dep => dep.AMethod(1)).Returns(result);   
var sut = new Sut(wrappee.Object); 
sut.DoStuffThatCallsAMethod(); 
Assert.IsTrue(sut.ResultState); 

que como se puede ver es mucho más agradable de leer. Solía ​​usar RhinoMocks pero desde que descubrí Moq solo uso Moq. Me parece que se produce un código mucho más legible. Entonces mi consejo sería ir por Moq.

Answer 2

Me he salido de Grabar/Reproducir porque hace que sea difícil ver en la configuración lo que se replicó/burló o simplemente ejecutar el código. Creo que Rhino tiene múltiples formas de trabajar. En particular, puede usar un bloque using() para aislar la configuración de otras llamadas.

Answer 3

RhinoMocks es en realidad muy versátil, puede utilizar cualquier enfoque. RhinoMocks se ve un poco mejor que Moq bajo el estilo expect/verify. Sin embargo, incluso el hecho de que puede usar este estilo está oculto en la documentación (la última vez que miré). Seleccionamos Moq sobre RhinoMocks en mi proyecto actual porque no nos dimos cuenta de que configura/verifica.

La sintaxis de grabación/reproducción le da la capacidad de cambiar el valor que devolverá un método en llamadas posteriores a ese método. Esto puede ser útil a veces. Una vez dicho esto, la necesidad de hacer esto es a menudo un olor que su diseño no es del todo correcto. Aunque es útil cuando puedes ver lo que está mal y tienes que seguir adelante.

Moq tiene la capacidad de cambiar el valor, pero es un poco torpe (a partir de la documentación)

// returning different values on each invocation 
var mock = new Mock<IFoo>(); 
var calls = 0; 
mock.Setup(foo => foo.GetCountThing()) 
.Returns(() => calls) 
.Callback(() => calls++);