A mock object can be useful to the software tester like a car designer uses a crash test dummy to simulate a human in a vehicle impact.
Similarly, mock-only settings could ensure that subsequent calls to the sub-system will cause it to throw an exception, hang without responding, or return null etc.
Thus, it is possible to develop and test client behaviors for realistic fault conditions in back-end sub-systems, as well as for their expected responses.
It might check the existence and perhaps the validity of the Person object passed in for saving (see fake vs. mock discussion above), but beyond that there might be no other implementation.
This can find otherwise invisible performance-sapping bugs, for example, where a developer, nervous of losing data, has coded repeated calls to save() where just one would have sufficed.
Programmers working with the test-driven development (TDD) method make use of mock objects when writing software.
Developing a realistic piece of software using TDD may easily involve several hundred unit tests.
If many of these induce communication with databases, web services and other out-of-process or networked systems, then the suite of unit tests will quickly become too slow to be run regularly.
This in turn leads to bad habits and a reluctance by the developer to maintain the basic tenets of TDD.
Conversely, simply mocking one method might require far less configuration than setting up an entire real class and therefore reduce maintenance needs.