QA Engineering — Espresso

As a QA team at MyAirtel, it is imperative for us to ensure that the software we deliver complies with the standards set by the company and meets requirements to the full extent before it is released to the public

In order to achieve this, it becomes crucial to create an automation framework that is reliable, fast and requires less maintenance.

Before espresso, app automation was mainly catered by appium, however, espresso offers some capabilities that caused us to make that shift

· Unlike appium espresso, provides automatic synchronization of test actions with the UI of the app, this capability gives us more reliable and dependable test results

· Espresso takes a ‘grey box’ testing approach. With espresso, the tester has a lot more control over the application than in a black box tool like appium. As Espresso is inside the application, it has access to and knows how to use the code that actually runs the application, this allowed us to integrate a performance testing framework that uses the application code to capture android performance stats.

· Espresso is very fast, we’ve never seen something so fast in UI automation.

· Espresso supports testing activities outside the app like camera, browser and dialer etc which appium does not support.

· Espresso we can test toast message, autocomplete and dialogs which are outside app.

· With Espresso Test Suite, we can find code coverage and measure our testing efforts.

What is Espresso

Espresso is a testing framework made available by Google for Android to make it easy to write concise, reliable user interface tests. Espresso is well-suited for writing white box-style automated tests, where the test code utilizes implementation code details from the app under test.

Setting Up Espresso

Go to your app/build.gradle and add dependencies

androidTestCompile ‘com.android.support.test.espresso:espresso-core:3.0.1’

androidTestCompile ‘com.android.support.test:runner:1.0.1

Add to the same build.gradle file add

android.defaultConfig{

testInstrumentationRunner “android.support.test.runner.AndroidJUnitRunner”
}

Writing Up tests with Espresso

The following code snippet shows an example of an Espresso test:

@Test
public void sendNowDisplayed() {
onView(withId(R.id.name)).perform(typeText(“Test”)); //View Matcher
onView(withId(R.id.send)).perform(click()); //View Action
onView(withText(“Send Now !”)).check(matches(isDisplayed())); //View Assertion
}

· Espresso uses onView (Matcher<View> viewMatcher ) method to find a particular view among the View hierarchy.

· After finding the View you can perform actions on the View or on its Descendant using ViewActions of the Espresso.

· After performing an action on the View we will want to see if the view behaves as we want, This can be done using check

Spoon Integration with Espresso

Spoon is great library to distribute instrumentation tests to multiple devices. It aims to simplify testing by distributing instrumentation test execution and displaying the results in a meaningful way.

In the report output generated by Spoon. We can see

· Overall test results for each device

· Error message if a test is failed

· Viewing a test case’s screenshots for all devices

· Logcat logs

· View a test case’s screenshots as animated GIF

Analyze power use with Battery Historian

As a part of testing lifecycle, it was important for us to anlayze the app performance in terms of battery usage, it is very complicating to monitor the battery at the level of hardware, because monitoring itself also drains battery while trying to measure how much battery is drained. To be able to get that kind of information accurate, we need to integrate a third part hardware to the device.

The Battery Historian tool provides insight into a device’s battery consumption over time. At a system-wide level, the tool visualizes power-related events from the system logs in an HTML representation. At an app-specific level, the tool provides a variety of data that can help you identify battery-draining app behaviour.

Performance Testing Framework

We integrated a framework with the existing one for extracting memory, CPU and network usage data. With the help of this we can easily capture android performance stats like CPU (user space, system space), Memory (Native, Dalvik, Private shared etc.), Network(RX/TX for mobile and Wi-Fi data usage) info after every UI test/suite run and dump data into mongo DB for version and compare this data with previous version. It gives us an insight for performance degradation and to identify the culprit classes and thread by heap dump and method trace.

The sample document stored in mongo collection: -

{

“deviceId” : “Custom Phone — 5.0.0 — API 21–768x1280”,

“apkVersion” : “4269”,

“nativeHeapUsed” : 44132,

“nativeHeapfree” : 15259,

“dalvikPSS” : 17240,

“dalvikShared” : 1216,

“dalvikPrivate” : 17192,

“usedTotalMemoryInMB” : 27,

“maxTotalHeapSizeInMB” : 96,

“availableTotalHeapSizeInMB” : 69,

“created” : ISODate(“2018–01–31T08:12:37.861Z”)

}

{

“deviceId” : “ Custom Phone — 5.0.0 — API 21–768x1280”,

“apkVersion” : “4269”,

“userSpaceCpuUsage” : 3,

“systemCpuUsage” : 11,

“ioWaitCpuUsage” : 0,

“irqCpuUsage” : 0,

“mainCpuUsage” : 0,

“readThreadCPUTime” : 2571,

“created” : ISODate(“2018–01–31T07:54:09.740Z”)

}

{

“deviceId” : “Custom Phone — 5.0.0 — API 21–768x1280”

“apkVersion” : “4269”,

“mobileTxData” : 0,

“mobileRxData” : 0,

“mobileTotalData” : 0,

“wifiTxData” : -1,

“wifiRxData” : -1,

“wifiTotalData” : -2,

“network_Carrier_Name” : “\”WiredSSID\””,

“networkType” : “WiFi”,

“created” : ISODate(“2018–01–31T08:12:39.051Z”)

}