Android. Программирование для профессионалов. 4-е издание

developer.android.com/training/testing/espresso
.
Интеграционные и модульные тесты служат разным целям.
Как правило, разработчики предпочитают начинать с
модульных тестов, потому что они выполняются достаточно
быстро; их можно запускать без долгих раздумий, что упрощает
выработку привычки. Интеграционные тесты выполняются
достаточно долго, что не позволяет выполнять их с такой
частотой. При этом каждый вид тестов дает важную
информацию о состоянии вашего приложения под особым
углом, поэтому действительно хорошие разработчики
выполняют тесты обоих типов.
Для любознательных: фиктивные объекты и тестирование
Фиктивные объекты (имитации) играют в интеграционном
тестировании совершенно иную роль, чем в модульном
тестировании. Они выдают себя за другие несвязанные
компоненты и тем самым обеспечивают изоляцию
тестируемых компонентов. Модульные тесты тестируют
отдельные классы; каждый класс обладает собственными
специфическими зависимостями, поэтому каждый класс теста

---

использует свой набор фиктивных объектов. Так как
фиктивные объекты различаются между классами тестов, а
поведение особой роли не играет, для модульных тестов
замечательно подходят фреймворки, упрощающие создание
простых фиктивных объектов (такие как Mockito).
С другой стороны, интеграционные тесты предназначены
для тестирования всего приложения как единого целого. Вместо
того чтобы обеспечивать изоляцию компонентов приложения,
фиктивные объекты используются для изоляции приложения от
всех внешних объектов, с которыми может взаимодействовать
приложение, — например, для обеспечения веб-службы
фиктивными данными и откликами на запросы. В приложении
BeatBox можно было бы предоставить фиктивный объект
SoundPool
, который сообщал бы о воспроизведении
конкретного звукового файла. Так как фиктивные объекты
имеют большие размеры и совместно используются многими
тестами и поскольку они чаще применяются для реализации
фиктивного поведения, при интеграционном тестировании
лучше 
избегать 
использования 
автоматизированных
фреймворков и вместо этого писать фиктивные объекты
вручную.
В любом случае действует один принцип: моделирование
сущностей на границе тестируемого компонента. Он
определяет область действия теста и гарантирует, что тест не
будет проходить только в случае неработоспособности самого
компонента.