Hi Patrick, interesting idea - maybe i try a similar approach next time i need a 'recursive-stub'. You're absolutly right with your assumption about the properties - as always real world is more complicated ;-)
I also understood the argument with the untested parts. But especially if that parts are tested with other test (e.g. there are mocks that verify some expectations on that object) and now i have another test that wants to test a completely other expectation - this test just ignores the 'recursive-stub'. Imagine that a new property is introduced into the existing interface. I'll also write a new test to verify that fake.NewProperty.XYZ=5 is set. By why must i adapt old test code to now also stub the NewProperty? So my hope was that if had a 'recursive-stub' in the old test - i didn't have to adapt old code if a new property is used in the production code. O.k. i think my that explanation was confuse - i hope you can follow ;-) Andreas On 27 Mai, 14:05, Patrick Steele <[email protected]> wrote: > Not that I know of. Is is really that hard to add one more line? > > fake.SomeProperty = MockRepository.GenerateStub<PropertyType>(); > > I guess if you had a lot of properties, it might become cumbersome. > Then again, if you've got a lot of properties you're calling methods > on, they're probably an important part of the class you're testing and > you may want to set some expectations on them. > > It is an interesting idea. I played around with trying to create an > extension method that would use reflection to recursively generate > stubs, but there's some tricky issues (like how to set a return value > on a read-only property without using a lambda). And the recursive > nature of the stubbing caused an issue too. > > public static void StubDeep<T>(this T mock) where T:class > { > Type t = typeof (T); > foreach (var prop in t.GetProperties(BindingFlags.Public | > BindingFlags.Instance).Where(prop => !prop.PropertyType.IsSealed)) > { > var subMock = MockRepository.GenerateStub(prop.PropertyType); > if (prop.CanWrite) > { > prop.SetValue(mock, subMock, new object[] {}); > } > else > { > //TOOD: How to set up a Stub() on a just a 'Type' > // and a 'PropertyInfo'? I.e. no lambda. > //mock.Stub(m => m.Property).Return(subMock); > } > > // this doesn't work as the typeof "subMock" is > // reported as "Object" inside StubDeep(). > subMock.StubDeep(); > } > > } > > There may be easy fixes for those two issues, but I haven't played > around much with reflection on generic types. > > --- > Patrick Steelehttp://weblogs.asp.net/psteele > > On Thu, May 27, 2010 at 4:47 AM, haifisch <[email protected]> wrote: > > Hello, > > > is there a simple way to create a recursive stub in RhinoMocks? > > Some thing like TypeMock's fake. > > > var fake = Isolate.Fake.Instance<SomeType>(); > > > //code under test can > > > fake.SomeProperty.DoSomething() > > > //or > > > var propObj = fake.SomeProperty; > > propObj.DoSomething(); > > > (http://weblogs.asp.net/rosherove/archive/2009/07/09/minimizing-unit- > > test-fragility-8-features-in-typemock-isolator-to-help.aspx) > > > I'm aware that there are only special cases where such a feature might > > make sense, but sometimes i just want stub a parameter object - > > without any expectations on its usage. > > > Best regards, > > > Andreas -- 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.
