About Espresso

Use Espresso to write concise, beautiful, and reliable Android UI tests like this:

public void testSayHello() {
  onView(withId(R.id.name_field))
    .perform(typeText("Steve"));
  onView(withId(R.id.greet_button))
    .perform(click());
  onView(withText("Hello Steve!"))
    .check(matches(isDisplayed()));
}

The core API is small, predictable, and easy to learn and yet remains open for customization. Espresso tests state expectations, interactions, and assertions clearly without the distraction of boilerplate content, custom infrastructure, or messy implementation details getting in the way.

Espresso tests run optimally fast! Leave your waits, syncs, sleeps, and polls behind and let Espresso gracefully manipulate and assert on the application UI when it is at rest. Enjoy writing and executing your tests today - try a shot of Espresso!

Getting Started

Espresso was open sourced on Oct 17, 2013 and all of its documentation now lives on https://code.google.com/p/android-test-kit/wiki/Espresso

Here are a few useful links to the content on the external site:
Getting Started
Samples
Javadoc

Target Audience
Espresso is targeted at developers, who believe that automated testing is an integral part of the development life-cycle. While it can be used for black-box testing, Espresso's full power is unlocked by those who are familiar with the codebase under test.

Backward Compatibility
Espresso is supported on the following APIs:

Codename API
Froyo 8
Gingerbread 10
Ice Cream Sandwich 15
Jelly Bean 16,17,18
KitKat 19

Setup your test environment
To avoid flakiness, we highly recommend that you turn off system animations on the virtual or physical device(s) used for testing.
Under 'Settings->Developer options' disable the following 3 settings and restart the device:

Frequently asked questions

1. Why not use Goobotium or Robotium?

Robotium has problems. Here are a few.

It has a bad API:

--It's confusing: Which of the 30 or so click methods should you use? What is the difference between searchText and waitForText?
--Dangerous methods: For example, getView lets you hold on to stale user interface elements
--Poor documentation: What does "current" mean in getCurrentActivity?

Bugs present in fundamental actions. To identify just two:

--Click doesn't work reliably and fails silently
--getCurrentActivity is not reliable

Reliable tests are hard to develop because test actions are not synchronized with events on user interface. For example:
--Proper synchronization is difficult, adds a lot of ugly code, and may not always work

While Goobotium patches a few of the bugs in fundamental actions such as click and getCurrentActivity, it does not address the bad API. The Espresso API is not only reliable but is much cleaner and pleasant to consume.

2. Why not use a user interface automator (aka Geppetto)?

UIAutomator:

--Does not support Android API versions older than 16, which omits the Jelly_Bean releases.
--Does not provide the sophisticated synchronization mechanisms that make it easy to write reliable tests
--Tests are not coupled to the development of the code: The steps to create tests are aimed at black-box testing. Even the creators of the framework recommend doing this kind of testing after the user interface of an app has been stabilized.
--While some may consider it an advantage to control the user interface outside an app, we believe it's dangerous to test code that you don't own (for example, the tests could be brittle).

3. Is there a way to return a specific view?

No. There's no top-level API for this because it is dangerous (the view state changes and you may end up holding on to a stale object). You may access views by writing your own ViewAction or ViewAssertion (here, Espresso guarantees that you get a non-stale view and the UI thread is paused while you take actions or query the state).

4. Can I wait for a view to load or timeout that doesn't load when expected?

There is no need for waits with Espresso. Instead, the framework synchronizes test operations with user interface updates. You start by writing a test without sleeps. If you see places where things are still out of sync, you may need to provide additional guidance to Espresso about your application using the IdlingResource interface: sample.