Mocking has a much different role in integration testing than it does in unit testing. Mock objects exist to isolate the component under test by pretending to be other, unrelated components. Unit testing tests an individual class; each class will have its own distinct dependencies, so each test class has a different set of mock objects. Since the mock objects are different in each test class, and the behavior rarely matters, mock frameworks that make it easy to create simple mock objects (like Mockito) are a great fit for unit tests.

Integration tests, on the other hand, are meant to test a larger piece of the app as a whole. Instead of isolating pieces of the app from each other, you use mocks to isolate the app from anything external it might interact with – for example, by providing a web service with fake data and responses. In BeatBox, you would provide a fake SoundPool that could tell you when a particular sound file was played. Because the mocks are larger and shared among many tests, and because it is more common to implement mock behavior, it is better to avoid automatic mocking frameworks for integration tests and instead manually write mock objects.

In either case, the same rule applies: Mock out the entities at the boundary of the component under test. This focuses the scope of your test and keeps it from breaking except when the component itself is broken.