The final test double abstraction that we will cover in this book is the test mock. Mocks replace function behaviors like stubs, observe method calls like spies and stubs, and additionally verify function behaviors. Essentially, mocks are a "one-stop shop" for faking and testing methods.
So, when should we use mocks? The Sinon.JS mock API documentation (http://sinonjs.org/docs/#mocks) starts with the appropriate use cases for mocks:
"Mocks should only be used for the method under test. In every unit test, there should be one unit under test. If you want to control how your unit is being used and like stating expectations upfront (as opposed to asserting after the fact), use a mock."
The documentation cautions that mocks should be avoided in many situations:
"Mocks come with built-in expectations that may fail your test. Thus, they enforce implementation details. The rule of thumb is: if you wouldn't add an assertion for some...