Android Testing (Kotlin) — Introduction

In this series of posts we are going to talk about Android Testing. It’s a big field to talk at, but here there are some important points and tips.

1. Introduction
2. How to test.
3. Unit tests.
4. Integration tests.

First of all we need a brief introduction to general testing.

What is testing?

Well, opening our app and manually try out all the functionalities is testing, right? But think about every time you make a change in you app. In order to have a good testing coverage you would need to try all the functionalities of the app every time your code changes just a little. And repeat it over and over again in your development cycle. Don’t get me wrong, manual testing is necessary to know how our app looks and how our app works. But in addition to that, having automatic tests in our projects, and running them after every change we make, will help us with the project development and maintenance. It’s better to use some of our development time in automatic testing than doing it only manually, no matter how much time we spend on it.

On the other hand, one tend to think that testing helps us to know if our app works correctly. But it does much more. When we develop a new feature, adding tests helps us to know if it works. In addition they should tell us if it does not work, or if it crash. And more important: where or even why it does not work. But it goes beyond there. While we keep developing the project, those tests assure that we are not breaking the previous developed features (recession bugs). We can now even change the code or refactor it being more confident about doing it right. Moreover, when a new bug is found, we can fix it and create a new test to be sure the bug is not going to happen again.

F.I.R.S.T. principles

According to Robert C. Martin, tests should follow the FIRST rule:

• Fast: tests should be fast when running. We want to run tests as much as possible on every iteration. If they don’t run fast, it’s going to be a bit painful.
• Independent: tests should not depend on each other. This is, every test should be individual, they shouldn’t expect results from other test or actions. This way we can run test individually or in random order. (In fact, in Android Studio they are run in random order to assure this property)
• Repeatable: tests should be repeatable in every run. If a test is repeatable means that we can trust it. If not, we won’t be sure about its results.
• Self-Validating: tests should have a boolean output. True if they pass or false if not. This way we can run multiple tests expecting all of them are true, instead of manually inspect the result of each one.
• Thorough: They should cover all user cases. Having reliable tests means you are simulating all possible scenarios and you can be sure they are working.

Tests classification

There are multiple ways to classify tests depending on the level we want to achieve. E.g: White box tests, black box tests, acceptance tests, user tests, scope tests, and so on.

However we are going to use one of the most used classification when we talk about Android testing: Unit Tests, Integration Tests and UI Tests

• Unit tests: are tests running single operations or methods. They are really fast, small and easy to run. We should create as much unit tests as we need to cover our core methods.
• Integration tests: are test running different modules together. This means, we have to prepare the infrastructure to make them work. They are bigger and slower than the first ones, so we will have less test in this level.
• UI tests: are test that interact directly with what the user can see and do. These test are the slowest ones and require to set up the environment. Because of this, usually this layer will contain less tests than the other two.

These points are well represented in the following pyramid. Remember: lots of Unit test, less integration tests and a few less UI tests.

This way we will cover almost all our code flow. Testing from the core logic to the user presentation of the app.

Tests in Android

We need a test runner to be able to run the tests against our Android app. The default test runner is JUnit. We can use other runners, but JUnit should be enough to run our tests, so no change is needed. If you are not familiar with testing, we will see some basic interactions with the runner in the following posts.

And last but not least, let’s see how test are organized in Android. When we create an Android application, along with some configuration files, a source folder is also created in /appName/src/main/java/package_structure. In addition to this, we can create two types of tests in two different folders (they are created automatically by the IDE):

• /appName/src/test/java/package_structure: these test will run over Java virtual machine. So, we will test here classes that use only pure Java (or Kotlin) code. We won’t include here any test that contains Android native code. (Note: we can mock and include some Android Objects if we need them)
• /appName/src/androidTest/java/package_structure: these tests need an Android emulator or physical device to run with. So, we will include here all tests containing any Android code (also non-UI Android tests that need objects like Context, Android resources and so on using sdks like Robolectric).

Note: to follow the good practices, tests should be included in the same package structure than its tested classes.

In order to create a test automatically witht he help of the IDE, put the cursor on the class’ name, alt + enter and select Create test

You will see a wizard to create a new test, asking you for the test name and some optional configurations. After that, you can choose where to create the test, inside test or androidTest folder depending of the test type you need.

Originally published at https://adalpari.github.io on October 16, 2018.