For the most part, I really like the new AAA syntax and the emphasis
on stubs.

1. I read in Emanuele DelBono's thread that it will no longer be
necessary to call Repeat.Any() on stubs. I'm assuming this didn't make
it into the RC, correct? Particularly for read-only properties, it's
painful to always write code like:

  thing.Stub(x => x.Name).Return("Bob").Repeat.Any();

2. Changing a stubbed return value later is still difficult, unless
I'm doing something wrong. I tried TentativeReturn, which didn't
appear to do anything. I want to be able to configure standard return
values in a setup fixture, then customize a subset of these values in
individual test cases. I can do it, but it's ugly:

    public interface ISomeThing
    {
        string Name { get; }
    }

    [Test]
    public void ReadOnlyPropertyChangeValueAfterRead()
    {
        ISomeThing thing = MockRepository.GenerateStub<ISomeThing>();
        thing.Stub(x => x.Name).Return("Bob").Repeat.Any();

        string previousValue = thing.Name;

        thing.BackToRecord();
        thing.Stub(x => x.Name).Return(previousValue + "
Smith").Repeat.Any();
        thing.Replay();

        Assert.That(thing.Name, Is.EqualTo("Bob Smith"));
    }

3. I am still confused about the proper usage of Do. In Ayende's post
( http://ayende.com/Blog/archive/2008/07/02/Rhino-Mocks-3.5-A-feature-t...

I don't get Arguments from IntelliSense. Say I have the following
member of an interface:

  int GiveMeOneMore(int aValue);

Can someone provide me a working code example of stubbing a return
value that returns whatever the parameter is plus one?

Thank you very much!

1/ not in the RC, will be in the release version.
2/ TentativeReturn is an internal call. The way you work is the way to do
it.
3/ the default intellisense is probably confused by what is going on there.
There are 2 Do overloads that likely put it into a spin.
It works with R#, *shrug*

  IMyThings things = MockRepository.GenerateStub<IMyThings>();

  things.Stub(x => x.GiveMeOneMore(0))
    .IgnoreArguments()
    .Return(0)
    .Do(invocation => invocation.ReturnValue =
(int)invocation.Arguments[0] + 1);

Error:

Cannot convert lambda expression to type 'System.Delegate' because it
is not a delegate type

(Interface shown below)

  public interface IMyThings
  {
    int GiveMeOneMore(int aValue);
  }

On Sep 30, 2:05 am, "Ayende Rahien" <aye...@ayende.com> wrote:

[Test]
public void MethodStubReturnBasedOnParameter()
{
    IMyThings things = MockRepository.GenerateStub<IMyThings>();

    things.Stub(x => x.GiveMeOneMore(0))
        .IgnoreArguments()
        .Do((Func<int, int>)(arg => arg + 1))
        .Repeat.Any();

    Assert.That(things.GiveMeOneMore(98), Is.EqualTo(99));
    Assert.That(things.GiveMeOneMore(99), Is.EqualTo(100));

Regarding the need for BackToRecord/Replay (#2 in the earlier post),
I'm unclear as to how "System.InvalidOperationException : The result
for IMyThings.GiveMeOneMore(5); has already been setup" adds value to
a mocking framework when dealing with stubs. It comes across as an
arbitrary limitation of Rhino Mocks. I'd really like to treat stubs as
mutable, malleable objects that my tests can change at will (and at
any time). Essentially I'd like PropertyBehavior on stubs, whether the
item in question is a read/write property, a read-only property, or a
method. Please consider offering more flexible behavior (at least as
an option) in the future.

Thank you!