Introduction to Automated Android Testing – Part 1

I’ve seen a lot of people confused and unsure about how to do tests in Android. In the past, it was very difficult to test Android apps and there wasn’t much direction. In this series, I am going to try make testing a bit easier for you. This first post is just to get you started with testing, the next few will go more in depth into testing in Android. Let’s get started!

Why should I test anyway?

You probably don’t really need convincing, since you are already reading this blog post. Here are some reasons why I like to write tests:

• Testing forces you to think in a different way and implicitly makes your code cleaner in the process.
• You feel more confident about your code if it has tests.
• Shiny green status bars and cool reports detailing how much of your code is covered are both consequences of writing tests.
• Regression testing is made a lot easier, as automated tests would pick up the bugs first.

Regression testing is the biggest benefit for me. If you refactor and your tests still pass, you will be confident that you haven’t broken anything. The problem with testing is that you might not see the benefit of testing immediately, as the true value will only surface a couple of months later when you need to refactor.

What types of testing are there in Android?

Unit Testing

A unit test generally exercises the functionality of the smallest possible unit of code (which could be a method, class, or component) in a repeatable way.

Tools that are used to do this testing:

• JUnit – normal test assertions.
• Mockito – mocking out other classes that are not under test.
• PowerMock – mocking out static classes such as Android Environment  class etc.

UI Testing – Instrumentation Tests

A UI Test or Instrumentation Test mocks typical user interactions with your app. Clicking on buttons, typing in text are some of the things UI Tests can complete.

Tools that are used to do this testing:

• Espresso –  Used for testing within your app, selecting items, making sure something is visible. 
• UIAutomator – Used for testing interaction between different apps.

There are other tools that are available for this kind of testing such as Robotium, Appium, Calabash, Robolectric. 

What do I need to get started with Automated Testing?

In order for you to get started with automated testing in your app, you should follow some kind of architectural pattern that will help you test and structure your app in a clean, testable way. One such pattern that easily enables testing is Model View Presenter (MVP) for Views and Repository Pattern for Networking and Database Access.

Of course, this is not the only option for you as an Android Developer, it is one of the many that you can explore in order to get test coverage and a clean architecture.
I have found it very difficult to implement tests without having a defined structure, often my tests were useless and I didn’t know what to test, it was also very difficult to get code coverage on large apps. My UI tests were also not very reliable as they were testing against production servers. Hopefully we can address these issues in this blog series.

Structure your App in a Testable Way

Here is a diagram depicting the structure I will use as a guideline for the rest of the blog post series:

• Views  – Activities and Fragments. This is where we set text and make UI changes. I typically like to keep the Android specific code in this section and try not to pass a context further than the view, obviously this is not always easy but it is good guidance to try follow. Views should only talk to presenters.
• Presenters – This is where business logic to decide what should be displayed on the views is going to go.  Presenters talk to the repositories to get information out, and convey information to the Views. Try avoid putting Android specific code in your presenter if you can avoid it as it will make unit testing more difficult.
• Repositories – Decide where to get data from, should they come from local persisted data? Or should the data come from the network? Repositories talk to presenters.
• Models – Typically POJOs, these are models that are used by the Presenter and the View to convey information to the View from the Presenter.

Unit tests will test the Presenters and the Repositories. UI Tests will test the View all the way down to the repositories.

There are many great articles describing MVP and other architecture options – this blog post is not going to go into those details. Read more about different Android architectures here, here and here.

Where are Automated Tests placed in my Android app?

In your Android app folder structure, there are two folders that will house the tests: test  and androidTest

androidTest  – Android Instrumentation Tests are located here. The tests in this folder need to run on an Android Emulator or physical device.

test/ – Unit tests are placed in this folder. Unit Tests run on the JVM on your local machine and do not run on an Android device or emulator. This means they do not have access to Android classes (such as the Context  class).

---

Now that we are aware of the different kinds of tests and where to place in them in our apps. The next post we will go deeper into how to structure your code in order to allow for better unit testing. Check out Part 2 here!

Make sure you get notified about the rest of the series by subscribing to updates.