top of page
Search
Jul 20, 2021

How to Run Android Mobile Test Automation using Espresso

Updated: Aug 16, 2021

Simran Raina @sraina / 5.30 PM EDT . July 20, 2021


Espresso is one of the Android mobile automation testing frameworks that enable reliable user interface tests directly within the Android Studio Integrated Development Environment (IDE).


For years the mobile testing fraternity interested in mobile app test automation has been using Appium as a holy grail. However, as the gap between a developer and QA engineer is shrinking, QAs are able to discover a new test framework named Espresso to test native Android apps. The developers are still happy with their unit tests, as they don’t want to run their tests on emulators (and unit tests do not, right?) every time (that takes a lot of time). They have QAs to do that. And QAs also nowadays feeling the heat due to time crunch in the Agile environment. The heat is from using the Appium test frameworks as it takes a hell of a lot of time. There are some others problem areas that are surfacing which give rise to the next topic.



Why Appium is getting discouraged?

  • Appium tests are flaky: The reliability of Appium tests is at stake. Test failing which was working a few minutes back is every mobile app QAs woes in life.

  • Appium test setup is cumbersome: Setting up that Nodejs server and then writing the desired capabilities can take a good amount of effort.

  • Mobile DevOps process requires Fast and Reliable Feedback: The world is changing fast and so do the features of a product. There are quick-paced releases, which means DevOps pipelines are running hot with the builds. Testing feedback cycles also have to be quick to put fixes quickly to the production. Mobile app QAs need a tool that empowers them with these capabilities. Appium tests can let us down here.

  • More testing activities have moved into the Development process: Iterating the previous point, the DevOps and Developers want the app to be tested before the apk is even published. Earlier an apk file was ready for the QA to test and get the bugs. But those times have long gone. And at this age, we need to test the app with the code directly and then generate a QA approved apk to move to the market.

We need a solution between unit tests and orchestrated tests. 
And the solution is: Instrumented Tests. Ta da!

What is Espresso? – An implementation of Instrumented Tests

  • Small and lightweight API that is easy to set up and live happily beside the developer’s code. It also becomes part of the whole product package.

  • The code looks like English that makes sense. It doesn’t mean it can be implemented by a non-technical person. It requires knowledge of Java or Kotlin languages but at a minimum.

  • Java and Kotlin are the two languages of Android App development and is the same for Espresso.

  • Gradle and Android Studio are required and their knowledge. No Maven, but Gradle which is another build tool to do the same stuff as Maven in Appium test frameworks.

  • Automatic Synchronisation is provided by Espresso for elements and test actions. It automatically detects when the main thread is idle and accordingly runs test commands at the appropriate time. As a result, Espresso is faster and more stable. Unlike Appium, it does not involve any server communication. This is the most powerful feature of using Espresso.

  • Part of Jetpack SDK from Google as it is an Android Native framework provided and maintained by Google. Dedicated support from the detailed documentation available from the Google community.


Let’s start writing the Espresso test:


Step1: You need the code from your developers on your Android Studio IDE. You can get it from GitHub/Bitbucket/GitLab. Also, you can try to get some free sample codes on Google.


Step2: Locate the /src folder in the project and expand it:


So, /main is for developers’ code, /test is for unit tests and /androidtest is for the instrumented tests.



Step3: In the package, create a Kotlin/Java class file to write the Espresso test.






Step4: Backing up a little, we also need to add Espresso dependencies in the project build.gradle file

We also need a test execution engine like AndroidJunitRunner and that we can get from androix.test libraries

Step5: Alright, back to the class file, we need to understand three lines for writing a simple test case which can:

Locate the desired view element on the mobile app screen

Take the desired action on that element

And, finally, assert the test.


These three steps can literally be converted into the below line of codes:


onView(withId(R.my_id)) //my_id is the identifier to locate the desired element in the view
.perform(click()) //click action is performed on the desired element located in the first step
.check(matches(not(isEnabled())); // assert that the element is not         enabled

These methods can also be referred to as:

  • viewMatchers

  • viewActions

  • viewAssertions, respectively.


We have a lot of such methods to help us out for different mobile app test scenarios.

Help yourself to check out the below link.



There is still wrapper code missing here, but that can be added simply. And then we can execute the test on the emulator or connected real device.


Happy learning and testing!



Comments

bottom of page