Fuzzyman has a new mocking library for Python, which he presents in Mocking, Patching, Stubbing: all that Stuff.
Michael takes issue with Martin Fowler's Mocks Aren't Stubs; specifically where he defines mocks as objects pre-programmed with expectations which form a specification of the calls they are expected to receive. Michael's mocks are not pre-programmed with expectations - his expectations are defined after the test execution.
Now, to me, this is a trivial distinction - the important difference between a stub and a mock is in the existence of expectations. Whether the expectations are defined before or after the text execution is not crucial - it's still a mock.
It does matter in terms or usability, of course. It feels more natural to Michael to define his expectations after the test object is exercised, along with his assertions. For me, I have to say that defining the mock object's behaviors all in one place makes sense, so both the expected method calls and any return values should defined together - and the return values have to be pre-defined. We are using EasyMock here at GU (along with the Hamcrest constraints library) and I like it just fine. But that's more a matter of taste than anything else.
Posted to Agile by Simon Brunning at November 20, 2007 03:26 PMI think there is a difference and your entry here has crystallised it for me (I will probably update my article).
For any one unit (function / method / class), we will probaby have several tests - each testing a specific aspect of behavior.
For example, normal behaviour, corner cases, error conditions (etc). Each one will be a separate test.
So for each test we setup the initial conditions, perform the actions and then make an assertion about the behaviour.
The pattern described by Martin merges the initial setup with 'defining the expectations' - which I think makes it less clear what you are actually testing.
It is nice to be able to say - for these conditions we expect this action to behave in this way.
The 'setup - > action -> assertions' pattern makes this all explicit, whereas 'expectations -> verification' makes it less clear (in my opinion and FWIW etc etc...).