Chapter 6 APP Stability Testing

1. Overview

The automated testing framework arkxtest is an important part of the toolset, supporting the JS/TS language unit testing framework (JsUnit) and UI testing framework (UiTest). JsUnit provides unit test case execution capabilities, basic interfaces for writing test cases, generates corresponding reports, and is used for testing system or application interfaces. UiTest provides the ability to find and operate interface controls through simple and easy-to-use APIs, supporting users in developing automated test scripts based on interface operations. This guide introduces the main functions, implementation principles, environment preparation, test script writing, and execution of the testing framework.

2. Environment Preparation

Environment Requirements: The writing of automated scripts is mainly based on DevEco Studio. It is recommended to use version 3.0 or later. Script execution requires PC to be connected to hardware device.

Script execution requires PC to be connected to board hardware device

For setting up the environment, DevEco Studio can be downloaded and configured as described in Chapter 03 - Development Environment Preparation.

3. Create and Write Test Scripts

To create a new test script: In DevEco Studio, create a new application development project. The ohos directory is where the test scripts are located. Under the project directory, open the ets file of the module to be tested. Place the cursor at any position in the code, right-click > Show Context Actions > Create Ohos Test or use the shortcut key Alt+enter > Create Ohos Test to create a test class. For more guidance, please refer to the DevEco Studio guidance.

4. Write Unit Test Scripts

Note

This chapter mainly describes the capabilities supported by the unit testing framework and how to use those capabilities.

In the unit testing framework, test scripts need to include the following basic elements:

• Import dependencies to use the testing interfaces of the dependencies.

• Write test code, mainly writing the related logic of the test code, such as interface calls, etc.

• Assert interface calls, set checkpoints in the test code. Without checkpoints, it cannot be considered a complete test script.

The scenario implemented by the following example code is: Start the test page and check whether the page currently displayed on the device is the expected page.

5. Write UI Test Scripts

This chapter mainly introduces the capabilities supported by the UI testing framework and how to use the APIs of those capabilities. UI testing is based on unit testing. UI test scripts add calls to UiTest interfaces (providing links) on the basis of unit test scripts to complete corresponding testing activities. The following example code is incrementally written on the basis of the unit test script above. It implements clicking operations on the started application page and then checking whether the current page change is the expected change.

1. Add dependency import: import { Driver, ON } from '@ohos.UiTest'

2. Write index.ets page code

3. Write specific test code

4. Execute test scripts

DevEco Studio execution is done by clicking the button. Currently, the following execution methods are supported:

• Test package level execution, i.e., execute all test cases in the test package.

• Test suite level execution, i.e., execute all test cases defined in the describe method.

• Test method level execution, i.e., execute the specified it method, which is a single test case.

View Test Results

After test execution is complete, you can directly view the test results in DevEco Studio, as shown in the following example:

6. Common Problems

Common Problems with Unit Test Cases

Error 1

Print logs added in test cases are printed after the test results

Problem Description

The log print information added in the test case does not appear during test case execution, but appears after the test case execution ends.

Possible Cause

This situation only occurs when there are asynchronous interface calls in the test case. In principle, all log information in the test case should be printed before the test case execution ends.

Solution

When there is more than one asynchronous interface being called, it is recommended to encapsulate the interface calls in Promise calls.

Error 2

Error reported when executing test case: fail to start ability

Problem Description

When executing the test case, the test case execution fails, and the console returns the error: fail to start ability.

Possible Cause

There is a problem during the test package packaging process, and the test framework dependency files are not packaged in the test package.

Solution

Check if the test package contains the OpenHarmonyTestRunner.abc file. If not, recompile and package, then execute the test again.

Error 3

Test case timeout error reported when executing test case

Problem Description

Test case execution ends, and the console prompts the execute time XXms error, meaning the test case execution timed out.

Possible Cause

• The test case executes an asynchronous interface, but the done function is not executed during the execution, causing the test case execution to never end until it times out.

• The function called by the test case takes too long, exceeding the timeout setting for test case execution.

• The assertion in the called function fails, throwing a failure exception, causing the test case execution to never end until it times out.

Solution

• Check the test case code logic to ensure that even if the assertion fails, the scenario can proceed to the done function to ensure the test case execution ends.

• You can modify the test case execution timeout configuration parameter in Run/Debug Configurations in the IDE to avoid test case execution timeout.

• Check the test case code logic and assertion results to ensure assertions pass.

Common Problems with UI Test Cases

Error 1

Failure log has "Get windows failed/GetRootByWindow failed" error information

Problem Description

UI test case execution fails. Viewing the hilog log, the log contains "Get windows failed/GetRootByWindow failed" error information.

Possible Cause

The system ArkUI switch is not enabled, causing the control tree information of the tested interface to not be generated.

Solution

Execute the following commands and restart the device to execute the test case again.

```typescript
hdc shell param set persist.ace.testmode.enabled 1
shell
hdc shell param set persist.ace.testmode.enabled 1

::: warning Error 2
Failure log has "uitest-api does not allow calling concurrently" error information
:::

**Problem Description**

UI test case execution fails. Viewing the hilog log, the log contains "uitest-api does not allow calling concurrently" error information.

**Possible Cause**

- The asynchronous interface provided by the UI testing framework in the test case does not have await syntax sugar call added.

- Multi-process execution of UI test cases, causing multiple UITest processes to be pulled up. The framework does not support multi-process calls.

**Solution**

- Check the test case implementation and add await syntax sugar calls for asynchronous interfaces.

- Avoid multi-process execution of UI test cases.

::: warning Error 3
Failure log has "does not exist on current UI! Check if the UI has changed after you got the widget object" error information
:::

**Problem Description**

UI test case execution fails. Viewing the hilog log, the log contains "does not exist on current UI! Check if the UI has changed after you got the widget object" error information.

**Possible Cause**

After the code in the test case finds the target control, the device interface changes, causing the found control to be lost and unable to proceed with the next simulation operation.

**Solution**

Re-execute the UI test case.

---