> **NOTE**<br>Test cases are classified into common test cases and device-specific test cases. You are advised to place common test cases in the **common** directory and device-specific test cases in the directories of the related devices.
> **NOTE**
>
> Test cases are classified into common test cases and device-specific test cases. You are advised to place common test cases in the **common** directory and device-specific test cases in the directories of the related devices.
### Writing Test Cases
### Writing Test Cases
This test framework supports test cases written in multiple programming languages and provides different templates for different languages.
This test framework supports test cases written in multiple programming languages and provides different templates for different languages.
...
@@ -111,7 +113,7 @@ Example:
...
@@ -111,7 +113,7 @@ Example:
/**
/**
* @tc.name: integer_sub_001
* @tc.name: integer_sub_001
* @tc.desc: Verify the sub-function.
* @tc.desc: Verify the subfunction.
* @tc.type: FUNC
* @tc.type: FUNC
* @tc.require: Issue Number
* @tc.require: Issue Number
*/
*/
...
@@ -119,7 +121,7 @@ Example:
...
@@ -119,7 +121,7 @@ Example:
{
{
// Step 1 Call the function to obtain the result.
// Step 1 Call the function to obtain the result.
int actual = Sub(4, 0);
int actual = Sub(4, 0);
// Step 2 Use an assertion to compare the obtained result with the expected result.
// Step 2 Use an assertion to compare the obtained result with the expected result.
EXPECT_EQ(4, actual);
EXPECT_EQ(4, actual);
}
}
...
@@ -130,49 +132,57 @@ Example:
...
@@ -130,49 +132,57 @@ Example:
Enter the header comment in the standard format. For details, see [Code Specifications](https://gitee.com/openharmony/docs/blob/master/en/contribute/code-contribution.md).
Enter the header comment in the standard format. For details, see [Code Specifications](https://gitee.com/openharmony/docs/blob/master/en/contribute/code-contribution.md).
2. Add the test framework header file and namespace.
2. Add the test framework header file and namespace.
```
#include <gtest/gtest.h>
```
#include <gtest/gtest.h>
using namespace testing::ext;
```
using namespace testing::ext;
```
3. Add the header file of the test class.
3. Add the header file of the test class.
```
#include "calculator.h"
```
```
#include "calculator.h"
```
4. Define the test suite (test class).
4. Define the test suite (test class).
```
```
class CalculatorSubTest : public testing::Test {
class CalculatorSubTest : public testing::Test {
public:
public:
static void SetUpTestCase(void);
static void SetUpTestCase(void);
static void TearDownTestCase(void);
static void TearDownTestCase(void);
void SetUp();
void SetUp();
void TearDown();
void TearDown();
};
};
void CalculatorSubTest::SetUpTestCase(void)
void CalculatorSubTest::SetUpTestCase(void)
{
{
// Set a setup function, which will be called before all test cases.
// input testsuit setup step，setup invoked before all testcases
}
}
void CalculatorSubTest::TearDownTestCase(void)
void CalculatorSubTest::TearDownTestCase(void)
{
{
// Set a teardown function, which will be called after all test cases.
// input testsuit teardown step，teardown invoked after all testcases
}
}
void CalculatorSubTest::SetUp(void)
void CalculatorSubTest::SetUp(void)
{
{
// Set a setup function, which will be called before each test case.
// input testcase setup step，setup invoked before each testcases
}
}
void CalculatorSubTest::TearDown(void)
{
// input testcase teardown step，teardown invoked after each testcases
}
```
> **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.
void CalculatorSubTest::TearDown(void)
{
// Set a teardown function, which will be called after each test case.
}
```
> **NOTE**<br>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.
5. Add implementation of the test cases, including test case comments and logic.
| HWTEST(A,B,C)| Use this template if the test case execution does not depend on setup or teardown.|
| 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.|
| HWTEST_F(A,B,C) | Use this template if the test case execution (excluding parameters) 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.|
| HWTEST_P(A,B,C) | Use this template if the test case execution (including parameters) depends on setup and teardown. |
In the template names:
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**.
- *A* indicates the test suite name.
- *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.
- *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**<br>
- The expected result of each test case must have an assertion.
> **NOTE**
- The test case level must be specified.
>
- It is recommended that the test be implemented step by step according to the template.
> - The expected result of each test case must have an assertion.
- The comment must contain the test case name, description, type, and requirement number, which are in the @tc.*xxx*: *value* format. The test case description must be in the @tc.xxx format. The test case type @tc.type can be any of the following:
> - The test case level must be specified.
> - It is recommended that the test be implemented step by step according to the template.
| Test Case Type|Code|
> - The comment must contain the test case name, description, type, and requirement number, which are in the @tc.*xxx*: *value* format.The test case description must be in the @tc.xxx format. The test case type @tc.type can be any of the following:
| ------------|------------|
|Function test |FUNC|
| Test Case Type | Code |
|Performance test |PERF|
| ---------------- | ---- |
|Reliability test |RELI|
| Function test | FUNC |
|Security test |SECU|
| Performance test | PERF |
|Fuzz test |FUZZ|
| Reliability test | RELI |
| Security test | SECU |
| Fuzz test | FUZZ |
#### JavaScript Test Case Example
#### JavaScript Test Case Example
- Naming rules for source files
- 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.
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:
Example:
```
```
AppInfoTest.js
AppInfoTest.js
```
```
...
@@ -262,7 +276,7 @@ Example:
...
@@ -262,7 +276,7 @@ Example:
it("appInfoTest001", 0, function () {
it("appInfoTest001", 0, function () {
// Step 1 Call the function to obtain the test result.
// Step 1 Call the function to obtain the test result.
var info = app.getInfo()
var info = app.getInfo()
// Step 2 Use an assertion to compare the obtained result with the expected result.
// Step 2 Use an assertion to compare the obtained result with the expected result.
expect(info != null).assertEqual(true)
expect(info != null).assertEqual(true)
})
})
...
@@ -276,7 +290,7 @@ Example:
...
@@ -276,7 +290,7 @@ Example:
2. Import the APIs and JSUnit test library to test.
2. Import the APIs and JSUnit test library to test.
```
```
import app from '@system.app'
import app from '@system.app'
import {describe, beforeAll, beforeEach, afterEach, afterAll, it, expect} from 'deccjsunit/index'
import {describe, beforeAll, beforeEach, afterEach, afterAll, it, expect} from 'deccjsunit/index'
```
```
3. Define the test suite (test class).
3. Define the test suite (test class).
...
@@ -313,7 +327,7 @@ Example:
...
@@ -313,7 +327,7 @@ Example:
it("appInfoTest001", 0, function () {
it("appInfoTest001", 0, function () {
// Step 1 Call the function to obtain the test result.
// Step 1 Call the function to obtain the test result.
var info = app.getInfo()
var info = app.getInfo()
// Step 2 Use an assertion to compare the obtained result with the expected result.
// Step 2 Use an assertion to compare the obtained result with the expected result.
expect(info != null).assertEqual(true)
expect(info != null).assertEqual(true)
})
})
...
@@ -326,7 +340,7 @@ When a test case is executed, the test framework searches for the build file of
...
@@ -326,7 +340,7 @@ When a test case is executed, the test framework searches for the build file of
The following provides templates for different languages for your reference.
The following provides templates for different languages for your reference.
-**Test case build file example (C++)**
-**Test case build file example (C++)**
```
```c++
import("//build/test.gni")
import("//build/test.gni")
...
@@ -365,70 +379,90 @@ The following provides templates for different languages for your reference.
...
@@ -365,70 +379,90 @@ The following provides templates for different languages for your reference.
Enter the header comment in the standard format. For details, see [Code Specifications](https://gitee.com/openharmony/docs/blob/master/en/contribute/code-contribution.md).
Enter the header comment in the standard format. For details, see [Code Specifications](https://gitee.com/openharmony/docs/blob/master/en/contribute/code-contribution.md).
> **NOTE**<br>The output path is ***Part name*/*Module name***.
```
> **NOTE**
>
> The output path is ***Part name*/*Module name***.
4. Configure the directories for dependencies.
4. Configure the directories for dependencies.
```
```
config("module_private_config") {
config("module_private_config") {
visibility = [ ":*" ]
visibility = [ ":*" ]
include_dirs = [ "../../../include" ]
include_dirs = [ "../../../include" ]
}
}
```
```
> **NOTE**<br>Generally, the dependency directories are configured here and directly referenced in the build script of the test case.
> **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.
5. Set the output build file for the test cases.
```
```
ohos_unittest("CalculatorSubTest") {
ohos_unittest("CalculatorSubTest") {
}
}
```
```
6. Write the build script (add the source file, configuration, and dependencies) for the test cases.
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**<br>Set the test type based on actual requirements. The following test types are available:
```
>
ohos_unittest("CalculatorSubTest") {
> - **ohos_unittest**: unit test
module_out_path = module_output_path
> - **ohos_moduletest**: module test
sources = [
> - **ohos_systemtest**: system test
"../../../include/calculator.h",
> - **ohos_performancetest**: performance test
"../../../src/calculator.cpp",
> - **ohos_securitytest**: security test
"../../../test/calculator_sub_test.cpp"
> - **ohos_reliabilitytest**: reliability test
]
> - **ohos_distributedtest**: distributed test
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.
7. Group the test case files by test type.
```
```
group("unittest") {
group("unittest") {
testonly = true
testonly = true
deps = [":CalculatorSubTest"]
deps = [":CalculatorSubTest"]
}
}
```
```
> **NOTE**<br>Grouping test cases by test type allows you to execute a specific type of test cases when required.
> **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)**
-**Test case build file example (JavaScript)**
```
```javascript
import("//build/test.gni")
import("//build/test.gni")
...
@@ -448,32 +482,39 @@ The following provides templates for different languages for your reference.
...
@@ -448,32 +482,39 @@ The following provides templates for different languages for your reference.
```
```
The procedure is as follows:
The procedure is as follows:
1. Add comment information for the file header.
1. Add comment information for the file header.
Enter the header comment in the standard format. For details, see [Code Specifications](https://gitee.com/openharmony/docs/blob/master/en/contribute/code-contribution.md).
Enter the header comment in the standard format. For details, see [Code Specifications](https://gitee.com/openharmony/docs/blob/master/en/contribute/code-contribution.md).
> **NOTE**<br>The output path is ***Part name*/*Module name***.
> **NOTE**
>
> The output path is ***Part name*/*Module name***.
4. Set the output build file for the test cases.
4. Set the output build file for the test cases.
```
```
ohos_js_unittest("GetAppInfoJsTest") {
ohos_js_unittest("GetAppInfoJsTest") {
}
}
```
```
> **NOTE**<br>
>- Use the **ohos\_js\_unittest** template to define the JavaScript test suite. Pay attention to the difference between JavaScript and C++.
> **NOTE**
>- 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**.
>
> - 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.
5. Configure the **config.json** file and signature file, which are mandatory.
...
@@ -485,7 +526,7 @@ The following provides templates for different languages for your reference.
...
@@ -485,7 +526,7 @@ The following provides templates for different languages for your reference.
**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:
**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:
```
```
{
{
...
@@ -530,7 +571,7 @@ The following provides templates for different languages for your reference.
...
@@ -530,7 +571,7 @@ The following provides templates for different languages for your reference.
"description": "$string:mainability_description",
"description": "$string:mainability_description",
"label": "MyApplication",
"label": "MyApplication",
"type": "page",
"type": "page",
"launchType": "standard"
"launchType": "multiton"
}
}
],
],
"js": [
"js": [
...
@@ -555,8 +596,10 @@ The following provides templates for different languages for your reference.
...
@@ -555,8 +596,10 @@ The following provides templates for different languages for your reference.
deps = [ ":GetAppInfoJsTest" ]
deps = [ ":GetAppInfoJsTest" ]
}
}
```
```
> **NOTE**<br>Grouping test cases by test type allows you to execute a specific type of test cases when required.
> **NOTE**
>
> Grouping test cases by test type allows you to execute a specific type of test cases when required.
#### Configuring ohos.build
#### Configuring ohos.build
Configure the part build file to associate with specific test cases.
Configure the part build file to associate with specific test cases.
...
@@ -576,7 +619,9 @@ Configure the part build file to associate with specific test cases.
...
@@ -576,7 +619,9 @@ Configure the part build file to associate with specific test cases.
]
]
}
}
```
```
> **NOTE**<br>**test_list** contains the test cases of the corresponding module.
> **NOTE**
>
> **test_list** contains the test cases of the corresponding module.
### Configuring Test Case Resources
### Configuring Test Case Resources
Test case resources include external file resources, such as image files, video files, and third-party libraries, required for test case execution.
Test case resources include external file resources, such as image files, video files, and third-party libraries, required for test case execution.
>- **target_name** indicates the test suite name defined in the **BUILD.gn** file in the **test** directory.
>
>- **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.
>- **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="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.
>- **src="out"** indicates that the test resources are in the **out/release/$(*part*)** directory.
...
@@ -657,7 +703,9 @@ Before executing test cases, you need to modify the configuration based on the d
...
@@ -657,7 +703,9 @@ Before executing test cases, you need to modify the configuration based on the d
</NFS>
</NFS>
</user_config>
</user_config>
```
```
>**NOTE**<br>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.
>**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.
### Executing Test Cases on Windows
### Executing Test Cases on Windows
#### Building Test Cases
#### Building Test Cases
...
@@ -668,17 +716,21 @@ Test cases cannot be built on Windows. You need to run the following command to
...
@@ -668,17 +716,21 @@ Test cases cannot be built on Windows. You need to run the following command to
```
```
When the build is complete, the test cases are automatically saved in **out/hispark_taurus/packages/phone/images/tests**.
When the build is complete, the test cases are automatically saved in **out/hispark_taurus/packages/phone/images/tests**.
>**NOTE**<br>In the command, **hispark_taurus_standard** indicates the product supported by the current version, and **make_test** indicates all test cases. You can set the build options based on requirements:<br>
>**NOTE**
> - --**product-name**: specifies the name of the product to build. It is mandatory.
>
> - --**build-target**: specifies the target to build. It is optional.
>In the command, **hispark_taurus_standard** indicates the product supported by the current version, and **make_test** indicates all test cases. You can set the build options based on requirements:
>
>- --**product-name**: specifies the name of the product to build. It is mandatory.
>- --**build-target**: specifies the target to build. It is optional.
#### Setting Up the Execution Environment
#### 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.
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.
2. Copy **developertest** and **xdevice** from the Linux environment to the **Test** directory on Windows, and copy the test cases to the **testcase** directory.
>**NOTE**<br>Port the test framework and test cases from the Linux environment to the Windows environment for subsequent execution.
> **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.
3. Modify the **user_config.xml** file.
```
```
<build>
<build>
...
@@ -690,7 +742,9 @@ When the build is complete, the test cases are automatically saved in **out/hisp
...
@@ -690,7 +742,9 @@ When the build is complete, the test cases are automatically saved in **out/hisp
<dir>D:\Test\testcase\tests</dir>
<dir>D:\Test\testcase\tests</dir>
</test_cases>
</test_cases>
```
```
>**NOTE**<br>`<testcase>` indicates whether to build test cases. `<dir>` indicates the path for searching for test cases.
>**NOTE**
>
>`<testcase>` indicates whether to build test cases. `<dir>` indicates the path for searching for test cases.
#### Executing Test Cases
#### Executing Test Cases
1. Start the test framework.
1. Start the test framework.
...
@@ -714,7 +768,7 @@ When the build is complete, the test cases are automatically saved in **out/hisp
...
@@ -714,7 +768,7 @@ When the build is complete, the test cases are automatically saved in **out/hisp
-tm [TESTMODULE]: specifies the module to test. This parameter must be used together with -tp.
-tm [TESTMODULE]: specifies the module to test. This parameter must be used together with -tp.
-ts [TESTSUITE]: specifies a test suite. This parameter can be used independently.
-ts [TESTSUITE]: specifies a test suite. This parameter can be used independently.
-tc [TESTCASE]: specifies a test case. This parameter must be used together with -ts.
-tc [TESTCASE]: specifies a test case. This parameter must be used together with -ts.
You can run -h to display help information.
You can run h to display help information.
```
```
### Executing Test Cases on Linux
### Executing Test Cases on Linux
#### Mapping the Remote Port
#### Mapping the Remote Port
...
@@ -724,13 +778,16 @@ To enable test cases to be executed on a remote Linux server or a Linux VM, map
...
@@ -724,13 +778,16 @@ To enable test cases to be executed on a remote Linux server or a Linux VM, map
hdc_std kill
hdc_std kill
hdc_std -m -s 0.0.0.0:8710
hdc_std -m -s 0.0.0.0:8710
```
```
>**NOTE**<br>The IP address and port number are default values.
>**NOTE**
>
>The IP address and port number are default values.
2. On the HDC client, run the following command:
2. On the HDC client, run the following command:
```
```
hdc_std -s xx.xx.xx.xx:8710 list targets
hdc_std -s xx.xx.xx.xx:8710 list targets
```
```
>**NOTE**<br>Enter the IP address of the device to test.
>**NOTE**
>
>Enter the IP address of the device to test.
#### Executing Test Cases
#### Executing Test Cases
1. Start the test framework.
1. Start the test framework.
...
@@ -745,7 +802,7 @@ To enable test cases to be executed on a remote Linux server or a Linux VM, map
...
@@ -745,7 +802,7 @@ To enable test cases to be executed on a remote Linux server or a Linux VM, map
The test framework locates the test cases based on the command, and automatically builds and executes the test cases.
The test framework locates the test cases based on the command, and automatically builds and executes the test cases.
```
```
run -t UT -ts CalculatorSubTest -tc integer_sub_00l
run -t UT -ts CalculatorSubTest -tc interger_sub_00l
```
```
In the command:
In the command:
```
```
...
@@ -765,7 +822,9 @@ You can obtain the test result in the following directory:
...
@@ -765,7 +822,9 @@ You can obtain the test result in the following directory:
```
```
test/developertest/reports/xxxx_xx_xx_xx_xx_xx
test/developertest/reports/xxxx_xx_xx_xx_xx_xx
```
```
>**NOTE**<br>The folder for test reports is automatically generated.
>**NOTE**
>
>The folder for test reports is automatically generated.
