Android Test (ii): Android Test Basics

Android Test (ii): Android Test Basics

Release date December 20, 2017 bug Master

Original: https://developer.android.com/training/testing/fundamentals.html

Users interact with your app at different levels. From pressing the button to downloading the information to their device, you should test the various use cases and interactions as you iterate through the development of the application.

Using iterative development Workflows

As your application expands, you may find that you need to get data from the server, interact with the device's sensors, and also need to access local storage or present a complex user interface. The diversity of applications requires a comprehensive testing strategy.

When developing a new feature in an iteration, you first need to write a new test or add new test examples and assertions to the existing unit tests. The test started out as a failure because the new feature was not yet implemented.

When designing new features, it is important to consider the design of unit tests. Write a corresponding unit test for each functional unit. Your unit tests should cover as many interactions as possible with the unit, including standard interactions, invalid input, and unavailability of resources.

Figure: Test-driven Development: two cycles and iterative processes.

A complete workflow, such as a series of nested loop iterations. With long, slow, UI-driven integration testing, you can do this with shorter, faster unit test-driven development cycles. This series of loops continues until your application satisfies each use case.

Test pyramids

Figure: Test the pyramid to show the three test categories that should be included in the application's test suite.

Test the pyramids, as shown, to show how your application should include three types of tests: small, medium, and large.

• A small test is a unit test that you can run in isolation from your production system. They usually mock all the major components and run quickly on the PC.

• Mid-Test is an integration test between a small test and a large test. They integrate several components and run on an Android emulator or a real device.

• A big test is an integration and UI test that runs by completing a UI workflow. They ensure that critical end-user tasks work correctly on Android simulators or real-world devices.

Note: The test pyramid here is defined as Google's Test division for Android apps. Different types of applications, the division of hierarchy by the test pyramid model, and the definition of each layer will vary.

Although the small test is fast and focused, it allows you to quickly handle failures, but they are low fidelity and independent, making it hard to believe that the test application is working properly, so it needs to be complemented by big tests.

Because of the different characteristics of each test category, your test work should include testing each layer of the pyramid. Although the test scale for each category may vary depending on the application usage, we generally recommend the following categories: 70% of small Tests, 20% of medium tests, and 10% for large tests.

Small test

When you add and change the functionality of an application, you ensure that the functionality runs as expected by creating and writing unit tests. Although you can run unit tests in an Android emulator or a real device, it is often quicker and easier to run unit tests in a development environment, and you need to add stubs or mock methods to interact with your Android system.

Robolectric

If your application's test environment requires unit testing to interact more extensively with the Android framework, then you can use Robolectric. This tool performs a test-friendly, Java-based logic stub to emulate the Android framework, which is maintained by the community.

The Robolectric test is almost entirely consistent with the full fidelity of running tests on Android devices, but is still faster than device testing. It also supports the following aspects of the Android platform:

• Android 4.1 (API Level 16) and later
• Android Gradle Plugin 2.4 and later
• Component Life cycle
• Event Loops
• All Resources

Robolectric has its own set of test APIs and introduces some new concepts. For more information about combining Robolectric APIs with application testing, see the tool's User guide

Mock object

You can run unit tests by modifying the Android.jar version to monitor the Android framework elements that the app interacts with. This jar file does not contain any code, so your application calls the Android framework by default throws an exception. To test the code elements that interact with the Android system, use a framework like Mockito to configure the mock objects.

Detection Unit Test

You can also run test unit tests on Andorid simulators or real devices, without any stub or mock frames involved. Because this test form is significantly slower than the local unit test, it is best to rely on this method only if you need to evaluate the application's behavior with the current device hardware.

Medium test

After you have tested each unit of your application in the development environment, you should verify that the components behave correctly when running on the emulator or device. Medium testing allows you to complete this part of the development process. If the components of some applications depend on physical hardware, these tests are especially important for creating and running.

Medium test how your application coordinates multiple units, but they do not test the full application. The use cases for medium testing include UI tests for service testing, integration testing, and mock external dependency behavior.

Typically, it's a good idea to test your application on a cloud-based service such as an Android emulator or firebase test lab, rather than testing your application on a real device, because you can easily and quickly test multiple screen sizes and combinations of hardware configurations.

Big test

While it is important to test the functionality of each layer in the application, it is equally important to test common workflows and use cases (from the UI to the business logic to the data layer) that involve the entire stack.

If your application is small enough, you may need only a large set of tests to evaluate your application. Otherwise, you should divide your large test suites based on team ownership, vertical functionality, or user goals.

For each large workflow-based test you write, you should also write a test to check the functionality of each UI component contained in the workflow. In this way, even in the first few steps, the corresponding large tests fail, and your test suite continues to identify potential problems at every step of the key user's operations.

The Androidjunitrunner class defines a JUnit framework-based test runner that allows you to run JUnit 3 or JUnit 4-style test classes on Android devices. Easily load test packages and applications onto real devices or Android simulators, run tests and report results.

The Androidjunitrunner class supports the following tools and frameworks from the Android Test support library:

JUNIT4 Rules

The test description language includes the lifecycle of critical application components for management involving your test code, such as Activitie and service. Learn how to define these rules and see the JUNIT4 rules Guide

Espresso

Espresso synchronizes asynchronous tasks and automatically performs the following in-app interactions:

Performs an action on the View object. * Complete workflow across application process boundaries. Available only on Android 8.0 (API level 26) and later. * Assess how users with accessibility needs are using your app. * Find and activate items in Recyclerview and Adapterview objects. * Verify the status of outgoing intent. * Verify the structure of the DOM in the WebView object. * Keep track of long-running background operations in your application.

To learn more about these interactions and how to use them in your application's tests, see the Espresso Guide.

UI Automator

We recommend that you use UI Automator to test your application only if your application must interact with the system. Because the UI Automator interacts with the system application UI, you need to rerun and repair the UI Automator test after each system update. Such updates include an Android platform version upgrade and a new version of the Google Play service.

As an alternative to using UI Automator, we recommend adding a closed test or dividing a large test into a series of small and medium-sized tests. In particular, a focus at a time is to test communication between one application, such as sending information to other applications and responding to intent results. The Espresso-intents tool can help you write these smaller tests.

The UI Automator framework performs interactions within your application's system applications, such as checking the current display UI hierarchy, intercepting screens, and analyzing the current state of the device. For more details about how UI Automator checks the application you are testing, see the UI Automator Guide.

Android Test Orchestrator

Android test orchestrator runs each UI test in its own instrumentation sandbox, improving the reliability of the test suite by reducing the sharing state between Tests and isolating application crashes on a per-test basis.

Android Test (ii): Android Test Basics