- Standing in for other classes without actually requiring the involvement of those classes: this allows you to keep tests of a given class independent of other classes; rather than making calls to the other classes (and inadvertently testing them as well) the mock stands in for the other class. It goes without saying that while this isolation can be a good thing, it is most certainly detrimental if you don’t complement it with some form of integration test which removes the artificial isolation and ensures that the various components of a system function correctly when used as a whole.
- A sub-purpose of this isolation here is that it can be used to prevent you from hitting a third-party or external API or service during your test suite run; in other words, you can not only prevent your code from hammering the service/API inappropriately, but you can also simulate failure modes and special conditions. Examples of "external" APIs and services might include things like Amazon’s S3 service, or even your own database.
- Verifying that the code being tested makes the calls on other classes that it should be making: the mock is told to expect certain messages (and optionally return specific values) and can cause a test or spec to fail if those expected messages are not received. This wouldn’t be possible without mocks because it would require other classes to be instrumented with additional code just for the purposes of testing and verification (which wouldn’t be very clean).
Stubs are related to mocks: they can stand in for other classes, but they do not perform verification like mocks do. Stubs allow you to modify or control the interaction among components in a system; mocks go one step further and additionally allow you to make assertions about those interactions. As such, both of these tools are critical to implementation of interaction-based testing, which is the counterpart to state-based testing.
There are other types of test doubles, include proxies and spies.