Rhino Mocks 3.5 Design DecisionsGetting closer to conclusion
There has been an invaluable amount of discussion regarding the question I pose about the API design of Rhino Mocks 3.5. Jeremy Gray in particular has been helpful in making good suggestions and making the argument to simplify the API for developers who are not experts in TDD terminology and usage.
My current thinking is to combine GenerateMock() and GenerateStub() into a single method, GenerateTestDouble(). This method will return a dynamic mock.
If you want a true stub, you will be able to call myTestDouble.StubUnexpectedInteractions(). Note, since stubs have a special behavior for properties, I am also considering: myTestDouble.StubPropertiesAndUnexpectedInteractions(); .
If you want a strict mock, you will be able to call myTestDouble.FailOnUnexpectedInteractions();
Partial mock will not be supported by the static GenerateTestDouble method, and will require using the usual instance methods.
Calling VerifyAllExpectations() will be supported on all mocks.
The only remaining open question is whatever calling Expect() on an object that you previously called StubUnexpectedInteractions() should fail or not.