Rhino 3.5 bugs in read/write properties

[TrueWill]

I've encountered two bugs in Rhino.Mocks v3.5 for .NET 3.5 when
dealing with interface properties; the combination has proved to be a
showstopper.

Given:

public interface ISomeThing
{
string Name { get; }

int Number { get; set; }
}

The following NUnit tests fail:

[Test]
public void ReadWritePropertyBug1()
{
ISomeThing thing = MockRepository.GenerateStub<ISomeThing>();
thing.Number = 21;
thing.Stub(x => x.Name).Return("Bob");
Assert.That(thing.Number, Is.EqualTo(21));
// Fails - calling Stub on anything after
// setting property resets property to default.
}

[Test]
public void ReadWritePropertyBug2()
{
ISomeThing thing = MockRepository.GenerateStub<ISomeThing>();
thing.Stub(x => x.Number).Return(21);
// InvalidOperationException :
// Invalid call, the last call has been used...
// This broke a test on a real project when a
// { get; } property was changed to { get; set; }.
}


I realize there are workarounds to both of these bugs (set read/write
properties last, use PropertyBehavior to set read/write properties
instead of Stub), but the first would require significant redesign of
numerous tests in our code base and the second prevents us from simply
not using PropertyBehavior. The second also leads to fragile tests, as
mentioned in the above comment.

If these could be resolved for the release version of 3.5, it would
ease adoption in our company. Thank you!

[Ayende Rahien]

Are you using the RC version or the trunk?

[Tim Barcz]

Oren can you confirm if this is a bug or not?  I was bumping into this the other day and thought that maybe I was doing something wrong....

[Ayende Rahien]

I would like to know which version this is happening. On the face of it, it doesn't look like it should do it.

[Tim Barcz]

I was having similar issues with 3.5.0.2 the other day.  How similar it is to the scenario below I don't remember the exact scenario.

[TrueWill]

The RC.

[Tim Barcz]

Oren,

Can I help by checking or verifying something?

[Ayende Rahien]

please try thetrunk and see if it is stil an issue

[TrueWill]

I do not have Subversion, nor am I experienced in its use.

I've provided unit tests that replicate the bugs. If you add them to
your test suite, you'll gain regression testing for these issues as
well.

I realize that you're under no obligation to fix these issues. I'm
simply reporting them and stating that they will prevent wider
adoption of your software.

Thank you

On Oct 4, 2:28 am, "Ayende Rahien" <aye...@ayende.com> wrote:
> please try thetrunk and see if it is stil an issue
>

[TrueWill]

P.S. If you were replying to Mr. Barcz, I misunderstood, and I
apologize.

[Ayende Rahien]

The first one is fixed, the second is a problem in the test itself. I added support for detecting and giving a good error on this scenario:
[TestFixture]
public class FieldProblem_TrueWill
{

    [Test]
    public void ReadWritePropertyBug1()
    {
        ISomeThing thing = MockRepository.GenerateStub<ISomeThing>();
        thing.Number = 21;
        thing.Stub(x => x.Name).Return("Bob");

        Assert.AreEqual(thing.Number, 21);

        // Fails - calling Stub on anything after
        // setting property resets property to default.
    }

    [Test]

    [ExpectedException(typeof(InvalidOperationException), @"You are trying to set an expectation on a property that was defined to use PropertyBehavior.
Instead of writing code such as this: mockObject.Stub(x => x.SomeProperty).Return(42);
You can use the property directly to achieve the same result: mockObject.SomeProperty = 42;")]

    public void ReadWritePropertyBug2()
    {
        ISomeThing thing = MockRepository.GenerateStub<ISomeThing>();
        thing.Stub(x => x.Number).Return(21);
        // InvalidOperationException :
        // Invalid call, the last call has been used...
        // This broke a test on a real project when a
        // { get; } property was changed to { get; set; }.
    }
}

On Fri, Oct 3, 2008 at 11:56 PM, TrueWill <bi...@truewill.net> wrote:

[TrueWill]

Thank you very much.

Since PropertyBehavior appears to be on by default for stubs created
by GenerateStub, is there a way to turn it off? I would like to be
able to use the same syntax regardless of whether a property is read-
only or read-write. While it does make the setup more verbose, it
makes the tests less fragile by protecting from interface changes.

In other words, adding a setter to an existing interface breaks
mockObject.Stub(x => x.SomeProperty).Return(42);
while removing a setter from an existing interface breaks
mockObject.SomeProperty = 42;

Thanks,
Bill Sorensen

[Tim Barcz]

As a rhino user I don't know that I would want that feature...

I wouldn't consider a change to a contract (an interface) something a
test should just absorb.

I don't like fragile test but do you thiink that a failing test when
an interface changes is a sign of fagility?

Curious.

Tim

--
Sent from my mobile device

[Ayende Rahien]

You can use a mock instead of a stub, and only use Stub().