be in. Mocks, fakes, and stubs Classification between mocks, fakes, and stubs is highly inconsistent across the literature. Consistent among the literature, though, is that they all represent a production object in a testing environment by exposing the same interface. Which out of mock, fake, or stub is the simplest is inconsistent, but the simplest always returns pre-arranged responses (as in a method stub). On the other side of the spectrum, the most complex object will fully simulate a production object with complete logic, exceptions, etc. Whether or not any of the mock, fake, or stub trio fits such a definition is, again, inconsistent across the literature. For example, a mock, fake, or stub method implementation between the two ends of the complexity spectrum might contain assertions to examine the context of each call. For example, a mock object might assert the order in which its methods are called, or assert consistency of data across method calls. In the book The Art of Unit Testing mocks are described as a fake object that helps decide whether a test failed or passed by verifying whether an interaction with an object occurred. Everything else is defined as a stub. In that book, fakes are anything that is not real, which, based on their usage, can be either stubs or mocks. Setting expectations Consider an example where an authorization subsystem has been mocked. The mock object implements an isUserAllowed(task : Task) : boolean method to match that in the real authorization class. Many advantages follow if it also exposes an isAllowed : boolean property, which is not present in the real class. This allows test code to easily set the expectation that a user will, or will not, be granted permission in the next call and therefore to readily test the behavior of the rest of the system in either case. 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. Without such a simple and flexible mock system, testing each of these situations may be too laborious for them to be given proper consideration. Writing log strings A mock database object's save(person : Person) method may not contain much (if any) implementation code.