On Rhino.Mocks VerifyAllExpectations Vs AssertWasCalled

After reading my Rhino.Mocks Quick Reference post, a colleague and I had a discussion about the proper way to validate expectations in Rhino.Mocks. Specifically, he questioned if my use of .VerifyAllExceptions() was correct for the ArrangeActAssert syntax, or, as he proposed, is it the "old" syntax, being replaced by the .AssertWasCalled() methods.

Since this is a person I respect, I decided not to smite him and instead took a mental note to do some quick google searches research. Having failed to actually find Ayende's opinion on the matter in the first 5 minutes, I did come across this post, which raised a point I did not realize had forgotten:

In Rhino Mocks, expectations on stubs are not verified; only mocks are verified. If an object is created with GenerateStub instead of GenerateMock, then its VerifyAllExpectations method doesn't do anything. This is non-obvious because the AssertWasCalled and AssertWasNotCalled methods on a stub will behave the way you want them to. In Rhino Mocks, a stub can keep track of its interactions and assert that they happened, but it cannot record expectations and verify they were met. A mock can do both these things. 

So, if you are using a Stub, you must not use .VerifyAllExpectations(), because it will always pass.

Now, one might argue (and many, many on the Internet do argue) that a Stub should not have any expectations, so you shouldn't be calling either method. Stubs are for providing inputs to allow the code under test to run and limit your test to just the code under test, while Mocks are uses to validate behaviour. (they are one of the tests). 

If someone does have a link to Ayende's opinion, please post as a comment or email/tweet me. I'll update this post if I find it.

Update: found this (http://ayende.com/wiki/Rhino+Mocks+3.5.ashx#ExpectExtensionMethod) where it seems Ayende expects people to use either case (ie: he doesn't state here that one is "proper").  I still seem to remember a blog he wrote stating a preference for one over the other, but I haven't yet found it).