Test public void SetupResultUsingOrdered() { SetupResult.For(demo.Prop).Return("Ayende"); using(mocks.Ordered()) { demo.VoidNoArgs(); LastCall.On(demo).Repeat.Twice(); } mocks.ReplayAll(); demo.VoidNoArgs(); for (int i = 0; i < 30; i++) { Assert.AreEqual("Ayende",demo.Prop); } demo.VoidNoArgs(); }When we use SetupResult.For() we tell Rhino Mocks: "I don't care about this method, it needs to do X, so just do it, but otherwise ignore it." Using SetupResult.For() completely bypasses the expectations model in Rhino Mocks. In the above example, we define demo.Prop to return "Ayende", and we can call it no matter what the currently expected method is.
What about methods returning void?
You would use LastCall.Repeat.Any(), which has identical semantics (ignore ordering, etc).
The opposite of SetupResult.For() is to specify that this method should never be called (useful if you're using dynamic mocks), which is done like this:
Expect.Call(view.Ask(null,null)).IgnoreArguments(). .Repeat.Never();This has the same semantics as ExpectNoCall() in NMock and this tells the framework that any call to this method is an error. Notice that I still call IgnoreArguments(), since otherwise the expectation would be specifically that this method never called with null as both parameters. Like SetupResult.For() and Repeat.Any(), using Repeat.Never() transcends ordering.
Note: If you want to have a method that can repeat any number of time, but still obeys ordering, you can use: LastCall.On().Repeat.Times(0,int.MaxValue). This does obey all of the normal rules.