Mastering the World of Android Testing (Part 1)
Today, we are going to discuss in-depth about testing in Android and help you in starting your journey towards understanding and mastering it.
Yes, I know that the testing experience on Android has never been easy. It is filled with a lot of struggle understanding the concepts and scratching your head putting different pieces of the puzzle together. But after reading this series, I am pretty sure you will not feel the same ever again.
The main motivation behind writing this series is to give you a clear picture of the complete world of testing in Android and making it simple and easily understandable to you. Even if you had no prior experience of testing before, this series will prove to be the perfect start for your journey.
But if you have been writing tests on Android for quite some time now and want to level up your game to have a deeper understanding of the different types of testing, how you should approach them properly, the wide variety of tools and frameworks available to you and which tool to pick under what circumstances, then you are absolutely at the right place.
So, without wasting any time further, let’s get started.
Why Care About Testing?
Before diving deep into the various types of testing and the frameworks available, you should have a very clear understanding of why you should actually care about doing automated testing.
Like for a long time in my initial development career, I was not clear with the idea of “why” should I actually spend time in writing automated tests rather than doing it manually in the usual way. I mean, I obviously knew the so-called “theoretical” reasons but was not clear with the actual implications of writing and not writing tests.
Building Confidence In Your Code
I have seen this happening several times when a developer had developed a particular feature and shared the build with the QA team only to find the build failing flat even in the first round of testing. Even some of the basic acceptance tests were also failing.
This would have never happened if the developer had decided to write tests while developing the app. Identifying each and every success and failure cases and writing tests for them will ensure that you have confidence in the code you write and deliver.
Getting Rid Of Regression Bugs
Suppose you have been working hard on a new feature and have released it to production but just within a day of release, you find some old and already working feature breaking down from nowhere. You are absolutely clueless about what actually went wrong and is likely to waste a lot of time identifying these “regression bugs” and fixing them.
This situation would have never arrived if you had tests written for your old features. You could frequently run those tests while working on your new feature and instantly catch the bug from a failing test and identify what actually went wrong.
Writing Minimal Code
Once you start writing tests for your code, you will eventually end up writing a lot less production code than you would have written without tests. Now your main goal would be to only write code to make a particular test pass, and nothing more.
Suppose you are following Test-Driven Development (TDD) and you have written a test. Now your main target will be to write only the required code to make that particular test pass. You will not be writing any extra or spurious code that you would have written otherwise.
In the long run, you will be saving a lot of time and releasing flawless and robust features faster than before maintaining a lean and clean codebase.
Legacy code is any code that does not have tests.
Recommended Reading
The Testing Pyramid
Now let’s take some time to understand the testing pyramid. This will essentially give you a very clear idea of the different types of tests you need to write and how they differ from each other.
Unit Tests
These are going to be the major chunk of tests you are going to write in your app, like around 70% of your total tests. These are small, highly-focussed tests that can run right on your local development machine and as they run directly on your local environment, they are very fast and their execution time is very less.
You should write these types of tests for various business logic related stuff. Each test should be small and targeted and only target a particular scenario and nothing more than that. You are likely to have hundreds (or even thousands) of these tests and run them very often while developing your app.
The only downside of these tests is that they don’t run on a real device and their fidelity is lesser compared to the other types of tests. You will be using various mocking techniques to emulate various state and behavior and might not always be sure if they would actually work on a real device.
Integration Tests
These are the tests that will actually run on a real device and not on a local machine and is meant to test the integration between different modules working together.
These tests typically verify if two different modules or components are working together in the way they should. It is quite different from testing business logic that we discussed earlier. Generally, these tests are medium in size (larger than unit tests but shorter than end-to-end tests) and should comprise of around 20% of the total tests written for your app.
A simple example of an integration test would be to check if clicking on a particular button on an Activity is taking you to another Activity. This not testing an unit of logic residing in a particular Activity, rather verifying the integration between two separate Activities working together.
As these tests run on a real device or emulator, they tend to be much slower than unit tests and you would typically want to run them a lot less often. But the fidelity of these tests is much higher than unit tests as these tests are running on a real device running a real OS and verifying the true interaction between various components of your app.
End-to-End Tests
You are going to write only a few of these tests for your app. Ideally, we try to ensure that around 10% of our total tests are end-to-end tests. As the name suggests, you will use these kinds of tests to test a flow completely from one end to the other.
Suppose, your app has got a sign-up flow comprising of several steps and you want to test the entire flow, that’s exactly when you would want to write an end-to-end test. These tests will also run on a real device or emulator just like integration tests and therefore will again be quite slow in their execution.
But the fidelity of these tests is much higher as these tests also run on an actual device and the scope of these tests are much larger as they are testing a complete feature or a flow completely end-to-end. As the scope of these tests tends to be quite large in size, it can become quite challenging to debug what actually went wrong, if a particular test fails.
Testing Types In Android
Now as you have a clear understanding of the various types of tests you can write and when you should write them, let’s try to understand the types of tests available on the Android platform.
Don’t worry as these are not anything completely different from what we had discussed earlier, but in Android, we tend to classify tests on the basis of whether they are running on a local machine or on a real device/emulator.
Local Unit Tests
These are the tests that we have already talked about as unit tests which can run locally on your development machine. These tests reside under the path module/src/test/java and do not have any access to any Android framework APIs.
Suppose you have a method named validateEmailAddress(String) and you want to get this method’s functionality tested. You would want to write very small and focused tests for each scenario of this functionality like when the email is null, or is empty or is not valid, etc.
For unit testing, we make use of JUnit which is a very popular unit testing framework helping us to write clear and understandable tests. We can also make use of Robolectric which is another popular testing framework allowing us to unit test the Android dependencies as well.
Instrumented Tests
These are the tests which belong to the “Integration” and “End-to-End” tests category already discussed in the testing pyramid section. All these tests belong to the path module/src/androidTest/java.
Notice the addition of the “android” prefix before the “test” which signifies that these tests should run on an Android device or an emulator and will have access to Android dependencies. These are basically known as “source sets”, in case if you were curious.
These tests are quite slow in execution as a new test APK is created every time and run along with your original app under test. Both these apps run on the same process which enables the test app to access methods and fields on the actual app and automate user interactions as well.
You can use these type of tests to automate clicking on any button, typing some text, swiping some views, scrolling through lists and performing various actions in your app that only an actual user can perform manually.
Now you might have a question as to why these are called “instrumentation” tests? This is because they use the Android Instrumentation API via InstrumentationRegistry to control Android components and their lifecycle manually instead of letting the system control them.
The most popular framework we use to write instrumentation tests is Espresso. But we can also make use of other frameworks like UIAutomator to write tests that span across multiple apps at the same time which Espresso is not capable of.
For example, suppose you want to test if you can share a particular photo from your app to another 3rd party app. Here, we want to verify the interaction of our app with other 3rd party apps, which is where UIAutomator can come into play.
Recommended Reading
So, by now you should have a pretty good idea as to why you need to write tests for your application. You have also got a good idea of the different types of tests that you need to write and when should you write them.
We have just scratched the surface of Android testing till now. We will be back with another awesome article on this series where we will be busting some testing myths, talking about various testing tools and frameworks available and much more. So stay tuned.
This article was originally published on TechBeacon.
Next in the series
