Mocks typically follow a four step sequence : setup (data and expectations), exercise, verify, teardown
.gif)
1. Understanding One : Mocks are dynamic stubs ?
MSDN Article
.gif)
2. Understanding Two : Mocks are not stubs
Martin Fowler's Article
There are two differences
a. How test results are verified : Stubs do state verification, Mocks do behavior verification.
Mocks use behavior verification, where we instead check to see if the SUT (System Under Test) made the correct calls on the mock object. We do this check by telling the mock what to expect during setup and asking the mock to verify itself during verification.
b. The way testing and design play together : Classic vs Mockist
The classical TDD style is to use real objects if possible and a double if it's awkward to use the real thing. So a classical TDDer would use a real "collaborator or secondary object" and a double for the a service. The kind of double doesn't really matter that much.
A mockist TDD practitioner, however, will always use a mock for any object with interesting behavior.
An important offshoot of the mockist style is that of Behavior Driven Development (BDD).
No comments:
Post a Comment