Appium vs. Espresso

Posted May 4th, 2017

Mug with Sauce bot

Are you building a mobile application on Android, and want to automate your UI testing, but are wondering where to start? If so, you’re not alone. There are many ways to perform UI testing for Android.

In this article, I’ll provide some direction by discussing the pros and cons of two of the more popular tools for Android testing: Appium and Espresso.

Descriptions of Espresso and Appium

Let’s start with basic descriptions of what each tool does.

What is Espresso? From the Google Android developer site:
“The Espresso testing framework provides a set of APIs to build UI tests to test user flows within an app. These APIs let you write automated UI tests that are concise and that run reliably. Espresso is well-suited for writing white box-style automated tests, where the test code utilizes implementation code details from the app under test.”

What is Appium? From the Appium introduction page:
“Appium is an open-source tool for automating native, mobile web, and hybrid applications on iOS and Android platforms. Native apps are those written using the iOS, Android, or Windows SDKs. Mobile web apps are web apps accessed using a mobile browser [...]. Hybrid apps have a wrapper around a “webview”—a native control that enables interaction with web content.”

Key Differentiators Between Appium & Espresso

Espresso is inside the application, and is written by Google for the sole purpose of functional testing of an Android UI. In terms of testing style, the Espresso description mentions “white box testing.” As Espresso is inside the application, it has access to and knows how to use the code that actually runs the application for more thorough testing of each element.

Appium is designed to be a cross-platform test platform. As such, one of the trade-offs focuses on “black box testing” which only tests what has been exposed externally to the application. Using the Android UIAutomator framework, Appium can access all the UI elements that a user will see. Two of the benefits of being external to the application are the ability to validate the data going to and from the service layer behind the scenes, and the ability to execute simulations by telling the app the device has rotated, or that the home button has been pushed.

Simple Test Case in Espresso

It’s easy to get up and running with Espresso if you already have an Android application started. But as with all testing frameworks, it can be complicated as you try to do more.

  • Inside the mobile application, update your file to have the proper dependencies, and load the test runner.

Sample file with the new parts in bold:

apply plugin: ''

android {
  compileSdkVersion 22
  buildToolsVersion "22"

  defaultConfig {
    applicationId ""
    minSdkVersion 10
    targetSdkVersion 22.0.1
    versionCode 1
    versionName "1.0"

    testInstrumentationRunner ""

dependencies {
  // App's dependencies, including test
  compile ''

  // Testing-only dependencies
  androidTestCompile ''
  androidTestCompile ''
  • Next, create the test class, which will see if the words “Hello World” are displayed on the screen.
public class HelloWorldEspressoTest {

    public ActivityTestRule<MainActivity> mActivityRule = new ActivityTestRule(MainActivity.class);

    public void listGoesOverTheFold() {
        onView(withText("Hello world!")).check(matches(isDisplayed()));

Execute the tests.

$ ./gradlew connectedAndroidTest

That’s it! You now have Espresso running a test.

Simple Test Case in Appium

As Appium isn’t purpose-built to integrate with Android natively, there is a little more involved in the setup process. There are great resources with in-depth tutorials that cover getting up and running with Appium and Android. Sauce Labs’ Getting Started guide is a great way to get all the details.

Below, I’ll cover the basic steps to set up the test.

Start with cloning the Appium repository on GitHub, then follow the installation instructions.

Once everything is installed and running, it’s time to get a copy of the latest build (.apk) of the application you want to test, and write the setup file for the scenario. This file gets the APK file ready for Appium to test against.

protected AndroidDriver driver;

protected void prepareAndroidForAppium() throws MalformedURLException {
  File appDir = new File("/Users/test/apps");
  File app = new File(appDir, "sampleApp.apk");
  DesiredCapabilities capabilities = new DesiredCapabilities();

  //mandatory capabilities

  //other caps
  capabilities.setCapability("app", app.getAbsolutePath());
  driver =  new AndroidDriver(new URL(""), capabilities);

Next, write the test case, one per page in the app. In this example, it will find the text “Hello World” on the screen.

public void helloTest() {
  String app_package_name = "";
  driver.find_elements_by_xpath('//div[contains(text(), "Hello World")]')

Now, just run the test.


While both Appium and Espresso can fill the need for UI testing for your Android application, it really comes down to the scope of your testing. Ideally, you could leverage both frameworks to maximize the amount of testing done to the application, but as with most things, that is more time than most people have to invest upfront.

If you’re selecting just one framework, then for developers building a native Android application that have their scope limited to just the app and want comprehensive and embedded UI testing, Espresso will definitely fill that need.

If the tests need to support multiple platforms (e.g., iOS, hybrid, and Android), and you need to validate how the app reacts to outside factors like screen rotation, and/or you want to run the testing in parallel using a service like Sauce Labs, then Appium will better meet your needs.

Come Visit Sauce Labs at the JSConf.EU, happening May 6-7 - Learn More.

Vince Power is a Solution Architect who has a focus on cloud adoption and technology implementations using open source-based technologies. He has extensive experience with core computing and networking (IaaS), identity and access management (IAM), application platforms (PaaS), and continuous delivery.

Written by

Vince Power