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.


  • 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…


Live Templates: Logging with Android Studio

Android Studio comes with some pre-packaged Live Templates to make writing code fast. There are some logcat specific live templates that you could use in your classes to quickly write  code for logging. Below are some of the logging methods that I find invaluable.

  1.  logt (create TAG):
  2. logm (Log.d  for method call including parameter):logm
  3. loge (Log.e):loge

The same can be done for logi,logv,logr.  I don’t know about you. These have saved me a couple of keystrokes…and extra libraries just for logging.  You can even create your own Live Templates if you want.

Random Android Gradle Tip: Different Icon per BuildType

Say you want to tell if the version of your installed app is a debug or release version just by looking at the icon on your device. Quick way to do this is to leverage Gradle’s Build type concept.
Build types allow you to create different versions of the same app from the same project. All projects have by default, a debug and release build type. If you want to have a different debug icon from your release icon.

All you have to do is create your launcher icon (debug version) and instead of placing the drawables in the main source set you would install them in the debug source-set. When your project is built in debug mode it would use the matching assets in the debug folder instead of the assets in main source folder. When you build the release version it will use the assets in the release folder if it exists or use the default ones in the main source set. This also holds for build variants.

[1] http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Build-Variants