Testing With Android

Profiles:
LinkedIn: https://www.linkedin.com/in/nikitha-gullapalli/
GitHub:https://github.com/nikitha2/EXAMPLE_ESPRESSO_uiTesting_tea_time.git

Introduction:

Testing is one of the most important steps in the development life cycle. Writing unit tests for each module is important, as we do not want to break old code when adding a new functionality. There are multiple APIs that help us write efficient tests and reduce boiler plate code. Figure below shows different testing APIs for different kind of tests.

Testing APIs classification

Testing APIs classification

Local Unit Tests- Unit tests that run on your local machine only. These tests are compiled to run locally on the Java Virtual Machine (JVM) to minimize execution time. These tests are fast, but have less fidelity (the degree of exactness).

Local unit tests can be implemented using two frequently used APIs.

• Mockito- is used when the code does not have much dependency on the android framework. We can mock the data going to the method/ code under test and assert the test if the output is as expected. For tests that depend on your own dependencies, use mock objects to emulate your dependencies’ behavior.
• Robolectric- is used when the code has good dependency on the android framework. Robolectric library can mock the dependency so we can run our tests on the JVM. If your tests depend on objects in the Android framework, we recommend using Robolectric.

Instrumented unit tests- These are tests that depend on the android device to run their tests. They run on an android device/ emulator. These tests are slower than the local unit tests, but have better fidelity. These tests have access to instrumentation information, such as the Context for the app under test. Use this approach to run unit tests that have complex Android dependencies that require a more robust environment.

• Espresso: Espresso can be used to write concise, beautiful, and reliable Android UI tests. The core API is small, predictable, and easy to learn and yet remains open for customization. Espresso tests state expectations, interactions, and assertions clearly without the distraction of boilerplate content, custom infrastructure, or messy implementation details getting in the way. Espresso tests run optimally fast! It lets you leave your waits, syncs, sleeps, and polls behind while it manipulates and asserts on the application UI when it is at rest.
• There are main steps in writing an espresso test include the following: Entry point to interactions with views (via onView() and onData()). Also exposes APIs that are not necessarily tied to any view, such as pressBack().
• ViewMatchers — A collection of objects that implement the Matcher<? super View> interface. You can pass one or more of these to the onView() method to locate a view within the current view hierarchy.
• ViewActions — A collection of ViewAction objects that can be passed to the ViewInteraction.perform() method, such as click().
• ViewAssertions — A collection of ViewAssertion objects that can be passed the ViewInteraction.check() method. Most of the time, you will use the matches assertion, which uses a View matcher to assert the state of the currently selected view.
• cheat-sheet for all combinations of viewMatchers-viewActions-viewAssertions can be found here.
• UI Automator: The UI Automator testing framework provides a set of APIs to build UI tests that perform interactions on user apps and system apps. The UI Automator APIs allows you to perform operations such as opening the Settings menu or the app launcher in a test device. The UI Automator testing framework is well-suited for writing black box-style automated tests, where the test code does not rely on internal implementation details of the target app.
• Firebase Test Lab: you can simultaneously test your app on many popular Android devices and device configurations (locale, orientation, screen size, and platform version). These tests run on physical and virtual devices in remote Google data centers. You can deploy apps to Test Lab directly from Android Studio or from the command line. Test results provide test logs and include the details of any app failures.

Conclusion

Google suggests an app to have 70% local unit tests, 30% instrumented unit tests (medium and large tests). Most of the information has been taken from android documentation. Please refer to android documentation for detailed instructions on how to use use library for testing. link:https://developer.android.com/training/testing

Addition Resources:

Espresso

Setting SharedPrefs before launching an Activity

Exploring AndroidJUnitRunner filtering options — passing credentials as environment variables, so that they wont be included in the code.

Test If image view has a specific background image/ does not have a background

UI Automator

UI Automator viewer -The uiautomatorviewer tool provides a convenient GUI to scan and analyze the UI components currently displayed on an Android device