OK, I think I get it. Is this (then) really a bug report about "Rhino Mocks doesn't respect EQUALS overrides when performing its verification" ?
Steve Bohlen [email protected] http://blog.unhandled-exceptions.com http://twitter.com/sbohlen On Mon, Jun 21, 2010 at 2:35 PM, Dewy <[email protected]>wrote: > I don't want to override Equals in my object, I want to override the > way Rhino mocks is implementing the equals > > On Jun 21, 7:10 pm, Tim Barcz <[email protected]> wrote: > > Can you just override Equals() in whatever object type is returned > > by NewObjectUnderTest().WithProperty1("value1").Build(); > > > > The reason reference equality is used is that you've likely not > overridden > > Equals method. If you can tell .Net and by extension Rhino when two > objects > > are equal, the call below should work as you would like. > > > > On Mon, Jun 21, 2010 at 11:42 AM, Dewy <[email protected] > >wrote: > > > > > > > > > This is the thing, I don't want the objects to act different at all. I > > > want the objects to always use one type of equality, but using Rhino > > > Mocks as is will use refernce equality by default. > > > So, say I have a Mock service MyService and I can say something like: > > > > > [Test] > > > public void MyTest() > > > { > > > var objectUnderTest = > > > NewObjectUnderTest().WithProperty1("value1").Build(); // Using a > > > builder > > > > > objectUnderTest.MyService = MockMyService; // Setup in TestSetup > > > > > MockMyService.Expect(() => s => > > > s.SomeMethodCall(objectUnderTest)); > > > > > // do test > > > objectUnderTest.TestMethod(); // Changes Property1 to 'value2' > > > then calls SomeMethodCall > > > } > > > > > So, doing it this way works, but doesn't really tell me anything. What > > > I really want to do is something like: > > > > > [Test] > > > public void MyTest() > > > { > > > var objectUnderTest = > > > NewObjectUnderTest().WithProperty1("value1").Build(); // Using a > > > builder > > > > > objectUnderTest.MyService = MockMyService; // Setup in TestSetup > > > > > MockMyService.Expect(() => s => > > > > s.SomeMethodCall(NewObjectUnderTest().WithProperty1("value2").Build())); > > > > > // do test > > > objectUnderTest.TestMethod(); > > > } > > > > > And then have Rhino mocks use my version of equals but I don't want to > > > have to say use this contraint all over the place. > > > Does this make sense? > > > > > So, what I am looking for is way to change the default implementation > > > of equals within Rhino mocks, such that I don't have to change a line > > > in my tests, maybe in my test setups. > > > > > On Jun 21, 3:44 pm, Stephen Bohlen <[email protected]> wrote: > > > > I admit to some confusion about why you're trying to have objects > behave > > > one > > > > way (with value equality) when under test but not when in production > > > > (presumably reverting to their default reference equality). This > seems > > > to > > > > me to be at best confusing and worst rendering your tests mostly > useless. > > > > > > Can you expand a bit on the context of why you would even want this > in > > > your > > > > tests (as I am very curious)? > > > > > > Steve Bohlen > > > > [email protected]http://blog.unhandled-exceptions.comhttp:// > > > twitter.com/sbohlen > > > > > > On Mon, Jun 21, 2010 at 8:54 AM, Dewy < > [email protected] > > > >wrote: > > > > > > > In our tests we use Value Equality on our objects to check that > they > > > > > have the same values rather than being the same object. > > > > > When we set up expectations we have gotten around this by making > all > > > > > our objects be Value Objects (via base class and override of > Equals) > > > > > which we don't really want in the production code. > > > > > > > I see that there is a way to get around this by creating new > > > > > constraints where we can do as we see fit. > > > > > What I am really looking for is a way to override ALL equality for > all > > > > > mocks, such that we don't have to say on every Expect(...) that we > > > > > want to use a custom constraint, say some way to override this when > we > > > > > first create the MockRepository? > > > > > Is there a way already to do this? > > > > > > > -- > > > > > You received this message because you are subscribed to the Google > > > Groups > > > > > "Rhino.Mocks" group. > > > > > To post to this group, send email to [email protected]. > > > > > To unsubscribe from this group, send email to > > > > > [email protected]<rhinomocks%[email protected]> > <rhinomocks%[email protected]<rhinomocks%[email protected]> > > > > > <rhinomocks%[email protected]<rhinomocks%[email protected]> > <rhinomocks%[email protected]<rhinomocks%[email protected]> > > > > > > > > > . > > > > > For more options, visit this group at > > > > >http://groups.google.com/group/rhinomocks?hl=en. > > > > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "Rhino.Mocks" group. > > > To post to this group, send email to [email protected]. > > > To unsubscribe from this group, send email to > > > [email protected]<rhinomocks%[email protected]> > <rhinomocks%[email protected]<rhinomocks%[email protected]> > > > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/rhinomocks?hl=en. > > > > -- > > Tim Barcz > > Microsoft C# MVP > > Microsoft ASPInsiderhttp://timbarcz.devlicio.ushttp:// > www.twitter.com/timbarcz > > -- > You received this message because you are subscribed to the Google Groups > "Rhino.Mocks" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<rhinomocks%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/rhinomocks?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Rhino.Mocks" 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/rhinomocks?hl=en.
