After having spent an evening trying to iron out the issues and coming up with a clearer understanding, these are my thoughts.
The legendary Martin Fowler have written a good article about this. The article suggest the word double as a generic form of objects which are utilized in testing scenarios in place of the real implementation. Stubs and mocks are therefore specific versions of doubles. A stub is described as primarily "returning canned answers" and secondarily remembering what was called, while a mock are pre-set with expectations about which calls should be made.
This means that stubs don't really care whether they were called or not. The mock object, on the other hand, enforces which calls should be made, in what order and with what parameters. Mocks are concerned with the behaviour, in addition to the end-result, whereas stubs are only concerned with the end-result. Stubs lends itself to state-based testing, given A,B,C perform X, expect A',B',C'. Mocks on the other hand also enforces how the end-state was derived at.
One could argue that as mocks dictates the behaviour of a method, they break encapsulation. However this is a double edged sword, as it can be used to flesh out behaviour in an iterative manner, exemplified by Behaviour-Driven-Development (BDD).
In the context of Rhino Mocks, the waters are muddied. From this page we gather that you can set expectations on stubs, but they will never be enforced, and will therefore never make a test fail. On the other hand, you can use the
Repeat.Any()method on a mocked call to basically make it behave like a stubbed method (if it was called it is ok, but if not that's ok too).
Further, in Rhino Mocks, when you create a stub of an object, all properties functions as you would normally expect them to (if you set a value X, you will get back X later on).
