Rhino ¿Se burla de los trozos de sobrescritura?

Question

tengo este problema, que puede ser un error en la burla de Rhino 3.5:

stubObj = MockRepository.GenerateStub(IObject); 

stubObj.Stub(a=>a.Get()).Return (Guid.Empty); //1.stub 
stubObj.Stub(a=>a.Get()).Return (Guid.NewGuid()); //2.stub, should overwrite the first one? 

esto:

var value = stubObj.Get(); 

vuelve Guid.Empty, es este el comportamiento correcto?

Answer 1

Las siguientes pruebas deben pasar:

// arrange 
var stubObj = MockRepository.GenerateStub<IObject>(); 
stubObj.Stub(a => a.Get()) 
     .Return(Guid.Empty); 
// act 
var value = stubObj.Get(); 
// assert 
Assert.AreEqual(Guid.Empty, value); 

Y si usted quiere devolver un nuevo GUID:

// arrange 
var stubObj = MockRepository.GenerateStub<IObject>(); 
stubObj.Stub(a => a.Get()) 
     .Return(Guid.NewGuid()); 
// act 
var value = stubObj.Get(); 
// assert 
Assert.AreNotEqual(Guid.Empty, value); 

Answer 2

acaba de programar el objeto de código auxiliar para dos llamadas separadas. Si llama a stubObj.Get nuevamente, debe obtener lo que Guid.NewGuid generó. Puede preparar su objeto falso para cualquier cantidad de invocaciones de diferentes tipos. Por este motivo, no tiene sentido esperar que la última llamada .Stub para una invocación determinada reemplace los llamados .Stub anteriores de esa llamada.

En su código de prueba, que debe ser breve y ordenado, nunca debería haber un caso en el que deba 'deshacer' tal programación del simulacro en la forma en que parezca querer hacerlo.

Si lo que debe devolverse es una cuestión condicional que varía según otros bits del código de prueba en varias llamadas a este bloque de código, lo último que desea es que la magia haga que los lectores tengan que descubrir qué significado. Si es condicional, debes aclararlo.

Y luego, cuando se ha dejado claro, refactorearlo como usted no debe tener lógica condicional en las pruebas (véase Patrones de prueba xUnit)

Answer 3

Si desea devolver el GUID una serie vacía conocido de veces , lo único que tienes que hacer es decirle a RhinoMocks cuántas veces se debe repetir, por ej. la siguiente prueba pasa:

[Test] 
    public void MultipleStubsTest() 
    { 
     var testMock = MockRepository.GenerateMock<ITest>(); 
     testMock.Stub(x => x.Get()).Return(Guid.Empty).Repeat.Once(); 
     testMock.Stub(x => x.Get()).Return(Guid.NewGuid()); 

     Assert.AreEqual(Guid.Empty, testMock.Get()); 
     Assert.AreNotEqual(Guid.Empty, testMock.Get()); 
    } 

si usted no sabe cuántas veces Get() será llamado ante el GUID debe cambiar, que siempre se puede utilizar .No() y el código de allí (por favor me deje saber si necesitas más detalles).

Answer 4

Así es como lo harías. Pasa en mi máquina.

[TestMethod] 
    public void Test() 
    { 
     stubObj = MockRepository.GenerateMock<IGuidTest>(); 

     stubObj.Stub(a => a.Get()).Repeat.Times(1).Return(Guid.Empty); 
     stubObj.Stub(a => a.Get()).Repeat.Times(1).Return(Guid.NewGuid()); 

     Assert.AreEqual(Guid.Empty, stubObj.Get()); 
     Assert.AreNotEqual(Guid.Empty, stubObj.Get()); 

    } 
    public IGuidTest stubObj; 
    public interface IGuidTest 
    { 
     Guid Get(); 
    } 

Answer 5

Sí, este es el comportamiento esperado. Escribir las expectativas/stubs de esa manera le dice al marco burlón que devuelva Guid.Empty la primera vez que se llama al método Get() y devuelve Guid.NewGuid() la segunda vez que se invoca.

Estas son algunas maneras de "sobrescribir" la primera expectativa con la segunda: How to change behaviour of stubs?