Ok, I left the code as 2.0 syntax and uploaded
RecursiveMocksSameObjectInstance.patch

Couple comments:

Each item in the DependentMocks list has an array of ImplementedTypes
- I don't understand why that is an array, but am searching the array
just to be safe.

If there are multiple methods/properties with the same return type, I
think this will return the same instance for those as well. I would
think that would not be desired but wanted to check here before trying
to go any further with that.

On Oct 17, 6:07 am, "Ayende Rahien" <[EMAIL PROTECTED]> wrote:
> Did I says thanks for doing that already?
>
> On Fri, Oct 17, 2008 at 12:54 PM, Jason Meckley <[EMAIL PROTECTED]>wrote:
>
>
>
>
>
> > I don't think there is an official position on this since Rhino is
> > very organic in nature. I like the rule of thumb. If the feature is
> > for AAA syntax than the code and supporting test can be written
> > specifically for 3.5.  If the feature is available for 2.0 then I
> > would write a test using 2.0 syntax.
>
> > If the code doesn't compile for 2.0 then someone (usually me) will
> > update the syntax so it's compatible for 2.0.  If you do have a test
> > which is 3.5 syntax specific. the simples solution for backwards
> > compatibility is to surround the entire file with an precompile
> > statement like this. the statements are case sensative
>
> > #if DONTET35
> > using ...
>
> > public class
> > {
> >   ...tests go here
> > }
> > #end if
>
> > On Oct 16, 10:51 pm, webpaul <[EMAIL PROTECTED]> wrote:
> > > After walking away from it for a few days was able to get in just 10
> > > or 15 minutes when I came back. I've got it returning the same
> > > instance now and not breaking any of the existing tests. The first
> > > test worked only because it was returning null. :) So ignore that.
>
> > > Is it ok to use LINQ in Rhino mocks or are you still supporting .NET
> > > 2.0? I have some foreach statements I wouldn't mind using a LINQ query
> > > for. Change was made in TryCreateReturnValue in Impl/RecordMockState
>
> > >         [Test]
> > >         [Ignore("Not supported in replay mode")]
> > >         public void WillGetSameInstanceOfRecursedMockInReplayMode()
> > >         {
> > >             //RhinoMocks.Logger = new
> > > TraceWriterExpectationLogger(true, true, true);
>
> > >             MockRepository mocks = new MockRepository();
> > >             var mock = mocks.DynamicMock<IMyService>();
> > >             mocks.Replay(mock);
>
> > >             IIdentity i1 = mock.Identity;
> > >             IIdentity i2 = mock.Identity;
>
> > >             Assert.AreSame(i1, i2);
> > >             Assert.IsNotNull(i1);
> > >         }
>
> > >         [Test]
> > >         public void
> > > WillGetSameInstanceOfRecursedMockWhenNotInReplayMode()
> > >         {
> > >             //RhinoMocks.Logger = new
> > > TraceWriterExpectationLogger(true,true,true);
>
> > >             var mock = new MockRepository().DynamicMock<IMyService>();
>
> > >             IIdentity i1 = mock.Identity;
> > >             IIdentity i2 = mock.Identity;
>
> > >             Assert.AreSame(i1, i2);
> > >             Assert.IsNotNull(i1);
> > >         }
>
> > > On Oct 10, 7:16 am, webpaul <[EMAIL PROTECTED]> wrote:
>
> > > > Simon is certainly right in that I've bit off a bigger piece than I
> > > > thought I was. I've only used Rhino Mocks in a few limited ways and
> > > > didn't realize there was more to it, so clearly I need to take some
> > > > more time to understand things. Seems like the style here is to go
> > > > away, finish a problem and come back instead of talking about it while
> > > > working on it. So I'll spend some more time understanding things and
> > > > see what I can do then.
>
> > > > On Oct 10, 6:41 am, "Ayende Rahien" <[EMAIL PROTECTED]> wrote:
>
> > > > >http://ayende.com/Blog/archive/2008/10/10/recursive-mocking.aspx
>
> > > > > On Wed, Oct 8, 2008 at 6:32 AM, webpaul <[EMAIL PROTECTED]> wrote:
>
> > > > > > Regarding
>
> >http://ayende.com/Blog/archive/2008/10/08/rhino-mocks-challenge-imple...
> > > > > > :
>
> > > > > > Do you expect that Identity is not null in this test and should
> > have
> > > > > > an implementation? If so, I'm curious whether you expect changes to
> > > > > > Castle.DynamicProxy.ProxyGenerator or not. In the below test
> > > > > > mockService.Identity is null and gives an exception as such. Do you
> > > > > > expect that and want that fixed or am I missing something?
>
> > > > > >    public interface ISomeInterface
> > > > > >    {
> > > > > >        string Name { get; set; }
> > > > > >    }
>
> > > > > >    public interface IMyService
> > > > > >    {
> > > > > >        ISomeInterface Identity { get; set;}
> > > > > >    }
>
> > > > > >    [TestFixture]
> > > > > >        public class FluentMocksTests
> > > > > >        {
> > > > > >                [Test]
> > > > > >                public void CanCallSomeRandomInterfaceProperty()
> > > > > >                {
> > > > > >            var mockService =
> > > > > > MockRepository.GenerateMock<IMyService>();
> > > > > >            Expect.Call(mockService.Identity.Name).Return("foo");
> > > > > >            Assert.AreEqual("foo", mockService.Identity.Name);
> > > > > >                }
> > > > > >        }- Hide quoted text -
>
> > > > > - Show quoted text -- Hide quoted text -
>
> > > > - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Rhino Tools Dev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/rhino-tools-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to