Rhino 3.5 questions - Repeat.Any, changing return values, Do syntax

414 views
Skip to first unread message

TrueWill

unread,
Sep 29, 2008, 11:15:54 PM9/29/08
to Rhino.Mocks
I'm working with the .Net 3.5 version of Rhino.Mocks 3.5 RC (I've got
tentative management approval to use it), and am still trying to
figure out some features.

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-to-be-proud-of.aspx
), he writes:

.Do(invocation => Assert.AreEqual("foo", invocation.Arguments[0]));

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!

Ayende Rahien

unread,
Sep 30, 2008, 3:05:01 AM9/30/08
to Rhino...@googlegroups.com
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*

TrueWill

unread,
Sep 30, 2008, 9:53:52 PM9/30/08
to Rhino.Mocks
1. Thanks!
2. Could it be made internal or hidden from IntelliSense, then?
3. I'm using R# 4.1. In any case, this does not compile with the RC:

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);

TrueWill

unread,
Sep 30, 2008, 10:14:26 PM9/30/08
to Rhino.Mocks
I figured out #3. This works:

[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));
}

The Func<int, int> is required, as is the Repeat.Any (for the second
Assert to work). I will be glad when the need for Repeat.Any goes
away.

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!
Reply all
Reply to author
Forward
0 new messages