Posted on

Why Android Espresso UI Tests Rock

android espresso

Designed by Freepik

You’re probably familiar with Android Espresso, if not – it’s a framework for UI testing. You must’ve used jUnit before, but with it you can’t test much on Android. That’s why we have Espresso for testing actual app itself, test like a real person is using it and find bugs of course.


Now I’m not a TDD (Test Driven Development) guy or any kind of test guy. I write jUnit test quite rarely, just for stuff like text parsing algorithms mostly. I think it’s because of the app nature, the major part is just fetching stuff from internet, displaying it, making some interactions and sending them back to the internet

There isn’t simply so many complex algorithms/methods to test. Like you start this way

OK, this super-duper smart algorithm will calculate the distance to Mars at particular Earth day with precision up to 1 meter

You just fetch stuff from internet! But there’s this kind of testing that you do for every new feature you add – open app, click on different buttons, rotate screen, click on buttons fast. Drop the phone from 5th floor. No, not this one

And you see if app crashes, UI is correct


He comes Espresso, you can do all that by writing code: scroll to position, open list item, click on button. And verify then of course. Before you had to learn all those methods: how to to click on ListView item, how to click on RecyclerView item, how to scroll etc.

But I think it was a year or more already as we have UI test recording. So basically now you don’t need to write any code! You just press this button

android espresso

Then when process has started you use your app as you’d want your test to. And you’ll see corresponding test catching up with you

android espresso

You can see delay of 3.5 thousand seconds which is bug, it will convert to corresponding Thread.sleep method, you’ll need manually change time or your test will take a day

So when you’re done, you’ll get a generated Java class with all the interactions you made.


There will be no UI verification generated, but if you need it – adding it is ok, but in some cases you’ll have to learn the whole framework

But the most important is testing for crashes which doesn’t need any extra tests. For example we all know, that if you use vector drawable – you need to use app:srcCompat on ImageView or you’ll get a crash on pre Lollipop.

But some libraries take drawable xml resource in their method arguments ¬†and you pass vector drawable because you ether forget or expect them to handle those. Here you got yourself a crash and if you don’t test on pre L – you’re in trouble. Luckily those are almost dinosaurs

By recording simple navigation across your app into Espresso UI test, every screen, pop up, you’ll have this nice Java class, by running which you’ll have a walk-through your app. And then before every release build you just run it on different emulator configurations

Test UI, not Network

I remember that phrase and this phrase kills all the desire to create tests. Basically what it means is you need to mock data ( don’t use internet). Other than you spending time writing mock data, in many cases you actually want to test your servers. Like with Firebase, it’s kind of type unsafe if you have more than one platform (Android, iOS, web) which make write operations on their own. Danger Danger!

I think sometime before network wasn’t working with instrumented test, anyways, it works now and you can test everything.

Automate Testing?

Now how about automating tests, so you just run one command and run all the different emulators with different Espresso tests. I found this library on GitHub, but setting up seems such a pain in the ass. Feels like you’ll spend more time learning how to use it than you save by using it over the span of your whole life.

That was one of the reasons they made test recording. Because before them people would better do manual testing than spend tens of hours learning how to write tests (which suppose to save you time by you not testing manually, what an irony)


That’s it, just wanted to tell you guys how simple it is to automate crash finding

Thanks for reading, don’t forget to subscribe, follow me on Twitter, Facebook, G+ and share with friends if you think they’ll benefit from it!



  • Oleg (Beloo)

    Recorder doesn’t work well and has so many restrictions. With recorder your can start only from beginning (from first screen of app), always perform sign in, you can’t record any unusual action and you can’t even record regular action like typing in edittext, because of enormous lags on this action. This tool isn’t usable at this moment, and seems that Google suspended progress here
    Also you have suggested to test real environment and avoid mocks, but how again can you test something very rare, some not quite often response from server, any error?

    • As I said, I’m not a TDD guy, I don’t test my apps so much. Espresso is a great and easy way for me to find crashes before release builds