Mobile Android apps run on various devices (smartphones, tablets, phablets, chromebooks) that can vary considerably in screen size, resolution, processing power, memory and connectivity. Manually testing the bespoke Android apps we develop for you across all these different device set-ups would be virtually impossible and therefore we utilise automated Android app testing.
Testing your Android app is an integral part of the app development process. By continually running tests against your app during development, we can make sure the app performs to the highest standards and gives users a great user experience.
The Android Testing Support library (ATSL) provides an excellent framework for testing the Android apps we develop. It has a JUnit 4-compatible test runner (AndroidJUnitRunner) and functional User Interface (UI) testing through Espresso and UI Automator. We can run tests for these APIs directly in the Android Studio IDE (which is the Android development software we use) which makes it very easy to integrate Android app testing into our Android app development flow.
Effective Unit Tests
Unit tests are fundamental to a robust app testing strategy. Running unit tests against our code allows our Android app development team to instantly verify that the logic of individual units is correct. Running unit tests after every build helps us to quickly catch and fix software bugs introduced by code changes.
A unit test tries out the functionality of the smallest possible unit of code (e.g. a method, class, or component) in a way that can be repeated time and again. We build unit tests when we need to verify the logic and functionality of specific code or algorithms in your app.
Automated User Interface Tests
User Interface (UI) testing allows us to make sure your app meets functionality requirements and also achieves a high level of quality, thereby making it easier for it to be adopted by users. We have found that when asking technicians/drivers/engineers etc to use one of the bespoke Android apps we have developed, rather than say their old way of working with printed job sheets, there will always be resistence - anything that can be done to make the app simple and intuative to use will help get buy-in from the staff who are meant to use the app on a day-to-day basis.
The old-school approach to UI testing is to have a human tester perform a set of scripted user operations on the app to check that it is behaving correctly. However, this manual approach can be very time-consuming and, more importantly, it can be error-prone. A much more efficient approach is for us to write UI tests so user actions are performed in an automated way which allows our tests to run quickly and reliably in a repeatable manner.
What is Espresso in Android Testing?
We can use Espresso to write concise and reliable Android UI tests. The core Espresso API runs tests very quickly and can test clearly things such as state expectations, interactions, and assertions. Espresso is targeted at developers who are familiar with the code under test and therefore the Espresso tests are performed by the Android app developer who wrote the actual app's code.
What is AndroidJUnitRunner?
The AndroidJUnitRunner class is a JUnit test runner that lets us run test classes on Android devices, including those using the Espresso and UI Automator testing frameworks. JUnit is a simple framework to write repeatable tests. It is an instance of the xUnit architecture for unit testing frameworks. The test runner handles loading our test package and app on to a device as well as running our tests and reporting the test results.
What is UI Automator?
UI Automator is a UI testing framework which provides a set of APIs to build UI tests that perform interactions on user apps and system apps. The UI Automator APIs allows us to perform operations such as opening the Settings menu or the app launcher in a test device.
Model-View-Presenter (MVP) Architecture
There are many different ways for our software engineers to architect your Android app. Not all of them are testable so for a truly testable architecture it is best to separate key parts of the application, making them easier to maintain and test individually. A common UI pattern is the Model-View-Presenter architecture, or MVP for short which is a user interface architectural pattern engineered to facilitate automated unit testing and improve the separation of concerns in presentation logic:
- The "model" provides and stores the internal data.
- The "view" is a passive interface that displays data (the model) and routes user commands (events) to the presenter to act upon that data.
- The "presenter" sits between the model and view. It retrieves data from repositories (the model), and formats it for display in the view (basically it coordinates the UI with the data, ensuring they are in sync, i.e. it updates the view and acts upon user events forwarded by the view).