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


Random Android Gradle Tip: App dependencies

If you need to see the dependency tree for your project you can run:
./gradlew :app:dependencies
./gradlew :app:androidDependencies
if you need to solve a conflict you could either exclude the conflicting module or use a resolution strategy to force a particular version of the library to be used .


Short Expect Tutorial

So lets say you wanted to automate a login into a machine using ssh but not having to do the ssh key sharing thats explained in many posts including this one. You could use expect to do the same thing and more. Below is a script that you pass the domain you want to connect to, the password and the command to run and it runs this automatically. You need expect inorder to run this. save the below as file run.exp:

1. spawn ssh [lindex $argv 0]
2. set psd [lindex $argv 1]
3. set cmd [lindex $argv 2]
4. expect “Password:”
5. send “$psdr”
6. expect “.*”
7. send “$cmdr”
8. expect eof

  • spawn: used to start a program
  • expect: used to wait for a string
  • send: used to send command
  • interact: used to switch the control to the user.

You can run this as: ./run.exp <root@myhost> <mypassword> <thecommandtorun>

e.g ./run.exp root@foo.bar bob123 w

this would ssh into foo.bar as user root using password bob123 and then show a listing of everyone who is logged in and what they are doing.

Hello Gnome

So a couple of weeks ago i made the bold move to move from opensuse 11.0 to Fedora 10. My take on it.., i aint looking back at all. I’m actually impressed. I have to admit though, i kinda miss YAST, that there is a jewel. it will take a lot i guess to get a replacement. Yum seems to do the job, I’ve upgraded to yum presto, its a bit faster.

One thing though i’ve noticed is , gnome seems to be polished now. I remember using gnome on Redhat a few years back.It was not exactly the best thing, and made me choose KDE. Speakin of KDE, it seems to be getting blotted, or maybe its my suse 64bit installation. I had kde4.1, and i have to admit maybe i’m one of those guys who just want to resist change, but the idea of having to use a widget to access my desktop wasnt working.

I use java a lot in my day job, and i’ve found gnome isn’t that resource hungry compared to kde. I’m now using gnome and happy.