Skip to content

D
Docs

OpenHarmony / Docs
大约 2 年 前同步成功

通知 161
Star 293
Fork 28
D
Docs
“b40addd107d512f05b9f04509bca5fb4abac0dfe”上不存在“src/git@gitcode.net:qq_30916377/VueJS.git”
未验证 提交 56e3961f 编写于 作者: O openharmony_ci 提交者： Gitee
浏览文件
操作

!21841 翻译完成... 

!21841 翻译完成 20271+20154+20678：自测试框架添加stage模型编译使用说明指导+对toast的bottom属性进行api保护+静态卡片需求，formInfo新增isDynamic字段
Merge pull request !21841 from ester.zhou/TR-20271
上级 0074f313 15a76234
隐藏空白更改
内联 并排
Showing with 1232 addition and 674 deletion
en/application-dev/application-models/arkts-ui-widget-configuration.md
浏览文件 @ 56e3961f
......@@ -16,7 +16,7 @@ Widget-related configuration includes **FormExtensionAbility** configuration and
"extensionAbilities": [
{
"name": "EntryFormAbility",
"srcEntry": "./ets/entryformability/EntryFormAbility.ts",
"srcEntry": "./ets/entryformability/EntryFormAbility.ets",
"label": "$string:EntryFormAbility_label",
"description": "$string:EntryFormAbility_desc",
"type": "form",
......@@ -42,9 +42,9 @@ Widget-related configuration includes **FormExtensionAbility** configuration and
| description | Description of the widget. The value can be a string or a resource index to descriptions in multiple languages. The value is a string with a maximum of 255 bytes.| String| Yes (initial value: left empty)|
| src | Full path of the UI code corresponding to the widget. For an ArkTS widget, the full path must contain the widget file name extension, for example, **./ets/widget/pages/WidgetCard.ets**. For a JS widget, the full path does not need to contain the widget file name extension, for example, **./js/widget/pages/WidgetCard**.| String| No|
| uiSyntax | Type of the widget.<br>- **arkts**: ArkTS widget<br>- **hml**: JS widget| String| Yes (initial value: **hml**)|
| window | Window-related configurations.| Object| Yes|
| window | Window-related configurations.| Object| YYes (initial value: see Table 2)|
| isDefault | Whether the widget is a default one. Each UIAbility has only one default widget.<br>- **true**: The widget is the default one.<br>- **false**: The widget is not the default one.| Boolean| No|
| colorMode | Color mode of the widget.<br>- **auto**: auto-adaptive color mode<br>- **dark**: dark color mode<br>- **light**: light color mode| String| Yes (initial value: **auto**)|
| colorMode | Color mode of the widget.<br>- **auto**: following the system color mode<br>- **dark**: dark color mode<br>- **light**: light color mode| String| Yes (initial value: **auto**)|
| supportDimensions | Grid styles supported by the widget.<br>- **1 * 2**: indicates a grid with one row and two columns.<br>- **2 * 2**: indicates a grid with two rows and two columns.<br>- **2 * 4**: indicates a grid with two rows and four columns.<br>- **4 * 4**: indicates a grid with four rows and four columns.| String array| No|
| defaultDimension | Default grid style of the widget. The value must be available in the **supportDimensions** array of the widget.| String| No|
| updateEnabled | Whether the widget can be updated periodically.<br>- **true**: The widget can be updated at a specified interval (**updateDuration**) or at the scheduled time (**scheduledUpdateTime**). **updateDuration** takes precedence over **scheduledUpdateTime**. If both are specified, the value specified by **updateDuration** is used.<br>- **false**: The widget cannot be updated periodically.| Boolean| No|
......@@ -56,6 +56,13 @@ Widget-related configuration includes **FormExtensionAbility** configuration and
| dataProxyEnabled | Whether the widget supports the [update-through-proxy](./arkts-ui-widget-update-by-proxy.md) feature.<br>- **true**: The widget supports the update-through-proxy feature.<br>- **false**: The widget does not support the update-through-proxy feature.<br>If this tag is set to **true**, the settings for the scheduled update time will still take effect, but the settings for the update interval and next update time will not.| Boolean| Yes (initial value: **false**)|
| isDynamic | Whether the widget is a dynamic widget. This tag only applies to ArkTS widgets.<br>- **true**: The widget is a dynamic widget.<br>- **false**: The widget is a static widget. In this case, the widget is displayed as a static image after being added.| Boolean| Yes (initial value: **true**)|
**Table 2** Internal structure of the window object
| Field| Description| Data Type| Default Value Allowed|
| -------- | -------- | -------- | -------- |
| designWidth | Baseline width for page design. The size of an element is scaled by the actual device width.| Number| Yes (initial value: **720px**)|
| autoDesignWidth | Whether to automatically calculate the baseline width for page design. If it is set to **true**, the **designWidth** attribute will be ignored, and the baseline width will be calculated based on the device width and screen density.| Boolean| Yes (initial value: **false**)|
Example configuration:
......
en/device-dev/device-test/developer_test.md
浏览文件 @ 56e3961f
......@@ -8,7 +8,7 @@ OpenHarmony provides you with a comprehensive development self-test framework **
This document describes how to use the development self-test framework of OpenHarmony.
### Introduction
### Overview
After adding or modifying code, OpenHarmony developers want to quickly verify whether the modified code functions properly, and the system already has a large number of automated test cases of existing functions, such as TDD cases and XTS cases. The development self-test framework aims to help you improve your self-test efficiency so that you can quickly execute the specified automated test cases and conducting development tests at the development phase.
......@@ -18,7 +18,7 @@ After adding or modifying code, OpenHarmony developers want to quickly verify wh
When executing test cases using the framework, you must connect to the OpenHarmony device in advance.
## Environment Preparations
## Environment Setup
The development self-test framework depends on the Python environment. It is required that the Python version be 3.7.5 or later. Before using the framework, you can refer to the following document for configuration.
......@@ -28,16 +28,20 @@ Click [here](https://gitee.com/openharmony/docs/blob/master/en/device-dev/get-co
| Environment Dependency | Version | Description |
| ----------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
| Operating system | Ubuntu 18.04 or later | Code compilation environment. |
| Operating system | Ubuntu 20.04 or later | Code compilation environment. |
| Linux extension component| libreadline-dev | Plugin used to read commands. |
| python | 3.7.5 or later | Language used by the test framework. |
| Python plugins | pyserial 3.3 or later, paramiko 2.7.1 or later, setuptools 40.8.0 or later, and rsa4.0 or later| - **pserial**: supports Python serial port communication.<br>- **paramiko**: allows Python to use SSH. <br>- **setuptools**: allows Python packages to be created and distributed easily. <br>- **rsa**: implements RSA encryption in Python.|
| NFS Server | haneWIN NFS Server 1.2.50 or later or NFS v4 or later | Devices can be connected using serial ports. Mini- and small-system devices are used. |
| HDC | 1.1.0 | A tool that enables devices to be connected through the HarmonyOS Device Connector (HDC). |
| HDC | 1.2.0a | A tool that enables devices to be connected through the OpenHarmony Device Connector (HDC). |
1. Run the following command to install the Linux extended component readline:
1. Install Ubuntu.
As Ubuntu 20 has built-in Python 3.8.5, you do not need to install Python separately.
2. Run the following command to install the Linux extended component readline:
```bash
sudo apt-get install libreadline-dev
......@@ -91,7 +95,9 @@ Click [here](https://gitee.com/openharmony/docs/blob/master/en/device-dev/get-co
6. Install the NFS server if the device outputs results only through the serial port.
> This step is applicable to small-system or mini-system devices.
> ![icon-note.gif](/en/device-dev/driver/public_sys-resources/icon-note.gif) **NOTE**
>
> This operation applies to small-system or mini-system devices, not standard-system devices.
- Windows OS: Install the **haneWIN NFS Server1.2.50** package.
- Linux OS: Run the following command to install the NFS server:
......@@ -107,299 +113,34 @@ Click [here](https://gitee.com/openharmony/docs/blob/master/en/device-dev/get-co
0 upgraded, 0 newly installed, 0 to remove and 11 not upgraded.
```
7. If the device supports HDC connection, install the HDC tool. For details about the installation process, see [HDC-OpenHarmony device connector](https://gitee.com/openharmony/developtools_hdc/blob/master/README.md).
7. If the device supports HDC connection, install the HDC tool. For details about the installation process, see [HDC-OpenHarmony Device Connector](https://gitee.com/openharmony/developtools_hdc/blob/master/README.md).
### Environment Dependency Check
| Check Item | Operation | Requirement |
| Check Item | Action | Requirement |
| -------------------------------------------------- | --------------------------------------------------- | ------------------------- |
| Check whether Python is installed successfully. | Run the **python --version** command. | The Python version is 3.7.5 or later. |
| Check whether Python plugins are successfully installed. | Go to the **test/developertest** directory and run **start.bat** or **start.sh**.| The **>>>** prompt is displayed.|
| Check the NFS server status (for the devices that support only serial port output).| Log in to the development board through the serial port and run the **mount** command to mount the NFS. | The file directory can be mounted. |
| Check whether the HDC is successfully installed. | Run the **hdc_std -v** command. | The HDC version is 1.1.0 or later. |
| Check whether the HDC is successfully installed. | Run the **hdc -v** command. | The HDC version is 1.2.0a or later. |
## Test Case Preparation
The test framework supports multiple types of tests and provides different test case templates for them._
The test framework supports multiple types of tests and provides different test case templates for them.
**TDD Test (C++)**
Naming rules for source files
The source file name of test cases must be the same as that of the test suite. The file names must use lowercase letters and in the *Function*_*Sub-function*_**test** format. More specific sub-functions can be added as required.
Example:
```
calculator_sub_test.cpp
```
Test case example
```c++
/*
* Copyright (c) 2021 XXXX Device Co., Ltd.
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
#include "calculator.h"
#include <gtest/gtest.h>
using namespace testing::ext;
class CalculatorSubTest : public testing::Test {
public:
static void SetUpTestCase(void);
static void TearDownTestCase(void);
void SetUp();
void TearDown();
};
void CalculatorSubTest::SetUpTestCase(void)
{
// Set a setup function, which will be called before all test cases.
}
void CalculatorSubTest::TearDownTestCase(void)
{
// Set a teardown function, which will be called after all test cases.
}
void CalculatorSubTest::SetUp(void)
{
// Set a setup function, which will be called before all test cases.
}
void CalculatorSubTest::TearDown(void)
{
// Set a teardown function, which will be called after all test cases.
}
/**
* @tc.name: integer_sub_001
* @tc.desc: Verify the sub function.
* @tc.type: FUNC
* @tc.require: issueNumber
*/
HWTEST_F(CalculatorSubTest, integer_sub_001, TestSize.Level1)
{
// Step 1 Call the function to obtain the test result.
int actual = Sub(4, 0);
// Step 2 Use an assertion to compare the obtained result with the expected result.
EXPECT_EQ(4, actual);
}
```
The procedure is as follows:
1. Add comment information to the test case file header.
```
/*
* Copyright (c) 2021 XXXX Device Co., Ltd.
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
```
2. Add the test framework header file and namespace.
```c++
#include <gtest/gtest.h>
using namespace testing::ext;
```
3. Add the header file of the test class.
```c++
#include "calculator.h"
```
4. Define the test suite (test class).
```c++
class CalculatorSubTest : public testing::Test {
public:
static void SetUpTestCase(void);
static void TearDownTestCase(void);
void SetUp();
void TearDown();
};
void CalculatorSubTest::SetUpTestCase(void)
{
// Set a setup function, which will be called before all test cases.
}
void CalculatorSubTest::TearDownTestCase(void)
{
// Set a teardown function, which will be called after all test cases.
}
void CalculatorSubTest::SetUp(void)
{
// Set a setup function, which will be called before all test cases.
}
void CalculatorSubTest::TearDown(void)
{
// Set a teardown function, which will be called after all test cases.
}==
```
> **NOTE**
>
> When defining a test suite, ensure that the test suite name is the same as the target to build and uses the upper camel case style.
5. Add implementation of the test cases, including test case comments and logic.
```c++
/**
* @tc.name: integer_sub_001
* @tc.desc: Verify the sub function.
* @tc.type: FUNC
* @tc.require: issueNumber
*/
HWTEST_F(CalculatorSubTest, integer_sub_001, TestSize.Level1)
{
// Step 1 Call the function to obtain the test result.
int actual = Sub(4, 0);
// Step 2 Use an assertion to compare the obtained result with the expected result.
EXPECT_EQ(4, actual);
}
```
> **NOTE**
>
> @tc.require: The format must be started with **AR/SR** or **issue**, for example, **issueI56WJ7**.
The following test case templates are provided for your reference.
| Type | Description |
| --------------- | ------------------------------------------------ |
| HWTEST(A,B,C) | Use this template if the test case execution does not depend on setup or teardown. |
| HWTEST_F(A,B,C) | Use this template if the test case execution (excluding parameters) depends on setup or teardown.|
| HWTEST_P(A,B,C) | Use this template if the test case execution (including parameters) depends on setup or teardown. |
In the template names:
- **A** indicates the test suite name.
- **B** indicates the test case name, which is in the *Function*_*No.* format. The *No.* is a three-digit number starting from **001**.
- *C* indicates the test case level. There are five test case levels: guard-control level 0 and non-guard-control level 1 to level 4. Of levels 1 to 4, a smaller value indicates a more important function verified by the test case.
**NOTE**
- The expected result of each test case must have an assertion.
- The test case level must be specified.
- It is recommended that the test be implemented step by step according to the template.
- The comment must contain the test case name, description, type, and requirement number, which are in the @tc.*xxx*: *value* format. The test case type @**tc.type** can be any of the following:
| Test Case Type| Code|
| ------------ | -------- |
| Function test | FUNC |
| Performance test | PERF |
| Reliability test | RELI |
| Security test | SECU |
| Fuzzing test | FUZZ |
**TDD Test (JS)**
- Naming rules for source files
The source file name of test cases must be the same as that of the test suite. The file names must use lowercase letters and in the [Function]\_[Sub-function]\_**test** format. More specific sub-functions can be added as required.
The source file name of a test case must be in the *Function**Sub-function***Test** format, and each part must use the upper camel case style. More specific sub-functions can be added as required.
Example:
```
AppInfoTest.js
```
- Test case example
```js
/*
* Copyright (C) 2021 XXXX Device Co., Ltd.
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
import app from '@system.app'
import {describe, beforeAll, beforeEach, afterEach, afterAll, it, expect} from 'deccjsunit/index'
describe("AppInfoTest", function () {
beforeAll(function() {
// Set a setup function, which will be called before all test cases.
console.info('beforeAll caled')
})
afterAll(function() {
// Set a teardown function, which will be called after all test cases.
console.info('afterAll caled')
})
beforeEach(function() {
// Set a setup function, which will be called before all test cases.
console.info('beforeEach caled')
})
afterEach(function() {
// Set a teardown function, which will be called after all test cases.
console.info('afterEach caled')
})
/*
* @tc.name:appInfoTest001
* @tc.desc:verify app info is not null
* @tc.type: FUNC
* @tc.require: issueNumber
*/
it("appInfoTest001", 0, function () {
// Step 1 Call the function to obtain the test result.
var info = app.getInfo()
// Step 2 Use an assertion to compare the obtained result with the expected result.
expect(info != null).assertEqual(true)
})
})
```
The procedure is as follows:
1. Add comment information to the test case file header.
- The following uses **calculator_sub_test.cpp** as an example to describe how to compile a single-thread test case:
```
/*
* Copyright (C) 2021 XXXX Device Co., Ltd.
* Copyright (c) 2023 XXXX Device Co., Ltd.
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
......@@ -412,55 +153,446 @@ The procedure is as follows:
* See the License for the specific language governing permissions and
* limitations under the License.
*/
```
2. Import the APIs and JSUnit test library to test.
```js
import app from '@system.app'
import {describe, beforeAll, beforeEach, afterEach, afterAll, it, expect} from 'deccjsunit/index'
```
3. Define the test suite (test class).
```js
describe("AppInfoTest", function () {
beforeAll(function() {
// Set a setup function, which will be called before all test cases.
console.info('beforeAll caled')
})
afterAll(function() {
// Set a teardown function, which will be called after all test cases.
console.info('afterAll caled')
})
beforeEach(function() {
// Set a setup function, which will be called before all test cases.
console.info('beforeEach caled')
})
afterEach(function() {
// Set a teardown function, which will be called after all test cases.
console.info('afterEach caled')
})
```
4. Add implementation of the test cases.
```JS
/*
* @tc.name:appInfoTest001
* @tc.desc:verify app info is not null
#include "calculator.h"
#include <gtest/gtest.h>
using namespace testing::ext;
class CalculatorSubTest : public testing::Test {
public:
static void SetUpTestCase(void);
static void TearDownTestCase(void);
void SetUp();
void TearDown();
};
void CalculatorSubTest::SetUpTestCase(void)
{
// Set a setup function, which will be called before all test cases.
}
void CalculatorSubTest::TearDownTestCase(void)
{
// Set a teardown function, which will be called after all test cases.
}
void CalculatorSubTest::SetUp(void)
{
// Set a setup function, which will be called before all test cases.
}
void CalculatorSubTest::TearDown(void)
{
// Set a teardown function, which will be called after all test cases.
}
/**
* @tc.name: integer_sub_001
* @tc.desc: Verify the sub function.
* @tc.type: FUNC
* @tc.require: issueNumber
*/
it("appInfoTest001", 0, function () {
HWTEST_F(CalculatorSubTest, integer_sub_001, TestSize.Level1)
{
// Step 1 Call the function to obtain the test result.
var info = app.getInfo()
int actual = Sub(4, 0);
// Step 2 Use an assertion to compare the obtained result with the expected result.
expect(info != null).assertEqual(true)
})
EXPECT_EQ(4, actual);
}
```
> **NOTE**
>
> @tc.require: The format must be started with **issue**, for example, **issueI56WJ7**.
The procedure is as follows:
1. Add comment information to the test case file header.
```
/*
* Copyright (c) 2023 XXXX Device Co., Ltd.
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
```
2. Add the test framework header file and namespace.
```
#include <gtest/gtest.h>
using namespace testing::ext;
```
3. Add the header file of the test class.
```
#include "calculator.h"
```
4. Define the test suite (test class).
> When defining a test suite, ensure that the test suite name is the same as the target to build and uses the upper camel case style.
```
class CalculatorSubTest : public testing::Test {
public:
static void SetUpTestCase(void);
static void TearDownTestCase(void);
void SetUp();
void TearDown();
};
void CalculatorSubTest::SetUpTestCase(void)
{
// Set a setup function, which will be called before all test cases.
}
void CalculatorSubTest::TearDownTestCase(void)
{
// Set a teardown function, which will be called after all test cases.
}
void CalculatorSubTest::SetUp(void)
{
// Set a setup function, which will be called before all test cases.
}
void CalculatorSubTest::TearDown(void)
{
// Set a teardown function, which will be called after all test cases.
}
```
5. Add implementation of the test cases, including test case comments and logic.
```
/**
* @tc.name: integer_sub_001
* @tc.desc: Verify the sub function.
* @tc.type: FUNC
* @tc.require: issueNumber
*/
HWTEST_F(CalculatorSubTest, integer_sub_001, TestSize.Level1)
{
// Step 1 Call the function to obtain the test result.
int actual = Sub(4, 0);
// Step 2 Use an assertion to compare the obtained result with the expected result.
EXPECT_EQ(4, actual);
}
```
> ![icon-note.gif](/en/device-dev/driver/public_sys-resources/icon-note.gif) **NOTE**
>
> The value of **@tc.require** must start with AR/SR or issue, for example, **issueI56WJ7**.
- The following uses base_object_test.cpp as an example to describe how to compile a multi-thread test case:
```
// The test case file header comment and test case comment are the same as those in the single-thread test case example.
#include "base_object.h"
#include <gtest/gtest.h>
#include <gtest/hwext/gtest-multithread.h>
#include <unistd.h>
using namespace testing::ext;
using namespace testing::mt;
namespace OHOS {
namespace AAFwk {
class AAFwkBaseObjectTest : public testing::Test {......}
// Step 1 Set the function to be tested to return the factorial result.
int factorial(int n)
{
int result = 1;
for (int i = 1; i <= n; i++) {
result *= i;
}
printf("Factorial Function Result : %d! = %d\n", n, result);
return result;
}
// Step 2 Use an assertion to compare the obtained result with the expected result.
void factorial_test()
{
int ret = factorial(3); // Call the function to obtain the result.
std::thread::id this_id = std::this_thread::get_id();
std::ostringstream oss;
oss << this_id;
std::string this_id_str = oss.str();
long int thread_id = atol(this_id_str.c_str());
printf("running thread...: %ld\n", thread_id); // Output the ID of the running thread.
EXPECT_EQ(ret, 6);
}
HWTEST_F(AAFwkBaseObjectTest, Factorial_test_001, TestSize.Level1)
{
SET_THREAD_NUM(4);
printf("Factorial_test_001 BEGIN\n");
GTEST_RUN_TASK(factorial_test);
printf("Factorial_test_001 END\n");
}
HWMTEST_F(AAFwkBaseObjectTest, Factorial_test_002, TestSize.Level1, 6)
{
printf("Factorial_test_002 BEGIN\n");
factorial_test();
printf("Factorial_test_002 END\n");
}
} // namespace AAFwk
} // namespace OHOS
```
The procedure is as follows:
1. Add comment information to the test case file header.
> **NOTE**<br>The standard is the same as that of the single-thread test case.
2. Add the test framework header file and namespace.
```
#include <gtest/gtest.h>
#include <gtest/hwext/gtest-multithread.h>
#include <unistd.h>
using namespace testing::ext;
using namespace testing::mt;
```
3. Add the header file of the test class.
```
#include "base_object.h"
```
4. Define the test suite (test class).
```
class AAFwkBaseObjectTest : public testing::Test {......}
```
> **NOTE**<br>The standard is the same as that of the single-thread test case.
5. Add implementation of the test cases, including test case comments and logic.
```
// Step 1 Set the function to be tested to return the factorial result.
int factorial(int n)
{
int result = 1;
for (int i = 1; i <= n; i++) {
result *= i;
}
printf("Factorial Function Result : %d! = %d\n", n, result);
return result;
}
// Step 2 Use an assertion to compare the obtained result with the expected result.
void factorial_test()
{
int ret = factorial(3); // Call the function to obtain the result.
std::thread::id this_id = std::this_thread::get_id();
std::ostringstream oss;
oss << this_id;
std::string this_id_str = oss.str();
long int thread_id = atol(this_id_str.c_str());
printf("running thread...: %ld\n", thread_id); // Output the ID of the running thread.
EXPECT_EQ(ret, 6);
}
// GTEST_RUN_TASK(TestFunction) is a multi-thread startup function. The parameter is a custom function.
// If SET_THREAD_NUM() is not called, the default value 10 will be used.
HWTEST_F(AAFwkBaseObjectTest, Factorial_test_001, TestSize.Level1)
{
SET_THREAD_NUM(4); // Set the number of threads. It can be dynamically set in the same test suite.
printf("Factorial_test_001 BEGIN\n");
GTEST_RUN_TASK(factorial_test); // Start the multi-thread execution of the factorial_test task.
printf("Factorial_test_001 END\n");
}
// HWMTEST_F(TEST_SUITE, TEST_TC, TEST_LEVEL, THREAD_NUM)
// THREAD_NUM can be used to set the number of threads for executing a test case.
// HWMTEST_F creates a specified number of threads and executes the tested function.
HWMTEST_F(AAFwkBaseObjectTest, Factorial_test_002, TestSize.Level1, 6)
{
printf("Factorial_test_002 BEGIN\n");
factorial_test();
printf("Factorial_test_002 END\n");
}
// Add the multi-thread API MTEST_ADD_TASK(THREAD_ID,ThreadTestFunc). Multiple threads are registered but are not executed in this test case. Instead, they are executed later in a unified manner. This API is applicable to the multi-thread test in the scenario where multiple test cases are combined.
// THREAD_ID is used to distinguish threads and starts from 0. You can also use a random thread ID by passing in RANDOM_THREAD_ID. In this scenario, each thread ID is unique.
// Add the multi-thread API MTEST_POST_RUN() to execute the previously registered threads in a unified manner.
```
> **NOTE**<br>The comments for multi-thread test cases are the same as those of single-thread test cases.
- About C++ test case templates:
The following test case templates are provided for your reference.
| Type| Description|
| ------------| ------------|
| HWTEST(A,B,C)| Use this template if the test case execution does not depend on setup or teardown.|
| HWTEST_F(A,B,C)| Use this template if the test case execution (excluding parameters) depends on setup and teardown.|
| HWMTEST_F(A,B,C,D)| Use this template if the multi-thread test case execution depends on setup and teardown.|
| HWTEST_P(A,B,C)| Use this template if the test case execution (including parameters) depends on setup and teardown.|
In the template names:
- **A** indicates the test suite name.
- **B** indicates the test case name, which is in the *Function*_*No.* format. The *No.* is a three-digit number starting from **001**.
- **C** indicates the test case level. There are five test case levels: guard-control level 0 and non-guard-control level 1 to level 4. Of levels 1 to 4, a smaller value indicates a more important function verified by the test case.
- **D** indicates the number of threads for executing the multi-thread test case.
**Note**:
- The expected result of each test case must have an assertion.
- The test case level must be specified.
- It is recommended that the test be implemented step by step according to the template.
- The test case description is in the standard @tc.*xxx* *value* format. The comment must contain the test case name, description, type, and requirement number. The test case type @tc.type can be any of the following:
| Test Case Type | Code |
| ------------ | -------- |
| Function test | FUNC |
| Performance Test | PERF |
| Reliability test | RELI |
| Security Test | SECU |
| Fuzz test | FUZZ |
**TDD Test (JavaScript)**
- Naming rules for source files
The source file name of a test case must be in the [Function][Sub-function]**Test** format, and each part must use the upper camel case style. More specific sub-functions can be added as required.
Example:
```
AppInfoTest.js
```
- Test case example
```js
/*
* Copyright (C) 2023 XXXX Device Co., Ltd.
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
import app from '@system.app'
import {describe, beforeAll, beforeEach, afterEach, afterAll, it, expect} from 'deccjsunit/index'
describe("AppInfoTest", function () {
beforeAll(function() {
// Set a setup function, which will be called before all test cases.
console.info('beforeAll caled')
})
afterAll(function() {
// Set a teardown function, which will be called after all test cases.
console.info('afterAll caled')
})
beforeEach(function() {
// Set a setup function, which will be called before all test cases.
console.info('beforeEach caled')
})
afterEach(function() {
// Set a teardown function, which will be called after all test cases.
console.info('afterEach caled')
})
/*
* @tc.name:appInfoTest001
* @tc.desc:verify app info is not null
* @tc.type: FUNC
* @tc.require: issueNumber
*/
it("appInfoTest001", 0, function () {
// Step 1 Call the function to obtain the test result.
var info = app.getInfo()
// Step 2 Use an assertion to compare the obtained result with the expected result.
expect(info != null).assertEqual(true)
})
})
```
The procedure is as follows:
1. Add comment information to the test case file header.
```
/*
* Copyright (C) 2023 XXXX Device Co., Ltd.
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
```
2. Import the APIs and JSUnit test library to test.
```js
import app from '@system.app'
import {describe, beforeAll, beforeEach, afterEach, afterAll, it, expect} from 'deccjsunit/index'
```
3. Define the test suite (test class).
```js
describe("AppInfoTest", function () {
beforeAll(function() {
// Set a setup function, which will be called before all test cases.
console.info('beforeAll caled')
})
afterAll(function() {
// Set a teardown function, which will be called after all test cases.
console.info('afterAll caled')
})
beforeEach(function() {
// Set a setup function, which will be called before all test cases.
console.info('beforeEach caled')
})
afterEach(function() {
// Set a teardown function, which will be called after all test cases.
console.info('afterEach caled')
})
```
4. Write test cases
```JS
/*
* @tc.name:appInfoTest001
* @tc.desc:verify app info is not null
* @tc.type: FUNC
* @tc.require: issueNumber
*/
it("appInfoTest001", 0, function () {
// Step 1 Call the function to obtain the test result.
var info = app.getInfo()
// Step 2 Use an assertion to compare the obtained result with the expected result.
expect(info != null).assertEqual(true)
})
```
> ![icon-note.gif](/en/device-dev/driver/public_sys-resources/icon-note.gif) **NOTE**
>
> The value of **@tc.require** must start with AR/SR or issue, for example, **issueI56WJ7**.
**Fuzzing Test**
......@@ -481,325 +613,447 @@ The following provides templates for different languages for your reference.
- **Test case build file example (C++)**
```
# Copyright (c) 2021 XXXX Device Co., Ltd.
import("//build/test.gni")
```
# Copyright (c) 2023 XXXX Device Co., Ltd.
module_output_path = "developertest/calculator"
import("//build/test.gni")
config("module_private_config") {
visibility = [ ":*" ]
module_output_path = "developertest/calculator"
include_dirs = [ "../../../include" ]
}
config("module_private_config") {
visibility = [ ":*" ]
ohos_unittest("CalculatorSubTest") {
module_out_path = module_output_path
include_dirs = [ "../../../include" ]
}
sources = [
"../../../include/calculator.h",
"../../../src/calculator.cpp",
]
ohos_unittest("CalculatorSubTest") {
module_out_path = module_output_path
sources += [ "calculator_sub_test.cpp" ]
sources = [
"../../../include/calculator.h",
"../../../src/calculator.cpp",
]
configs = [ ":module_private_config" ]
sources += [ "calculator_sub_test.cpp" ]
deps = [ "//third_party/googletest:gtest_main" ]
}
configs = [ ":module_private_config" ]
group("unittest") {
testonly = true
deps = [":CalculatorSubTest"]
}
```
The procedure is as follows:
deps = [ "//third_party/googletest:gtest_main" ]
}
1. Add comment information for the file header.
```
# Copyright (c) 2021 XXXX Device Co., Ltd.
```
2. Import the build template.
```
import("//build/test.gni")
```
3. Specify the file output path.
```
module_output_path = "developertest/calculator"
```
> **NOTE**<br>The output path is ***Part name*/*Module name***.
4. Configure the directories for dependencies.
```
config("module_private_config") {
visibility = [ ":*" ]
include_dirs = [ "../../../include" ]
}
```
> **NOTE**
>
> Generally, the dependency directories are configured here and directly referenced in the build script of the test case.
5. Set the output build file for the test cases.
```
ohos_unittest("CalculatorSubTest") {
}
```
6. Write the build script (add the source file, configuration, and dependencies) for the test cases.
```
ohos_unittest("CalculatorSubTest") {
module_out_path = module_output_path
sources = [
"../../../include/calculator.h",
"../../../src/calculator.cpp",
"../../../test/calculator_sub_test.cpp"
]
sources += [ "calculator_sub_test.cpp" ]
configs = [ ":module_private_config" ]
deps = [ "//third_party/googletest:gtest_main" ]
}
```
> **NOTE**
>
> Set the test type based on actual requirements. The following test types are available:
>
> - **ohos_unittest**: unit test
> - **ohos_moduletest**: module test
> - **ohos_systemtest**: system test
> - **ohos_performancetest**: performance test
> - **ohos_securitytest**: security test
> - **ohos_reliabilitytest**: reliability test
> - **ohos_distributedtest**: distributed test
7. Group the test case files by test type.
```
group("unittest") {
testonly = true
deps = [":CalculatorSubTest"]
}
```
> **NOTE**
>
> Grouping test cases by test type allows you to execute a specific type of test cases when required.
group("unittest") {
testonly = true
deps = [":CalculatorSubTest"]
}
```
The procedure is as follows:
1. Add comment information for the file header.
```
# Copyright (c) 2023 XXXX Device Co., Ltd.
```
2. Import the build template.
```
import("//build/test.gni")
```
3. Specify the file output path.
```
module_output_path = "developertest/calculator"
```
> ![icon-note.gif](/en/device-dev/driver/public_sys-resources/icon-note.gif) **NOTE**
>
> The output path is the *Part name*/*Module name*.
4. Configure the directories for dependencies.
```
config("module_private_config") {
visibility = [ ":*" ]
include_dirs = [ "../../../include" ]
}
```
> ![icon-note.gif](/en/device-dev/driver/public_sys-resources/icon-note.gif) **NOTE**
>
> Generally, the dependency directories are configured here and directly referenced in the build script of the test case.
5. Set the output build file for the test cases.
```
ohos_unittest("CalculatorSubTest") {
}
```
6. Write the build script (add the source file, configuration, and dependencies) for the test cases.
```
ohos_unittest("CalculatorSubTest") {
module_out_path = module_output_path
sources = [
"../../../include/calculator.h",
"../../../src/calculator.cpp",
"../../../test/calculator_sub_test.cpp"
]
sources += [ "calculator_sub_test.cpp" ]
configs = [ ":module_private_config" ]
deps = [ "//third_party/googletest:gtest_main" ]
}
```
> ![icon-note.gif](/en/device-dev/driver/public_sys-resources/icon-note.gif) **NOTE**
>
> Set the test type based on actual requirements. The following test types are available:
> - **ohos_unittest**: unit test
> - **ohos_js_unittest**: FA model JS unit test
> - **ohos_js_stage_unittest**: stage model ArkTS unit test
> - **ohos_moduletest**: module test
> - **ohos_systemtest**: system test
> - **ohos_performancetest**: performance test
> - **ohos_securitytest**: security test
> - **ohos_reliabilitytest**: reliability test
> - **ohos_distributedtest**: distributed test
7. Group the test case files by test type.
```
group("unittest") {
testonly = true
deps = [":CalculatorSubTest"]
}
```
> ![icon-note.gif](/en/device-dev/driver/public_sys-resources/icon-note.gif) **NOTE**
>
> Grouping test cases by test type allows you to execute a specific type of test cases when required.
- **Test case build file example (JavaScript)**
```
# Copyright (C) 2021 XXXX Device Co., Ltd.
import("//build/test.gni")
module_output_path = "developertest/app_info"
ohos_js_unittest("GetAppInfoJsTest") {
module_out_path = module_output_path
hap_profile = "./config.json"
certificate_profile = "//test/developertest/signature/openharmony_sx.p7b"
}
group("unittest") {
testonly = true
deps = [ ":GetAppInfoJsTest" ]
}
```
The procedure is as follows:
1. Add comment information for the file header.
```
# Copyright (C) 2021 XXXX Device Co., Ltd.
```
```
# Copyright (C) 2023 XXXX Device Co., Ltd.
2. Import the build template.
import("//build/test.gni")
```
import("//build/test.gni")
```
module_output_path = "developertest/app_info"
3. Specify the file output path.
ohos_js_unittest("GetAppInfoJsTest") {
module_out_path = module_output_path
```
module_output_path = "developertest/app_info"
```
> **NOTE**
>
> The output path is ***Part name*/*Module name***.
hap_profile = "./config.json"
certificate_profile = "//test/developertest/signature/openharmony_sx.p7b"
}
4. Set the output build file for the test cases.
group("unittest") {
testonly = true
deps = [ ":GetAppInfoJsTest" ]
}
```
```
ohos_js_unittest("GetAppInfoJsTest") {
}
```
> **NOTE**
> - Use the **ohos_js_unittest** template to define the JavaScript test suite. Pay attention to the difference between JavaScript and C++.
> - The file generated for the JavaScript test suite must be in .hap format and named after the test suite name defined here. The test suite name must end with **JsTest**.
The procedure is as follows:
1. Add comment information for the file header.
```
# Copyright (C) 2023 XXXX Device Co., Ltd.
```
2. Import the build template.
```
import("//build/test.gni")
```
3. Specify the file output path.
```
module_output_path = "developertest/app_info"
```
> ![icon-note.gif](/en/device-dev/driver/public_sys-resources/icon-note.gif) **NOTE**
>
> The output path is the *Part name*/*Module name*.
4. Set the output build file for the test cases.
```
ohos_js_unittest("GetAppInfoJsTest") {
}
```
> ![icon-note.gif](/en/device-dev/driver/public_sys-resources/icon-note.gif) **NOTE**
>
> - Use the **ohos_js_unittest** template to define the JavaScript test suite. Pay attention to the difference between JavaScript and C++.
> - The file generated for the JavaScript test suite must be in .hap format and named after the test suite name defined here. The test suite name must end with **JsTest**.
5. Configure the **config.json** file and signature file, which are mandatory.
```
ohos_js_unittest("GetAppInfoJsTest") {
module_out_path = module_output_path
hap_profile = "./config.json"
certificate_profile = "//test/developertest/signature/openharmony_sx.p7b"
}
```
**config.json** is the configuration file required for HAP build. You need to set **target** based on the tested SDK version. Default values can be retained for other items. The following is an example:
```json
{
"app": {
"bundleName": "com.example.myapplication",
"vendor": "example",
"version": {
"code": 1,
"name": "1.0"
},
"apiVersion": {
"compatible": 4,
"target": 5 // Set it based on the tested SDK version. In this example, SDK5 is used.
}
},
"deviceConfig": {},
"module": {
"package": "com.example.myapplication",
"name": ".MyApplication",
"deviceType": [
"phone"
],
"distro": {
"deliveryWithInstall": true,
"moduleName": "entry",
"moduleType": "entry"
},
"abilities": [
{
"skills": [
{
"entities": [
"entity.system.home"
],
"actions": [
"action.system.home"
]
}
],
"name": "com.example.myapplication.MainAbility",
"icon": "$media:icon",
"description": "$string:mainability_description",
"label": "MyApplication",
"type": "page",
"launchType": "standard"
}
],
"js": [
{
"pages": [
"pages/index/index"
],
"name": "default",
"window": {
"designWidth": 720,
"autoDesignWidth": false
}
}
]
}
}
```
6. Group the test case files by test type.
```
group("unittest") {
testonly = true
deps = [ ":GetAppInfoJsTest" ]
}
```
> ![icon-note.gif](/en/device-dev/driver/public_sys-resources/icon-note.gif) **NOTE**
>
> Grouping test cases by test type allows you to execute a specific type of test cases when required.
- **Example of ArkTS case compilation configuration for the stage model**
5. Configure the **config.json** file and signature file, which are mandatory.
```
# Copyright (C) 2023 XXXX Device Co., Ltd.
import("//build/test.gni")
```
ohos_js_unittest("GetAppInfoJsTest") {
module_out_path = module_output_path
hap_profile = "./config.json"
certificate_profile = "//test/developertest/signature/openharmony_sx.p7b"
}
```
**config.json** is the configuration file required for HAP build. You need to set **target** based on the tested SDK version. Default values can be retained for other items. The following is an example:
```json
{
"app": {
"bundleName": "com.example.myapplication",
"vendor": "example",
"version": {
"code": 1,
"name": "1.0"
},
"apiVersion": {
"compatible": 4,
"target": 5 // Set it based on the tested SDK version. In this example, SDK5 is used.
want_output_path = "developertest/stage_test"
ohos_js_stage_unittest("ActsBundleMgrStageEtsTest") {
hap_profile = "entry/src/main/module.json"
deps = [
":actbmsstageetstest_js_assets",
":actbmsstageetstest_resources",
]
ets2abc = true
certificate_profile = "signature/openharmony_sx.p7b"
hap_name = "ActsBundleMgrStageEtsTest"
subsystem_name = "developertest"
part_name = "stage_test"
module_out_path = want_output_path
}
},
"deviceConfig": {},
"module": {
"package": "com.example.myapplication",
"name": ".MyApplication",
"deviceType": [
"phone"
],
"distro": {
"deliveryWithInstall": true,
"moduleName": "entry",
"moduleType": "entry"
},
"abilities": [
{
"skills": [
{
"entities": [
"entity.system.home"
],
"actions": [
"action.system.home"
]
}
],
"name": "com.example.myapplication.MainAbility",
"icon": "$media:icon",
"description": "$string:mainability_description",
"label": "MyApplication",
"type": "page",
"launchType": "standard"
}
],
"js": [
{
"pages": [
"pages/index/index"
],
"name": "default",
"window": {
"designWidth": 720,
"autoDesignWidth": false
}
}
]
ohos_app_scope("actbmsstageetstest_app_profile") {
app_profile = "AppScope/app.json"
sources = [ "AppScope/resources" ]
}
}
```
6. Group the test case files by test type.
```
group("unittest") {
testonly = true
deps = [ ":GetAppInfoJsTest" ]
}
```
> **NOTE**
>
> Grouping test cases by test type allows you to execute a specific type of test cases when required.
**Fuzzing Test**
[Fuzzing case specifications](https://gitee.com/openharmony/test_developertest/blob/master/libs/fuzzlib/README_zh.md)
**Benchmark Test**
[Benchmark case specifications](https://gitee.com/openharmony/test_developertest/blob/master/libs/benchmark/README_zh.md)
**Configuring ohos.build**
ohos_js_assets("actbmsstageetstest_js_assets") {
source_dir = "entry/src/main/ets"
}
ohos_resources("actbmsstageetstest_resources") {
sources = [ "entry/src/main/resources" ]
deps = [ ":actbmsstageetstest_app_profile" ]
hap_profile = "entry/src/main/module.json"
}
group("unittest") {
testonly = true
deps = []
deps += [ ":ActsBundleMgrStageEtsTest" ]
}
```
The procedure is as follows:
1. Add comment information for the file header.
```
# Copyright (C) 2023 XXXX Device Co., Ltd.
```
2. Import the build template.
```
import("//build/test.gni")
```
3. Specify the file output path.
```
want_output_path = "developertest/stage_test"
```
> ![icon-note.gif](/en/device-dev/driver/public_sys-resources/icon-note.gif) **NOTE**
>
> The output path is the *Part name*/*Module name*.
4. Set the output build file for the test cases.
```
ohos_js_stage_unittest("ActsBundleMgrStageEtsTest") {
}
```
> ![icon-note.gif](/en/device-dev/driver/public_sys-resources/icon-note.gif) **NOTE**
>
> Use the **ohos_js_stage_unittest** template to define the ArkTS test suite for the stage model.
5. Specify the configuration file **module.json**, signature file, part name, and compilation output path, which are all mandatory.
```
ohos_js_stage_unittest("ActsBundleMgrStageEtsTest") {
hap_profile = "entry/src/main/module.json"
certificate_profile = "signature/openharmony_sx.p7b"
subsystem_name = "developertest"
part_name = "stage_test" // Part name
}
```
6. Specify the configuration resource file (add the source files, configurations, and dependencies).
```
# Declare an AppScope module for the HAP. Those specified by app_profile and sources will be combined to a specific entry file for compilation.
ohos_app_scope("actbmsstageetstest_app_profile") {
app_profile = "AppScope/app.json"
sources = [ "AppScope/resources" ]
}
# Place the test case code for the stage model in the ets directory.
ohos_js_assets("actbmsstageetstest_js_assets") {
source_dir = "entry/src/main/ets"
}
# Source files are stored in the resources directory after compilation in the stage model.
ohos_resources("actbmsstageetstest_resources") {
sources = [ "entry/src/main/resources" ]
deps = [ ":actbmsstageetstest_app_profile" ]
hap_profile = "entry/src/main/module.json"
}
```
7. Group the test case files by test type.
```
group("unittest") {
testonly = true
deps = [ ":GetAppInfoJsTest" ]
}
```
> ![icon-note.gif](/en/device-dev/driver/public_sys-resources/icon-note.gif) **NOTE**
>
> Grouping test cases by test type allows you to execute a specific type of test cases when required.
**Configuring bundle.json**
Configure the part build file to associate with specific test cases.
```
"partA": {
"module_list": [
"build": {
"sub_component": [
"//test/testfwk/developer_test/examples/app_info:app_info",
"//test/testfwk/developer_test/examples/detector:detector",
"//test/testfwk/developer_test/examples/calculator:calculator"
],
"inner_list": [
],
"system_kits": [
{
"header": {
"header_base": "////test/testfwk/developer_test/examples/detector/include",
"header_files": [
"detector.h"
]
},
"name": "//test/testfwk/developer_test/examples/detector:detector"
}
],
"test_list": [ // Test under configuration module calculator.
"//system/subsystem/partA/calculator/test:unittest",
"//system/subsystem/partA/calculator/test:fuzztest",
"//system/subsystem/partA/calculator/test:benchmarktest"
"test": [ // Test under configuration module calculator.
"//test/testfwk/developer_test/examples/app_info/test:unittest",
"//test/testfwk/developer_test/examples/calculator/test:unittest",
"//test/testfwk/developer_test/examples/calculator/test:fuzztest"
}
```
> **NOTE**<br>**test_list** contains the test cases of the corresponding module.
> ![icon-note.gif](/en/device-dev/driver/public_sys-resources/icon-note.gif) **NOTE**
>
> **test_list** contains the test cases of the corresponding module.
## Configuring Test Resources
Test resources include external file resources, such as image files, video files, and third-party libraries, required for test case execution.
The test resources mainly include external file resources such as image files, video files, and third-party libraries required during test case execution. Currently, only static resources can be configured.
Perform the following steps:
1. Create a **resource** directory under the **test** directory of the part, create a corresponding module directory under the **resource** directory, and store the resource files required in this module directory.
1. Create the **resource** directory in the **test** directory of the part, and create a directory for the module in the **resource** directory to store resource files of the module.
2. In the module directory under **resource**, create the **ohos_test.xml** file in the following format:
```xml
<?xml version="1.0" encoding="UTF-8"?>
<configuration ver="2.0">
<target name="CalculatorSubTest">
<preparer>
<option name="push" value="test.jpg -> /data/test/resource" src="res"/>
<option name="push" value="libc++.z.so -> /data/test/resource" src="out"/>
</preparer>
</target>
</configuration>
```
```xml
<?xml version="1.0" encoding="UTF-8"?>
<configuration ver="2.0">
<target name="CalculatorSubTest">
<preparer>
<option name="push" value="test.jpg -> /data/test/resource" src="res"/>
<option name="push" value="libc++.z.so -> /data/test/resource" src="out"/>
</preparer>
</target>
</configuration>
```
3. In the build file of the test cases, configure **resource_config_file** to point to the resource file **ohos_test.xml**.
3. In the build file of the test cases, configure **resource_config_file** to point to the resource file **ohos_test.xml**.
```
ohos_unittest("CalculatorSubTest") {
resource_config_file = "//system/subsystem/partA/test/resource/calculator/ohos_test.xml"
}
```
>**NOTE**
>- **target_name** indicates the test suite name defined in the **BUILD.gn** file in the **test** directory. **preparer** indicates the action to perform before the test suite is executed.
>- **src="res"** indicates that the test resources are in the **resource** directory under the **test** directory. **src="out"** indicates that the test resources are in the **out/release/$(*part*)** directory.
```
ohos_unittest("CalculatorSubTest") {
resource_config_file = "//system/subsystem/partA/test/resource/calculator/ohos_test.xml"
}
```
> ![icon-note.gif](/en/device-dev/driver/public_sys-resources/icon-note.gif) **NOTE**
>
>- **target_name** indicates the test suite name defined in the **BUILD.gn** file in the **test** directory. **preparer** indicates the action to perform before the test suite is executed.
>- **src="res"** indicates that the test resources are in the **resource** directory under the **test** directory. **src="out"** indicates that the test resources are in the **out/release/$(*part*)** directory.
## Test Case Execution
### Configuration File
### Configuration File user_config.xml
Before executing test cases, you need to modify the configuration based on the device used.
Before executing test cases, you need to modify the configuration in **developer_test\config\user_config.xml** based on the device used.
#### Modifying user_config.xml
```xml
<user_config>
<build>
......@@ -849,11 +1103,50 @@ Before executing test cases, you need to modify the configuration based on the d
</NFS>
</user_config>
```
>**NOTE**
>
>If HDC is connected to the device before the test cases are executed, you only need to configure the device IP address and port number, and retain the default settings for other parameters.
> ![icon-note.gif](/en/device-dev/driver/public_sys-resources/icon-note.gif) **NOTE**
>
> If HDC is connected to the device before the test cases are executed, you only need to configure the device IP address and port number, and retain the default settings for other parameters.
### Command Description
### Executing Test Cases on Windows
#### **Test Case Building**
Test cases cannot be built on Windows. You need to run the following command to build test cases on Linux:
```
./build.sh --product-name {product_name} --build-target make_test
```
> ![icon-note.gif](/en/device-dev/driver/public_sys-resources/icon-note.gif) **NOTE**
>
>- **product-name**: specifies the name of the product to be compiled.
>- **build-target**: specifies the test case to build. **make_test** indicates all test cases. You can specify the test cases based on requirements.
When the build is complete, the test cases are automatically saved in **out/ohos-arm-release/packages/phone/tests**.
#### Setting Up the Execution Environment
1. On Windows, create the **Test** directory in the test framework and then create the **testcase** directory in the **Test** directory.
2. Copy **developertest** and **xdevice** from the Linux environment to the **Test** directory on Windows, and copy the test cases to the **testcase** directory.
> ![icon-note.gif](/en/device-dev/driver/public_sys-resources/icon-note.gif) **NOTE**
>
> Port the test framework and test cases from the Linux environment to the Windows environment for subsequent execution.
3. Modify the **user_config.xml** file.
```xml
<build>
<!-- Because the test cases have been built, change the value to false. -->
<testcase>false</testcase>
</build>
<test_cases>
<!-- The test cases are copied to the Windows environment. Change the test case output path to the path of the test cases in the Windows environment.-->
<dir>D:\Test\testcase\tests</dir>
</test_cases>
```
> ![icon-note.gif](/en/device-dev/driver/public_sys-resources/icon-note.gif) **NOTE**
>
> **\<testcase>** indicates whether to build test cases. **\<dir>** indicates the path for searching for test cases.
#### Executing Test Cases
1. Start the test framework.
```
......@@ -865,96 +1158,198 @@ Before executing test cases, you need to modify the configuration based on the d
If you need to manually add a product, add it within the **\<productform\>** tag to **config/framework_config.xml**.
3. Execute test cases.
3. Execute the test cases.
Run the following command to execute test cases:
```
run -t UT -ts CalculatorSubTest -tc interger_sub_00l
```
In the command:
```
-**t [TESTTYPE]**: specifies the test type, which can be **UT**, **MST**, **ST**, **PERF**, **FUZZ**, or **BENCHMARK**. This parameter is mandatory.
-**tp [TESTPART]**: specifies the part to test. This parameter can be used independently.
-**tm [TESTMODULE]**: specifies the module to test. This parameter must be specified together with **-tp**.
-**ts [TESTSUITE]**: specifies a test suite. This parameter can be used independently.
-**tc [TESTCASE]**: specifies a test case. This parameter must be specified together with **-ts**.
-**h**: displays help information.
```
Run the following commands to execute test cases:
```
run -t UT
run -t UT -tp PartName
run -t UT -tp PartName -tm TestModuleName
run -t UT -tp ability_base -ts base_object_test
run -t UT -tp PartName -tm TestModuleName -ts CalculatorSubTest
run -t UT -ts base_object_test
run -t UT -ts base_object_test -tc AAFwkBaseObjectTest.BaseObject_test_001
run -t UT -ts CalculatorSubTest -tc CalculatorSubTest.interger_sub_00l
run -t UT -cov coverage
run -t UT -ra random
run -t UT -ts base_object_test --repeat 5
run -hl
run -rh 3
run --retry
```
#### Executing Test Cases on Windows
In the command:
```
-**t [TESTTYPE]**: specifies the test type, which can be **UT**, **MST**, **ST**, **PERF**, **FUZZ**, **BENCHMARK**, **ACTS**, **HATS**, and more. This parameter is mandatory.
-**tp [TESTPART]**: specifies the part to test. This parameter can be used independently.
-**tm [TESTMODULE]**: specifies the module to test. This parameter must be specified together with **-tp**.
-**ts [TESTSUITE]**: specifies the test suite. This parameter can be used independently.
-**tc [TESTCASE]**: specifies the test case. This parameter must be specified together with **-ts** to indicate the test suite.
-**cov [COVERAGE]**: specifies the coverage.
-**h**: displays help information.
-**ra [random]**: specifies the out-of-order execution for C++ cases.
--**repeat**: specifies the number of case execution times.
-**hl [HISTORYLIST]**: enables the display of the latest 10 test cases. If there are more than 10 test cases, only the latest 10 test cases are displayed.
-**rh [RUNHISTORY]**: specifies the sequence number of the historical record to execute.
--**retry**: checks the last execution result and re-runs the failed test cases, if any.
```
Test cases cannot be built on Windows. You need to run the following command to build test cases on Linux:
```
./build.sh --product-name {product_name} --build-target make_test
```
### Executing Test Cases on Linux
>**NOTE**
>- **product-name**: specifies the name of the product to be compiled.
>- **build-target**: specifies the test case to build. **make_test** indicates all test cases. You can specify the test cases based on requirements.
After the build is complete, the test cases are automatically saved in **out/ohos-arm-release/packages/phone/tests**.
#### Configuring Remote Port Mapping and Modifying Configuration File
To enable test cases to be executed on a remote Linux server or a Linux VM, map the port to enable communication between the device and the remote server or VM. Configure port mapping as follows:
1. On the HDC server, run the following commands:
```
hdc_std kill
hdc_std -m -s 0.0.0.0:8710
```
> ![icon-note.gif](/en/device-dev/driver/public_sys-resources/icon-note.gif) **NOTE**
>
> The IP address and port number are default values.
##### Setting Up the Execution Environment
1. On Windows, create the **Test** directory in the test framework and then create the **testcase** directory in the **Test** directory.
2. On the HDC client, run the following command:
```
hdc_std -s xx.xx.xx.xx:8710 list targets
```
> ![icon-note.gif](/en/device-dev/driver/public_sys-resources/icon-note.gif) **NOTE**
>
> Enter the IP address of the device to test.
2. Copy **developertest** and **xdevice** from the Linux environment to the **Test** directory on Windows, and copy the test cases to the **testcase** directory.
3. Modify the **user_config.xml** file.
```xml
<build>
<!--If a test case needs to be compiled, set this attribute is true. Otherwise, set it to false. -->
<testcase>true</testcase>
</build>
<environment>
<!-- Configure the IP address, port number, and SN of the remote server to support connection to the device through HDC. -->
<device type="usb-hdc">
<ip></ip>
<port></port>
<sn></sn>
</device>
<environment>
```
>**NOTE**
>
>Port the test framework and test cases from the Linux environment to the Windows environment for subsequent execution.
3. Modify the **user_config.xml** file.
```xml
<build>
<!-- Because the test cases have been built, change the value to false. -->
<testcase>false</testcase>
</build>
<test_cases>
<!-- The test cases are copied to the Windows environment. Change the test case output path to the path of the test cases in the Windows environment.-->
<dir>D:\Test\testcase\tests</dir>
</test_cases>
```
>**NOTE**
>
>**\<testcase>** indicates whether to build test cases. **\<dir>** indicates the path for searching for test cases.
#### Executing Test Cases
1. Start the test framework.
```
./start.sh
```
2. Select the product.
#### Executing Test Cases on Linux
After the test framework starts, you are asked to select a product. Select the development board to test.
If you directly connect to a Linux host, you can directly run commands to execute test cases.
If the displayed product list does not contain the target one, you can add it in the **\<productform\>** tag in **config/framework_config.xml**.
##### Mapping the Remote Port
To enable test cases to be executed on a remote Linux server or a Linux VM, map the port to enable communication between the device and the remote server or VM. Configure port mapping as follows:
1. On the HDC server, run the following commands:
```
hdc_std kill
hdc_std -m -s 0.0.0.0:8710
```
>**NOTE**
>
>The IP address and port number are default values.
```
<framework_config>
<productform>
<option name="ipcamera_hispark_aries" />
<option name="ipcamera_hispark_taurus" />
<option name="wifiiot_hispark_pegasus" />
<option name="" />
</productform>
</framework_config>
2. On the HDC client, run the following command:
```
hdc_std -s xx.xx.xx.xx:8710 list targets
```
>**NOTE**
>
>Enter the IP address of the device to test.
```
3. Execute the test cases.
1. TDD commands
The test framework locates the test cases based on the command, and automatically builds and executes the test cases.
```
run -t UT
run -t UT -tp PartName
run -t UT -tp PartName -tm TestModuleName
run -t UT -tp ability_base -ts base_object_test
run -t UT -tp PartName -tm TestModuleName -ts CalculatorSubTest
run -t UT -ts base_object_test
run -t UT -ts base_object_test -tc AAFwkBaseObjectTest.BaseObject_test_001
run -t UT -ts CalculatorSubTest -tc CalculatorSubTest.interger_sub_00l
run -t -cov coverage
run -t UT -ra random
run -t UT -tp PartName -pd partdeps
run -t UT -ts base_object_test --repeat 5
run -hl
run -rh 3
run --retry
```
In the command:
```
-**t [TESTTYPE]**: specifies the test type, which can be **UT**, **MST**, **ST**, **PERF**, **FUZZ**, and **BENCHMARK**. This parameter is mandatory.
-**tp [TESTPART]**: specifies the part to test. This parameter can be used independently.
-**tm [TESTMODULE]**: specifies the module to test. This parameter must be specified together with **-tp**.
-**ts [TESTSUITE]**: specifies the test suite. This parameter can be used independently.
-**tc [TESTCASE]**: specifies the test case. This parameter must be specified together with **-ts** to indicate the test suite.
-**cov [COVERAGE]**: specifies the coverage.
-**h**: displays help information.
-**ra [random]**: specifies the out-of-order execution for C++ cases.
-**pd [partdeps]**: specifies execution parameter of the level-2 part dependencies.
--**repeat**: specifies the number of case execution times.
-**hl [HISTORYLIST]**: enables the display of the latest 10 test cases. If there are more than 10 test cases, only the latest 10 test cases are displayed.
-**rh [RUNHISTORY]**: specifies the sequence number of the historical record to execute.
--**retry**: checks the last execution result and re-runs the failed test cases, if any.
```
In Linux, you can run the following commands to view the supported product forms, test types, subsystems, and parts.
```
To view the help information, run **help**.
To view the **show** command, run **help show**.
To view the supported product forms, run **show productlist**.
To view the supported test types, run **show typelist**.
To view the supported test subsystems, run **show subsystemlist** .
To view the supported test parts, run **show partlist**.
```
2. ACTS/HATS commands
After selecting the product, you can refer to the following to execute the ACTS or HATS test cases.
```
run -t ACTS
run -t HATS
run -t ACTS -ss arkui
run -t ACTS -ss arkui, modulemanager
run -t ACTS -ss arkui -ts ActsAceEtsTest
run -t HATS -ss telephony -ts HatsHdfV1RilServiceTest
run -t ACTS -ss arkui -tp ActsPartName
run -t ACTS -ss arkui -ts ActsAceEtsTest,ActsAceEtsResultTest
run -t HATS -ss powermgr -ts HatsPowermgrBatteryTest,HatsPowermgrThermalTest
run -t ACTS -ss arkui -ts ActsAceEtsTest -ta class:alphabetIndexerTest#alphabetIndexerTest001
run -t ACTS -ss arkui -ts ActsAceEtsTest -ta class:alphabetIndexerTest#alphabetIndexerTest001 --repeat 2
run -hl
run -rh 1
run --retry
```
The parameters in the ACTS and HATS commands are the same, but are different from those in TDD commands.
```
-**t [TESTTYPE]**: specifies the test case type, which can be **ACTS** or **HATS**. This parameter is mandatory.
-**ss [SUBSYSTEM]**: specifies the subsystem to test. This parameter can be used independently. To specify multiple subsystems, separate them with commas (,).
-**tp [TESTPART]**: specifies the part to test. This parameter can be used independently.
-**ts [TESTSUITE]**: specifies the test suite. This parameter can be used independently. To specify multiple test suites, separate them with commas (,).
-**ta [TESTARGS]**: specifies the test method. This parameter must be used together with **-ts**.
--**repeat**: specifies the number of case execution times.
-**hl [HISTORYLIST]**: enables the display of the latest 10 test cases. If there are more than 10 test cases, only the latest 10 test cases are displayed.
-**rh [RUNHISTORY]**: specifies the sequence number of the historical record to execute.
--**retry**: checks the last execution result and re-runs the failed test cases, if any.
```
## Viewing the Test Result
### Test Report Logs
After the test cases are executed, the test result will be automatically generated. You can view the detailed test result in the related directory.
After the test is executed, the console automatically generates the test result.
### Test Result
You can obtain the test result in the following directory:
```
test/developertest/reports/xxxx_xx_xx_xx_xx_xx
```
>**NOTE**
>
>The folder for test reports is automatically generated.
> ![icon-note.gif](/en/device-dev/driver/public_sys-resources/icon-note.gif) **NOTE**
>
> The test report folder is automatically generated.
The folder contains the following files:
| Type | Description |
......@@ -964,12 +1359,54 @@ The folder contains the following files:
| summary_report.html | Test report summary. |
| details_report.html | Detailed test report. |
### Test Framework Logs
```
reports/platform_log_xxxx_xx_xx_xx_xx_xx.log
```
### Latest Test Report
```
reports/latest
```
## Executing Coverage Cases
When GCDA data is available, you can execute the test cases as follows for subsystems to generate a coverage report:
1. (Optional) To block redundant branch data generated by non-core code, run the following command in the **/test/testfwk/developer_test/localCoverage/restore_comment** directory before source code compilation:
python3 build_before_generate.py
Run the following command to select the parts to be blocked during compilation:
run -tp partname
run -tp partname1 partname2
2. Before compiling the version, modify the compilation options. Add **-- coverage** to the **cflags**, **cflags_cc**, and **ldflags** options in the **build.gn** file of the involved subsystem.
ldflags = [ "--coverage" ]
C: cflags = [ "--coverage" ]
C++: cflags_cc = [ "--coverage" ]
**Recommended**: You can also refer to the mode for the window subsystem. For details, see the files in this [pull request](https://gitee.com/openharmony/window_window_manager/pulls/1274/files).
3. To execute coverage test cases, perform the following to install the dependencies:
1. Run the **sudo apt install lcov** command to install lcov.
2. Run the **apt install dos2unix** command to install dos2unix.
3. Run the **pip install lxml** command to install lxml.
4. Run the **pip install selectolax** command to install selectolax.
5. Run the **pip install CppHeaderParser** command to install CppHeaderParser.
4. To map a remote device, set its IP address in the **usr_config.xml** file. For details about device mapping, see [Configuring Remote Port Mapping and Modifying Configuration File](#configuring-remote-port-mapping-and-modifying-configuration-file).
<!-- Set the IP address of the remote host to map (IP address of the PC to which the device is mounted).-->
<device type="usb-hdc">
<ip></ip>
<port></port>
<sn></sn>
</device>
5. Run the **./start.sh** command. Below are examples:
run -t UT -tp *Part name* -cov coverage
run -t UT -ss *Subsystem name* -cov coverage
run -t UT -ss *Subsystem name* -tp **Part name** -cov coverage
run -t UT MST ST -tp *Part name* -cov coverage
Note: The **-cov coverage** parameter must be added to the preceding commands.
6. Obtain the coverage report from the following paths:
Code coverage report: **/test/testfwk/developer_test/localCoverage/codeCoverage/results/coverage/reports/cxx/html**
API coverage report: **/test/testfwk/developer_test/localCoverage/interfaceCoverage/results/coverage/interface_kits/html**
en/release-notes/changelogs/OpenHarmony_4.0.8.2/changelogs-arkui.md
浏览文件 @ 56e3961f
......@@ -97,3 +97,117 @@ N/A
When building a child component, do not assign values to the variables by **@LocalStorageLink** and **@LocalStorageProp** in the child component.
To change these variables from the parent component, use the API provided by the **LocalStorage** (such as the **set** API) to assign values to them.
## cl.arkui.3 Change of the bottom Definition in Toast Options in the PromptAction Module
Changed the definition of the **bottom** attribute in toast options from distance between the top of the toast and the bottom of the screen to distance between the bottom of the toast and the bottom of the screen.
**Example**
```ts
import promptAction from '@ohos.promptAction';
@Entry
@Component
struct Index {
build() {
Row() {
Button()
.onClick(() => {
try {
promptAction.showToast({
message: 'Message Info',
duration: 2000
});
} catch (error) {
console.error(`showToast args error code is ${error.code}, message is ${error.message}`);
};
})
}
}
}
```
**Change Impacts**
In the **PromptAction** module, the same value for the **bottom** attribute may result in different toast appearances, depending on whether the API version used by the compiler is earlier than 10 or not.
**Key API/Component Changes**
N/A
**Adaptation Guide**
When setting the **bottom** attribute, account for the definition change.
## cl.arkui.4 Content Layout Change of AlertDialog
The content layout of the alert dialog box varies according to the following conditions: 1. whether there is a title. 2. whether the text is on a single line.
Currently, only the single-line text without a title is centered. In other cases, the text is left-aligned.
**Example**
```ts
// xxx.ets
@Entry
@Component
struct AlertDialogExample {
build() {
Column({ space: 5 }) {
Button('one button dialog')
.onClick(() => {
AlertDialog.show(
{
title: 'title',
message: 'text'.repeat(20),
autoCancel: true,
alignment: DialogAlignment.Bottom,
offset: { dx: 0, dy: -20 },
gridCount: 3,
confirm: {
value: 'button',
action: () => {
console.info('Button-clicking callback')
}
},
cancel: () => {
console.info('Closed callbacks')
}
}
)
})
.backgroundColor(0x317aff)
}.width('100%').margin({ top: 5 })
}
}
```
**Change Impacts**
The layout for the text specified by the **message** attribute of the alert dialog box is subject to the title and number of lines of the text.
**Key API/Component Changes**
N/A
**Adaptation Guide**
No proactive adaptation is required. You can also use **customDialog** for related implementation.
## cl.arkui.5 Avoidance Behavior Optimization of Popup
Before the change, the popup preferentially uses the lower area for avoidance. As a result, it cannot be displayed in the upper area even if the space is sufficient.
After the change: The popup preferentially uses the upper area for avoidance when it is configured to show above the target component; it preferentially uses the upper or lower area for avoidance when it is configured to show below the target component.
**Change Impacts**
The optimized popup avoidance behavior occurs when the **bindpopup** attribute is used.
**Key API/Component Changes**
N/A
**Adaptation Guide**
If the popup position is not as expected, you can adjust the **placement** settings.
Markdown is supported
0% 或 .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑！
想要评论请 注册 或