Introduction to Testing in Android

Hi, do you want to start writing tests for your Android apps and make them stable during constant new feature implementations? Let’s start a series about Android Testing.

As testing is one of my weakest areas in Android – I will be learning stuff just as most of you. It’s just that every developer will reach the point where you can build complex apps, but quality – is still behind. Here come tests, just like you, I want to learn how much it is possible to automate tests on Android

Types of Tests on Android

Basically, there are two types depending on where they run: Local and Instrumented tests. And two categories depending on what those tests are meant for: Unit Tests and UITests

Here’s a pyramid from official Google docs which I modified a bit, to show which test types run on computer or Android device

Tests in Android

As you see the second one says integrated, but by that, they mean integrated unit tests. And they suggest to write 70% local unit tests (Small testes), 20% integrated unit tests (Medium tests) and 10% UI tests (Large tests). I’ll trust this data for now because they definitely know much more about testing than I do

Local Tests

Local are tests which run on your computer. They don’t know anything about Android framework, even though you can import classes from it – you’ll get an exception when trying to call any methods. This is made intentionally so that they force you to write unit tests that do not depend on Android framework

You can monitor the elements of the Android framework with which your app interacts by running unit tests against a modified version of android.jar. This JAR file doesn’t contain any code, so your app’s calls to the Android framework throw exceptions by default

But there’s a way you can mimic Android framework – by mocking its methods with Mockito library. Basically how it works is you declare your own implementation for different methods. And since you do know class/method names from Android framework (they just throw exceptions) – you can get by

Also, there’s a great library called Robolectric, with it you don’t need to mock Android framework’s methods since they’re stubbed by Robolectric. They say it’s very close to running instrumented tests.

Instrumented Unit Tests

Those do have access to Android framework, since they run on an actual device or emulator. They’re great if you need to access Android framework’s classes (Parcelable, Context etc), testing databases and don’t want to mock methods, rely on Robolectric. But they still don’t have any UI

And to run those you need to build and install an apk to a device, so they are slower than local unit tests

UI Tests

Those obviously fall into integrated tests category, but they are not unit tests. UI tests feel the most natural to me simply because that’s the way I currently test apps: navigate, interact, verify results, look for crashes, debug

There’s one problem with it – it gets incredibly boring to go through the same parts of your app after each new feature implemented. Which means you skip testing some parts and as a result, you can get a fatal crash that has been around for 2 weeks and you didn’t know about it. Well, something like that.

Espresso

This framework lets you select an activity you want to test and write the whole list of interactions like clicks, typing, launch different activities and then verify that UI is in the correct state. And the cool part is that you see those interactions just like you would do them yourself. Also starting from Android 8 it’s possible to open other apps

UI Automator

It seems to be very similar to Espresso. But for now, I think Espresso is a more mainstream framework and is more developed. We’ll get deeper into those differences in the future posts

ADB UI Testing

There’re also two adb tools: monkeyrunner and monkey. Monkey runners lets your write some Python scripts to navigate through your app, make some interactions and look for crashes, take screenshots

Monkey is a simple adb tool where you just declare number of actions to perform and it runs through your app clicking on stuff and looking for crashes.

Conclusion

These are the main ways of testing Android apps. But they mean nothing until you make a mind change to TDD or just automating UI tests. In the following posts, we’ll get deep into each of those categories with actual examples of tests and mindset behind what part you’d test

If you do write tests for your apps – feel free to leave a comment and share your knowledge.

Post navigation

About Me

Hello I am Juma Allan, Founder and Author of Android Study. I am currently working as the Lead Android Engineer at dLight Solar, an Open Source Enthusiast and a big time Android Lover, learning Go and sharing my knowledge with others.

“If you don’t build your dream someone will hire you to help build theirs”