I think you have this a bit wrong. A stup is just a convinience thing - yuo use it to get your tests running without externals dependancies. You need to tell it what calls it will recieve, and how to respond to them, and this might give you some feedback about whether the method under test is behaving as expected. But that's a useful side effect - it's not the point of the thing.
A mock, OTOH, is a stub with expectations. You tell it what it should expect, and if that's not what it gets, your test will fail. So, for example, if I'm mocking a database connection, and I expect my method under test to write a database record, my test will fail if it doesn't happen. A stub wouldn't tell me one way or the other.
Let's talk about it on Wednesday?
Hello Simon,
Your explanation maps fairly closely to my understanding - perhaps what I understand less clearly are exactly *what* the existing mock libraries provide.
We use stubs in conjunction with 'listeners' on the methods we expect to be called, and we then assert that these have been fired, in the right order and with the right arguments.
So the stubs themselves don't tell us directly that the tests fail, but we check their state afterwards.
And it would be good to talk about it on Wednesday. 
I've read a bit more of Martin's article (although I don't like the 'replay' approach he suggested) - and you will have a deeper understanding of the issues than me.
Michael
Commenting by HaloScan
