> 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!

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

>> 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!

> On Fri, Oct 3, 2008 at 4:01 PM, Ayende Rahien <aye...@ayende.com> wrote:

>> Are you using the RC version or the trunk?

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

>>> 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!

> On Sat, Oct 4, 2008 at 3:16 AM, Tim Barcz <timba...@gmail.com> wrote:

>> 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....

>> On Fri, Oct 3, 2008 at 4:01 PM, Ayende Rahien <aye...@ayende.com> wrote:

>>> Are you using the RC version or the trunk?

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

>>>> 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!

> The RC.

> On Oct 3, 4:01 pm, "Ayende Rahien" <aye...@ayende.com> wrote:
> > Are you using the RC version or the trunk?

> The RC.

> On Oct 3, 4:01 pm, "Ayende Rahien" <aye...@ayende.com> wrote:
> > Are you using the RC version or the trunk?

> 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!

> 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

> On Oct 4, 3:10 pm, "Ayende Rahien" <aye...@ayende.com> wrote:
> > 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 <b...@truewill.net> wrote:

> > > 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!