The test-driven development mode is used during the development process. You can develop new cases or modify existing cases to test new or enhanced system features. The self-test helps you develop high-quality code in the development phase.
The test-driven development mode is used during the development process. You can develop new cases or modify existing cases to test new or enhanced system features. The test helps you develop high-quality code in the development phase.
<tdclass="cellrowborder"valign="top"width="66.12%"headers="mcps1.2.3.1.2 "><pid="p879375920132"><aname="p879375920132"></a><aname="p879375920132"></a>Development test framework</p>
<tdclass="cellrowborder"valign="top"width="66.12%"headers="mcps1.2.3.1.2 "><pid="p194133051713"><aname="p194133051713"></a><aname="p194133051713"></a>Developer test entry (Windows)</p>
<tdclass="cellrowborder"valign="top"width="66.12%"headers="mcps1.2.3.1.2 "><pid="p86419276175"><aname="p86419276175"></a><aname="p86419276175"></a>Developer test entry (Linux)</p>
</td>
</tr>
</tbody>
...
...
@@ -136,7 +136,7 @@ Install the serial port plugins **pyserial** and **readline** on the local P
## Compiling Test Cases<a name="section125411936102918"></a>
-Self-test case specifications
-Test case specifications
- Naming rules
The source file name of the test case must be consistent with the test suite content. The relationship between the test suite and the test case is 1:N and the test suite and the test source file is 1:1. Each source file is globally unique and named in the format of \[Feature\]\_\[Function\]\_\[Subfunction 1\]\_\[Subfunction 1.1\]. Subfunctions can be further divided.
...
...
@@ -145,18 +145,18 @@ Install the serial port plugins **pyserial** and **readline** on the local P
- Test case coding specifications
The self-test cases must comply with the feature code coding specifications. In addition, necessary case description information must be added. For details, see [\#li2069415903917](#li2069415903917).
The test cases must comply with the feature code coding specifications. In addition, necessary case description information must be added. For details, see [\#li2069415903917](#li2069415903917).
- Test case compilation and configuration specifications
The test cases are compiled in GN mode. The configuration must comply with the compilation guide of the open source project. For details, see [en-us\_topic\_0000001051580775.md](en-us_topic_0000001051580775.md).
-<aname="li2069415903917"></a>Self-test case template
-<aname="li2069415903917"></a>Test case template
For details, see the test case **demo** developertest/example/cxx\_demo/test/unittest/common/calc\_subtraction\_test.cpp.
>The LiteOS and Linux are used as examples only for different device models. For the same feature on different development boards, if the test cases are the same, they are stored in the **common** directory. For the same feature, if the test cases are used to distinguish different device models and may include kernel differences and chip platform differences, the test cases are distinguished by directory.
- Procedure for compiling self-test cases
1. Add the comment information of the case header file.
- Procedure for compiling test cases
1. Add comments to the test case header file.
2. Reference the **gtest** header file and **ext** namespace.
3. Add the header file to test.
4. Define test suites \(test classes\).
5. Implement specific test cases of the test suite, including test case comments and logic implementation.
6. Compile the test case compilation configuration.
## Using Test Framework<a name="section75882026185016"></a>
...
...
@@ -292,7 +292,7 @@ Install the serial port plugins **pyserial** and **readline** on the local P
```
- Check the environment before executing the self-test cases.
- Check the environment before executing the test cases.
- The system image and file system have been burnt to a development board and are running properly on the development board. In system mode, for example, the device prompt **OHOS\#** is displayed during shell login.
- The development host is properly connected to the serial port of the development board, and the development host is properly connected to the serial port of the development board.
- The IP addresses of the development host and development board are in the same network segment and can ping each other.
...
...
@@ -318,25 +318,29 @@ Install the serial port plugins **pyserial** and **readline** on the local P
Configure device models based on the actual development board, for example, **developertest/src/core/resource/config/framework\_config.xml**.
- Run the test command.
1. The following example shows how to run the test command. **-t ut** is mandatory, and **-ss** and **-tm** are optional.
1. To query the subsystems, modules, product forms, and test types supported by test cases, run the **show** command.
```
usage:
show productlist Querying Supported Product Forms
show typelist Querying the Supported Test Type
show subsystemlist Querying Supported Subsystems
show modulelist Querying Supported Modules
```
2. The following example shows how to run the test command. **-t** is mandatory, and **-ss** and **-tm** are optional.
```
run -t ut -ss test -tm example
```
2. Specify the parameters that can be used to execute the test suite corresponding to a specific feature or module.
3. Specify the parameters that can be used to execute the test suite corresponding to a specific feature or module.
