Interesting. I never realized there was a difference. I usually use #1. The only time I create a MockRepository and use it (#2) is when I need to test some old legacy code and a partial mock is my best option.
The possible issues I see with #2 is that, as your example shows, if you don't set up a specific return value for GetSomeData, you'll still get back a non-null object. This sounds dangerous to me since your app may depend on null/non-null meaning something. If the method call always returns a non-null value even when you didn't tell the stub to return a non-null value, it could makes your tests harder to read and less reliable. That's my 2 cents... --- Patrick Steele http://weblogs.asp.net/psteele On Thu, Feb 17, 2011 at 7:12 PM, Cvetomir Todorov <[email protected]> wrote: > Hi, > > The documentation says: > > 1) public static T GenerateStub<T>(params object[] argumentsForConstructor) > where T : class > > Generates a stub without needing a Rhino.Mocks.MockRepository > > 2) public T Stub<T>(params object[] argumentsForConstructor) > > Create a stub object, one that has properties and events ready for use, and > can have methods called on it. It requires an explicit step in order to > create an expectation for a stub. > > Can you tell me the difference between 1) and 2). Experimentally I found > that for example when we have this interface: > > public interface ITest > { > DataClass GetSomeData(ParameterClass param); > } > > and we create a stub using 2), then the calls to GetSomeData will return a > test double. But if we've created the object, using 1), then calls would > return null. In both cases we haven't prepared the stubs to return > predefined values. What looks to me is happening is that using 2) it will > always return default value for value types and a test double for reference > types. > > I find the difference between objects created with 1) and 2) confusing. Is > there a place in the documentation pointing out this and eventually other > differences, so that I can read and choose which one to use? > > -- > Software modules coupling is the path to the dark side. > Coupling leads to complexity. > Complexity leads to confusion. > Confusion leads to suffering. > Once you start down the dark path, forever will it dominate your destiny, > consume you it will! > > -- > 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. > -- 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.
