in Android, Android Studio, Testing, Uncategorized

Writing Android Tests with Espresso Test Recorder

Testing tools for Android have been improving significantly in the last 2 or so years. Instrumentation and Unit testing is now way easier with the advent of the Android Testing Library. There are tons of sources on how to integrate and use these tools in your own apps including these samples from Google for examples on how to write your own tests.

Android Studio 2.2 Preview 3 was recently released. This preview in my opinion, comes with the most coveted Android Studio feature revealed at Google I/O this year, Espresso Test Recorder. The recorder allows you to click through your app UI as normal as it records events and it generates reusable and editable test code for you. You can also add assertions (though limited). The generated tests can be run locally, on your Continuous Integration server, or on Firebase Test lab.

Although the recorder is still in beta, I decided to see how easy it would be to mimic the same UI tests from the Android Testing Codelab as described here. If you have not gone through that Codelab I urge you to read it before continuing , you will thank me later.

Manually writing the Codelab UI tests took roughly 20 minutes when I attempted them the first time. I wanted to see how much time the Espresso Test Recorder would save me on writing the same 3 UI tests described in that Codelab, so here goes:

First you will need to clone the sample code with:

git clone https://github.com/googlecodelabs/android-testing.git -b step-7
Espresso Test 1: Opening the ‘Add Note’ screen

This test opens the app, clicks the “add note” button and verifies that the correct screen is being displayed.

Espresso Test 2: Adding a note

This test will open the ‘Add Note’ screen, enter some text, click the save button and verify that the saved note has been displayed.

Espresso test 3: Clicking a note

This test verifies that clicking a note will display the correct note on screen. You will need to uncomment all the commented out code in the NoteDetailFragment class for this test to work as shown in the video.

 

Limitations
  • One class per test – currently you can only record a single test method per class. This isn’t a real issue though it would be nice if you could have multiple tests in one test class.
  • Available assertions are limited from the UI – the preview build has a limited option of assertions you can  do with the UI, so you will still need to write some code if you’re working with say intended() & intending() matchers.
  • UI assertions seem limited to your own UI code – e.g. if you have payments within your app, you can’t click the buy or cancel buttons on the Google PlayServices payments dialog box.
  • Input detection for Webviews – it does not seem like you can handle input for webview text boxes or add assertions to them.
  • Advanced features like handling background tasks which you can do with Idling Resources is still something you will need to code manually

 

Even though it has limitations it works well for the most common UI tests. I can only imagine it will get better with time. This without a doubt will make it a lot easier to write UI tests for your applications. It’s not a silver bullet but it definitely cuts down on the amount of boiler plate code you need to write. Writing UI tests definitely sucks less with the recorder. It took me less than 5 minutes to write the same tests with a bit of editing of the generated code. 

It’s definitely a good time to be an Android developer and to be using Android Studio.

To the Android Studio team…

giphy

  • Great article. Love the Gif 😛

  • artem_zin

    >UI assertions seem limited to your own UI code – e.g. if you have payments within your app, you can’t click the buy or cancel buttons on the Google PlayServices payments dialog box.

    That’s because Espresso runs under Instrumentaiton API which is limited to interact with one process (your app’s process usually), Google Play Payment dialog runs in Google Play process so you can’t interact with it via Espresso. BUT, there is a UIAutomator which can interact with whole system and you can now use it right from you Instrumentation tests.

  • Pingback: Cıvata()

  • Pingback: Reading Recommendations # 67 | Adventures in QA()