Appium vs Espresso vs XCUITest – Understanding how Appium Compares to Espresso & XCUITest

In this article we shall look at the Appium, Espresso and XCUITest test automation frameworks. We’ll learn the key differences between them, as well as when and why you should use them in your own testing environment.

What is Appium

Appium is an open source test automation framework which is completely maintained by the community. Appium can automate Native, Hybrid, mWeb, Mac Apps and Windows Apps. Appium follows the Selenium W3C protocol which enables the use of the same test code for both Android and iOS applications.

Under the hood Appium uses Espresso or UIAutomator2 as the mode of communication to Android Apps and XCUI for iOS. In a nutshell, Appium provides a stable webdriver interface on top of automation backends provided by Google and Apple.

Installing Appium was a bit of hassle for a long time, hence from Appium 2.0 architecturally we could choose to install the drivers and plugins as we wanted. You can find more details about Appium 2.0 here.

Highlights of Appium

• When Espresso or XCUI upgrades the API contract, Appium under the hood will make necessary changes and the test will remain unchanged and work as before.
• supports Cross platform testing, i.e., write one test that runs across many platforms.
• allows users to write tests in WebDriver compatible languages – Java, Python, C#, Ruby, JS, etc.
• Does not require application to be recompiled as it uses standard automation APIs across all platforms.
• A Black box testing tool which also supports Gray box testing to some extent with Espresso’s driver backdoor capability.
• Can switch between Espresso driver and UIAutomator2 driver for Android in a single session. (For example: Creating a session with Espresso Driver and then we can move to UIAutomator2 to perform actions outside of application under test.)

	DesiredCapabilities capabilities = new DesiredCapabilities();
	capabilities.setCapability(MobileCapabilityType.DEVICE_NAME, "Android Emulator");
	capabilities.setCapability(IOSMobileCapabilityType.LAUNCH_TIMEOUT, 900000);
	// Session is created using Android Espresso Driver
	capabilities.setCapability(MobileCapabilityType.AUTOMATION_NAME, AutomationName.ESPRESSO);
	capabilities.setCapability(MobileCapabilityType.APP, System.getProperty("user.dir") + "/apps/ApiDemos.apk");
	driver = new AndroidDriver<>(new URL("http://127.0.0.1:4723/wd/hub"), capabilities);
	driver.findElementByAccessibilityId("Views").click();
	// Switch to Android UIAutomator2 from Espresso
	Map<String, Object> args = new HashMap<>();
	args.put("strategy", "textContains");
	args.put("locator", "android.widget.TextView");
	args.put("action", "getText");
	String text = (String)driver.executeScript("mobile: uiautomator", args);

view raw AppiumEspressoToUIAutomator2.java hosted with ❤ by GitHub

• The latest Webdriver W3C Actions API is designed in such a way that any complex gestures can be designed and executed on any platform, e.g., Android, iOS. Below is an example of a swipe gesture that runs on Android and iOS platforms.

	Point source = slider.getLocation();
	PointerInput finger = new PointerInput(PointerInput.Kind.TOUCH, "finger");
	Sequence sequence = new Sequence(finger, 1);
	sequence.addAction(finger.createPointerMove(ofMillis(0),
	PointerInput.Origin.viewport(), source.x, source.y));
	sequence.addAction(finger.createPointerDown(PointerInput.MouseButton.MIDDLE.asArg()));
	sequence.addAction(new Pause(finger, ofMillis(600)));
	sequence.addAction(finger.createPointerMove(ofMillis(600),
	PointerInput.Origin.viewport(), source.x + 400, source.y));
	sequence.addAction(finger.createPointerUp(PointerInput.MouseButton.MIDDLE.asArg()));
	driver.perform(singletonList(sequence));

view raw SwipeGesture.java hosted with ❤ by GitHub

• The single Appium server is able to handle multiple sessions in parallel. 
• Applitools Ultrafast Grid or Appium image plugin can be used to perform visual testing.

	// Start visual UI testing
	eyes.open(driver, "iOS test application", "test");
	// Visual validation point #1
	eyes.checkWindow("Initial view");
	driver.findElementByAccessibilityId("Views").click()
	// Visual validation point #2
	eyes.checkWindow("After compute");

view raw VisualTesting.java hosted with ❤ by GitHub

• Appium has a locator strategy specific to Espresso, e.g., Data Matcher strategy, and another for XCUI, e.g., NSPredicates and ClassChain

	// Android DataMatchers
	driver.findElementByAndroidDataMatcher(orderJSON.toString().click()
	// iOS NSPredicates
	driver.findElement(MobileBy.iOSNsPredicateString("name IN {'chained VieW','Demos wheel picker color'} AND visible == 1")).click();
	// iOS Class Chain
	driver.findElement(MobileBy.iOSClassChain("'XCUIElementTypeWindow'/**/XCUIElementTypeStaticText[2]"));

view raw AppiumLocatorStrategy.java hosted with ❤ by GitHub

What is Espresso

Espresso is an Android test framework developed by Google for UI testing. Espresso automatically synchronizes test actions with the user interface of the mobile app and ensures that activity is started well before the actual test run.

Highlights of Espresso

• Feedback cycle is fast as it doesn’t require server communication. 
• Allows users to create custom view matchers and is based on Hamcrest matchers.
• Espresso Framework can be categorized between black box and white box testing, commonly called as gray box testing framework.
• Accessibility testing is possible in Native Espresso.
• Requires the entire code base to run the test.
• Locator strategy is Id from R file.
• Applitools Ultrafast Grid can be used to perform visual testing.
• For testing webviews, Espresso internally uses WebDriver APIs to control the behaviour of a webview.

	@Test
	public void mainActivityTest2() {
	onView(withId(R.id.digit_1)).perform(click());
	onView(withId(R.id.op_add)).perform(click());
	onView(withId(R.id.digit_2)).perform(click());
	onView(withId(R.id.eq)).perform(click());
	onView(allOf(Matchers.instanceOf(android.widget.EditText.class),
	withText("3"))).check(matches(isDisplayed()));
	}

view raw EspressoTestingWebviews.java hosted with ❤ by GitHub

What is XCUITest

The XCUITest framework from Apple helps users write UI tests straight inside the Xcode with the separate UI testing target in the app.

XCUITest uses accessibility identifiers to interact with the main iOS app. XCUITests can be written in Swift or Objective-C. 

There isn’t a reliable framework out there which easily supports testing on Apple TV devices. XCUITest is the only way to verify tvOS apps. SinceXcode 7, Apple has shipped XCTest prebuilt into its development kit. 

Highlights of XCUITest

• Runs in a separate process from our main iOS app and it doesn’t access an application’s internal methods.
• XCUIElement class in XCUITest provides gestures such as tap, press, swipe, pinch and rotate.

	// Interacting with pickers
	let first = NSPredicate(format: "label BEGINSWITH 'Picker'")
	let picker = app.pickerWheels.element(matching: first)
	picker.adjust(toPickerWheelValue: "value")

view raw XCUITestPickers.swift hosted with ❤ by GitHub

• Offers several inbuilt assertions e.g., XCTKVOExpectation, XCTNSNotificationExpectation, XCTDarwinNotificationExpectation, XCTNSPredicateExpectation, etc.

	// XCTNSPredicateExpectation
	let expectation = XCTNSPredicateExpectation(predicate: NSPredicate(format: "name IN {'chained VieW','Demos wheel picker color'} AND visible == 1 "), object: xCUIElement)

view raw XCTNSPredicateExpectation.swift hosted with ❤ by GitHub

Conclusion

Appium, Espresso and XCUI can each fill different needs for UI testing. The way to choose between them is to consider the requirements of your project. If your scope is limited just to one platform and you want comprehensive and embedded UI testing, XCUI or Espresso are great fits. For cross-platform testing across iOS, Android, and Hybrid then Appium is your best choice.