Espresso and Appium are both automated UI testing frameworks but they work in different ways. There are use-cases where Espresso is the more suitable choice and there are use-cases where Appium is the more suitable choice.
The primary difference between the two is that Appium is a purely black box testing framework and Espresso is not black-box or white-box, but what they call a "grey box" testing framework (this will be explained further).
Appium tests the actual Android application. It takes the application apk and runs UI tests on them without access to any of the internals of the application. An Appium test knows nothing about "Activities", "Broadcast Services", "Intents", etc... The tests have the same access privileges to an application that a user has and thus the tests simulate the usage of an app the way that a user would actually use the app.
Espresso, on the other hand, is a Java framework that is installed with your app's source code. With Espresso, you can write user interface tests (black box) but it has the same access to the internals of the application that any other unit/integration tests (white box) have, hence why it's called "grey-box" (black box + white box).
These two approaches carry different pro's and con's and shouldn't be seen as competing approaches, but rather as complimentary test approaches that cover different use cases.
- Better performance
- Supports mocking, which allows for better ability to cover a wider array of use-cases and allows you to mock out slow operations (REST api calls, database calls, etc...)
- Some tests can be run in a simulated environment (see: http://robolectric.org/) so instead of having to run tests on an Emulator or Real Android Device, tests can be run on a JVM (even better performance)
- Good integration with Android development tools
- Having access to the internals has many advantages, but the risk is that because you have the ability to alter the app, you're changing the app in a way that doesn't accurately represent how users will actually use an app
- Requires the source code to write tests. Which is fine if Android developers are writing tests. Might be a problem for QA engineers
- Requires knowledge of Android development to write tests
- Can only write tests in Android supported languages (Java, Kotlin)
- Tests the actual application (no source code) which means that tests run the application the way users run the application supporting a proper "end-to-end" test strategy
- Has access to device level configurations (WiFi, Network, Settings, etc...)
- Implements the W3C WebDriver protocol (https://www.w3.org/TR/webdriver/) which ensures better stability and compatibility and less risk of breaking changes or becoming unsupported
- Cross platform client libraries
- Uses same protocol as Selenium, so QA engineers with Selenium expertise can apply their expertise to Appium too
- Tests aren't as fast as Espresso tests
- Doesn't have access to the internals of the app, which limits the breadth of test-cases
- Can't debug the app source code
If we're to compare Espresso to Appium under the rubric of shift-left testing, Espresso is to the left of Appium and to the right of Unit Testing. Espresso is more flexible, and is tightly-coupled with the source code. Espresso tests are written and maintained throughout the development process and ensure that fewer defects flow "downstream". Appium tests are to the right of Espresso. They take the application build and tests the UI in it's true form. Manual UI testing is to the right of Appium, which involves actual people using the application.