Among the more frustrating aspects of unit testing are those tests that rely on many external dependencies, such as database connections, collaborator objects, or even the file system. Because a lot of context is assumed by such code, writing tests that isolate the behavior of individual methods is time-consuming and fragile.

Mock objects can be used to stub out such dependencies. Yet, relying on mock objects is not without danger, as Alex Ruiz points out in his article, BEA's Dev2Dev, Mock Objects: Shortcomings and Use Cases:

Testing code in isolation is difficult, especially when dealing with dependencies that are not easy or quick to set up in our tests. The more difficult it is to write and maintain unit tests, the greater the chances that developers will feel discouraged and stop writing tests...

Mock objects, or mocks, simulate difficult-to-use and expensive-to-use collaborators and provide a way to... set up complex dependencies in the testing environment..., verify that expected actions were executed by the code under test [and], simulate environment conditions that are difficult to generate...

A key point of Ruiz's article is that dependencies in a code base are often the source the bugs we would like to discover with unit testing. Stubbing out such dependencies can defeat the very purpose of testing:

Mocks can effectively speed up creation and execution of unit tests, but they cannot give us the confidence that the system, as a whole, works correctly. Mock testing may hide bugs or defects in the collaborators that are being mocked.

In addition, Ruiz notes that mock objects impose some design requirements on a system, and also require intimate knowledge of the system's implementation details:

Mock testing is glass box testing, which requires intimate knowledge of class internals. This is a side effect of the interaction-based nature of mocks. Justifiable changes in the implementation of a method may break tests using mocks, even if the result of executing such a method is still the same...

Expectations on class-based mocks may depend on protected or package-protected methods, which represent implementation details of a class. Such implementation details can (and will) change at any time, changing the interaction between the code under test and mocks, increasing the chances of breaking existing tests...

To what extent do you rely on mock objects in your unit tests? Do you agree with Ruiz's point that mock objects impose a lot of design constraints on a code base?