|Version|Ubuntu 18.04 or later|libreadline-dev|3.7.5 or later|pyserial 3.3 or later, paramiko 2.7.1 or later, setuptools 40.8.0 or later, and rsa4.0 or later|haneWIN NFS Server 1.2.50 or later, or NFS v4 or later| 1.1.0 or later|
|Description|Provides code build environment.|Plug-in used to read commands.|Language used by the test framework.|pyserial: 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.|Enables devices to be connected through the serial port.| A tool that enables devices to be connected through the HarmonyOS Device Connector (HDC).|
## Installation Process
1. Run the following command to install the Linux extended component libreadline:
```
sudo apt-get install libreadline-dev
```
The installation is successful if the following information is displayed:
```
Reading package lists... Done
Building dependency tree
Reading state information... Done
libreadline-dev is already the newest version (7.0-3).
0 upgraded, 0 newly installed, 0 to remove and 11 not upgraded.
```
2. Run the following command to install the setuptools plug-in:
```
pip3 install setuptools
```
The installation is successful if the following information is displayed:
```
Requirement already satisfied: setuptools in d:\programs\python37\lib\site-packages (41.2.0)
```
3. Run the following command to install the paramiko plug-in:
```
pip3 install paramiko
```
The installation is successful if the following information is displayed:
| Check whether Python is installed successfully.|Run the **python --version** command.|The Python version is 3.7.5 or later.|
| Check whether Python plug-ins are successfully installed.|Go to the **test/developertest** directory and run **run.bat** or **run.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.|
OpenHarmony provides a comprehensive auto-test framework for designing test cases. Detecting defects in the development process can improve code quality.
-[Overview](#section12403172115920)
-[Basic Concepts](#section53632272090)
This document describes how to use the OpenHarmony test framework.
-[Working Principles](#section2394431106)
## Setting Up the Environment
The test framework depends on the Python running environment. Before using the test framework, set up the environment as follows:
-[Limitations and Constraints](#section2029921310472)
-[Setting Up the Environment](subsys-testguide-envbuild.md)
-[Setting Up a Test Environment](#section175012297491)
│ ├── BUILD.gn # Build entry of the test framework
│ ├── start.bat # Test entry for Windows
The testing subsystem provides a one-click Python-based self-test platform for developers. It supports cross-platform tests and extension to third-party testing frameworks. The subsystem consists of modules for compiling, managing, scheduling and distributing, and executing test cases, collecting test results, generating test reports, creating test case templates, managing test environments, and many others.
│ └── start.sh # Test entry for Linux
└── xdevice # Modules on which the test framework depends
Before development using the testing subsystem, you need to understand the following concepts:
```
## Writing Test Cases
- Test case compilation
### Designing the Test Case Directory
Design the test case directory as follows:
This operation compiles the source code of test cases into binary files that can be executed on the tested device.
```
subsystem # Subsystem
- Test case scheduling & distributing
├── partA # Part A
│ ├── moduleA # Module A
This operation distributes test cases to different tested devices through the network port or serial port, and allocates a specific executor for each test case.
│ │ ├── include
│ │ ├── src # Service code
- Test case executor
│ │ └── test # Test directory
│ │ ├── unittest # Unit test
A test case executor defines the execution logic of each test case, such as its pre-processing, execution, and result recording.
│ │ │ ├── common # Common test cases
│ │ │ │ ├── BUILD.gn # Build file of test cases
- Test case template
│ │ │ │ ├── testA_test.cpp # Source code of unit test cases
│ │ │ ├── phone # Test cases for mobile phones
A test case template defines respective unified formats for test cases and for GN files.
│ │ │ ├── ivi # Test cases for head units
│ │ │ └── liteos-a # Test cases for the IP cameras that use the LiteOS kernel
- Test platform kits
│ │ └── resource # Dependency resources
│ │ └── ohos_test.xml
The test platform provides common methods to be used during the running of the test tool, for example, providing the test case directory to mount the file system to a tested device, distributing test cases to the tested device, or obtaining test results from the tested device.
│ ├── moduleB # Module B
│ ├── test
- Test report generation
│ │ └── moduletest # Module test
│ │ ├── common
This operation defines a template for generating self-test reports and web test reports.
│ │ ├── phone
│ │ ├── ivi
- Test environment management
│ │ └── liteos-a
│ │ ...
The tested devices can be managed through the USB port or serial port, including discovering a device and querying the device status.
│ └── ohos_build # Build entry configuration
...
```
### Working Principles<a name="section2394431106"></a>
> **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.
- The following figure shows the architecture of the test platform.
### Writing Test Cases
This test framework supports test cases written in multiple programming languages and provides different templates for different languages.
- The following figure shows the running sequence diagram of the test platform.
- Naming rules for source files
**Figure 2** Running sequence of the test platform<aname="fig107203017407"></a>
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 test platform is started using a shell script. It executes a series of testing commands entered on the command line interface \(CLI\) and prints the command output.
- Test case example
## Limitations and Constraints<a name="section2029921310472"></a>
- The self-test platform supports only code-level test case development and verification, such as unit testing and module testing.
- Currently, the testing framework supports only white-box testing.
- Only one test platform can be started on a testing device.
## Setting Up a Test Environment<a name="section175012297491"></a>
<tdclass="cellrowborder"valign="top"width="33.33333333333333%"headers="mcps1.2.4.1.2 "><aname="ul19802171518438"></a><aname="ul19802171518438"></a><ulid="ul19802171518438"><li>Memory: 8 GB or above</li><li>Hard disk space: 100 GB or above</li><li>Hardware architecture: x86 or ARM64</li></ul>
</td>
<tdclass="cellrowborder"valign="top"width="33.33333333333333%"headers="mcps1.2.4.1.3 "><aname="ul56772753313"></a><aname="ul56772753313"></a><ulid="ul56772753313"><li>Hi3516D V300 development board</li><li>Hi3518E V300 development board</li></ul>
<tdclass="cellrowborder"valign="top"width="33.33333333333333%"headers="mcps1.2.4.1.2 "><aname="ul16677122216594"></a><aname="ul16677122216594"></a><ulid="ul16677122216594"><li>OS: Windows 10 (64-bit) or Ubuntu 18.04<pid="p717443952718"><aname="p717443952718"></a><aname="p717443952718"></a>System component (Linux): libreadline-dev</p>
</li><li>Python: 3.7.5 or later</li><li>Python plug-ins: pySerial 3.3 or later, Paramiko 2.7.1 or later, Setuptools 40.8.0 or later, and RSA 4.0 or later</li><li>NFS server: haneWIN NFS Server 1.2.50 or later, or NFSv4 or later</li></ul>
</td>
<tdclass="cellrowborder"valign="top"width="33.33333333333333%"headers="mcps1.2.4.1.3 "><aname="ul20976824133414"></a><aname="ul20976824133414"></a><ulid="ul20976824133414"><li>OS: OpenHarmony 1.0 or later</li><li>Kernel: LiteOS Cortex-A or Linux kernel</li></ul>
</td>
</tr>
</tbody>
</table>
### Installing the Environment<a name="section6511193210111"></a>
1.\(Optional\) If the test environment runs Linux, run the following command to install system component Readline:
```
sudo apt-get install libreadline-dev
```
If the installation is successful, the following prompts are displayed:
```
Reading package lists... Done
Building dependency tree
Reading state information... Done
libreadline-dev is already the newest version (7.0-3).
0 upgraded, 0 newly installed, 0 to remove and 11 not upgraded.
```
2. Install Python extension plug-ins Setuptools. Install RSA, Paramiko, and pySerial if the device supports the serial port only.
1. Run the following command to install Setuptools:
```
pip install setuptools
```
If the installation is successful, the following prompts are displayed:
```
Requirement already satisfied: setuptools in d:\programs\python37\lib\site-packages (41.2.0)
```
2. Run the following command to install RSA:
```
pip install rsa
```
If the installation is successful, the following prompts are displayed:
```
Installing collected packages: pyasn1, rsa
Successfully installed pyasn1-0.4.8 rsa-4.7
```
3. Run the following command to install Paramiko:
```
pip install paramiko
```
If the installation is successful, the following prompts are displayed:
4. \(Optional\) Run the following command to install pySerial. This step is mandatory for tested devices that support serial ports only.
```
pip install pyserial
```
If the installation is successful, the following prompts are displayed:
```
Requirement already satisfied: pyserial in d:\programs\python37\lib\site-packages\pyserial-3.4-py3.7.egg (3.4)
```
3.\(Optional\) Install the NFS server. This step is mandatory for tested devices that support serial ports only.
**Windows OS**
Download and install **haneWIN NFS Server 1.2.50** at https://www.hanewin.net/nfs-e.htm.
**Linux OS**
```
sudo apt install nfs-kernel-server
```
After the environment is installed, you can conduct coding and debugging for a test platform in an integrated development environment \(IDE\) \(DevEco Studio is recommended\).
### Verifying the Test Environment<a name="section1899144517117"></a>
<tbody><trid="row567731662216"><tdclass="cellrowborder"valign="top"width="33.33333333333333%"headers="mcps1.2.4.1.1 "><pid="p1667711613224"><aname="p1667711613224"></a><aname="p1667711613224"></a>Check that a compliant Python version has been installed.</p>
</td>
<tdclass="cellrowborder"valign="top"width="33.33333333333333%"headers="mcps1.2.4.1.2 "><pid="p16678101614220"><aname="p16678101614220"></a><aname="p16678101614220"></a>Run the <strongid="b7670932632"><aname="b7670932632"></a><aname="b7670932632"></a>python --version</strong> command.</p>
</td>
<tdclass="cellrowborder"valign="top"width="33.33333333333333%"headers="mcps1.2.4.1.3 "><pid="p6554216134112"><aname="p6554216134112"></a><aname="p6554216134112"></a>The Python version must be 3.7.5 or later.</p>
</td>
</tr>
<trid="row559954144717"><tdclass="cellrowborder"valign="top"width="33.33333333333333%"headers="mcps1.2.4.1.1 "><pid="p1259195419474"><aname="p1259195419474"></a><aname="p1259195419474"></a>Check that Python extension plug-ins have been installed.</p>
</td>
<tdclass="cellrowborder"valign="top"width="33.33333333333333%"headers="mcps1.2.4.1.2 "><pid="p175925424714"><aname="p175925424714"></a><aname="p175925424714"></a>Access the <strongid="b35031935731"><aname="b35031935731"></a><aname="b35031935731"></a>test/xdevice</strong> directory and run <strongid="b155070352317"><aname="b155070352317"></a><aname="b155070352317"></a>run.bat</strong> or <strongid="b5507935931"><aname="b5507935931"></a><aname="b5507935931"></a>run.sh</strong>.</p>
</td>
<tdclass="cellrowborder"valign="top"width="33.33333333333333%"headers="mcps1.2.4.1.3 "><pid="p1040211281418"><aname="p1040211281418"></a><aname="p1040211281418"></a>The <strongid="b82085361632"><aname="b82085361632"></a><aname="b82085361632"></a>>>></strong> prompt is displayed.</p>
</td>
</tr>
<trid="row66781016182213"><tdclass="cellrowborder"valign="top"width="33.33333333333333%"headers="mcps1.2.4.1.1 "><pid="p8678416132217"><aname="p8678416132217"></a><aname="p8678416132217"></a>Check that the NFS server has been started (for tested devices that support serial ports only).</p>
</td>
<tdclass="cellrowborder"valign="top"width="33.33333333333333%"headers="mcps1.2.4.1.2 "><pid="p56781416142210"><aname="p56781416142210"></a><aname="p56781416142210"></a>Log in to the development board through the serial port and run the <strongid="b194410371631"><aname="b194410371631"></a><aname="b194410371631"></a>mount</strong> command to mount the NFS server.</p>
</td>
<tdclass="cellrowborder"valign="top"width="33.33333333333333%"headers="mcps1.2.4.1.3 "><pid="p27475710414"><aname="p27475710414"></a><aname="p27475710414"></a>The file directory can be mounted properly.</p>
</td>
</tr>
</tbody>
</table>
## Development Guidelines<a name="section16741101301210"></a>
### When to Use<a name="section93782214124"></a>
You can call the APIs to conduct white box tests of service code.
### Available APIs<a name="section54131732101218"></a>
The testing framework integrates the open-source unit testing framework and expands the macros of the test cases. For details about the framework, see the official open-source documentation.
<tdclass="cellrowborder"valign="top"width="88.59%"headers="mcps1.2.3.1.2 "><pid="p2248120191418"><aname="p2248120191418"></a><aname="p2248120191418"></a>The execution of test cases does not rely on setup and teardown execution. Based on the <strongid="b112735719267"><aname="b112735719267"></a><aname="b112735719267"></a>TEST</strong> macro, this macro has added the <strongid="b443291902514"><aname="b443291902514"></a><aname="b443291902514"></a>TestSize.Level1</strong> parameter to specify the test case level, for example, <strongid="b154975135291"><aname="b154975135291"></a><aname="b154975135291"></a>HWTEST(CalculatorAddTest, TestPoint_001, TestSize.Level1)</strong>.</p>
<tdclass="cellrowborder"valign="top"width="88.59%"headers="mcps1.2.3.1.2 "><pid="p17248132061412"><aname="p17248132061412"></a><aname="p17248132061412"></a>The execution of test cases (without parameters) depends on setup and teardown execution. Based on the <strongid="b112055810312"><aname="b112055810312"></a><aname="b112055810312"></a>TEST_F</strong> macro, this macro has added the <strongid="b421113883115"><aname="b421113883115"></a><aname="b421113883115"></a>TestSize.Level1</strong> parameter to specify the test case level, for example, <strongid="b921114813118"><aname="b921114813118"></a><aname="b921114813118"></a>HWTEST_F(CalculatorAddTest, TestPoint_001, TestSize.Level1)</strong>.</p>
<tdclass="cellrowborder"valign="top"width="88.59%"headers="mcps1.2.3.1.2 "><pid="p1248142031417"><aname="p1248142031417"></a><aname="p1248142031417"></a>The execution of test cases (with parameters) depends on setup and teardown execution. Based on the <strongid="b1196952353418"><aname="b1196952353418"></a><aname="b1196952353418"></a>TEST_P</strong> macro, this macro has added the <strongid="b197642314343"><aname="b197642314343"></a><aname="b197642314343"></a>TestSize.Level1</strong> parameter to specify the test case level, for example, <strongid="b59797231348"><aname="b59797231348"></a><aname="b59797231348"></a>HWTEST_P(CalculatorAddTest, TestPoint_001, TestSize.Level1)</strong>.</p>
</td>
</tr>
</tbody>
</table>
### How to Develop<a name="section53541946111218"></a>
1. Define a test suite file based on the test case directory, for example, **test/developertest/examples/lite/cxx\_demo/test/unittest/common/calc\_subtraction\_test.cpp**. The class in this test suite should be inherited from the **testing::Test** class and named in the format of "_Tested feature_\_**Test**".
```
```
/*
/*
* Copyright (c) 2020 OpenHarmony.
* Copyright (c) 2021 XXXX Device Co., Ltd.
* Licensed under the Apache License, Version 2.0 (the "License");
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
* You may obtain a copy of the License at
...
@@ -289,692 +87,749 @@ The testing framework integrates the open-source unit testing framework and expa
...
@@ -289,692 +87,749 @@ The testing framework integrates the open-source unit testing framework and expa
* See the License for the specific language governing permissions and
* See the License for the specific language governing permissions and
* limitations under the License.
* limitations under the License.
*/
*/
#include "calculator.h"
#include <gtest/gtest.h>
#include <gtest/gtest.h>
using namespace std;
using namespace testing::ext;
using namespace testing::ext;
class CalcSubtractionTest : public testing::Test {
>You must write test cases by observing the following specifications:
>- Naming
> The source file name of a test case must be consistent with the test suite content. Each test suite has multiple test cases and a test source file that is globally unique and named in \[Feature\]\_\[Function\]\_\[Subfunction 1\]\_\[Subfunction 1.1\] format \(subfunctions can be further divided\).
> The file name can contain only lower-case letters and underscores \(\_\) and must end with **test**, for example, **developertest/examples/lite/cxx\_demo**.
>- Coding
> The test cases must comply with the coding specifications for feature code. In addition, case descriptions are required for further clarification. For details, see [Test case template](#li2069415903917).
>- Compilation and configuration
> The test cases must be compiled using GN, and the configurations must comply with the compilation guide of this open-source project. For details, see [Compilation and Building Subsystem - Lightweight and Small-Scale Systems](subsys-build-mini-lite.md).
>- <a name="li2069415903917"></a>Test case template
> For details, see the example test case **developertest/examples/lite/cxx\_demo/test/unittest/common/calc\_subtraction\_test.cpp**.
2. Implement the preprocessing \(via the **SetUp** function\) and postprocessing \(via the **TearDown** function\) operations required by the execution of the test suite.
```
void CalcSubtractionTest::SetUpTestCase(void)
{
{
// step 1: input testsuite setup step
// Set a setup function, which will be called before all test cases.
}
}
void CalcSubtractionTest::TearDownTestCase(void)
void CalculatorSubTest::TearDownTestCase(void)
{
{
// step 2: input testsuite teardown step
// Set a teardown function, which will be called after all test cases.
}
}
void CalcSubtractionTest::SetUp(void)
void CalculatorSubTest::SetUp(void)
{
{
// step 3: input testcase setup step
// Set a setup function, which will be called before each test case.
}
}
void CalcSubtractionTest::TearDown(void)
void CalculatorSubTest::TearDown(void)
{
{
// step 4: input testcase teardown step
// Set a teardown function, which will be called after each test case.
}
}
```
3. Compile a test case based on the feature to be tested. The following code uses **HWTEST\_F** as an example:
<td class="cellrowborder" valign="top" width="45.51%" headers="mcps1.1.5.1.4 "><p id="p1332554310018"><a name="p1332554310018"></a><a name="p1332554310018"></a>Verifies that each functionality of the software complies with the function design and specifications.</p>
<td class="cellrowborder" valign="top" width="45.51%" headers="mcps1.1.5.1.4 "><p id="p133261343301"><a name="p133261343301"></a><a name="p133261343301"></a>Verifies that the software complies with security requirements and related laws and regulations within the software lifecycle.</p>
<td class="cellrowborder" valign="top" width="45.51%" headers="mcps1.1.5.1.4 "><p id="p103261243906"><a name="p103261243906"></a><a name="p103261243906"></a>Verifies the probability that the software does not cause system failures within a specified period of time and under given conditions. Software stability is also involved in the test.</p>
</td>
</tr>
</tbody>
</table>
4. Compile the GN file of the test case, including defining the compilation target, adding compilation dependencies, and setting the source file.
Example file path: **test/developertest/examples/lite/cxx\_demo/test/unittest/common/BUILD.gn**
```
import("//build/lite/config/test.gni")
unittest("CalcSubTest") {
output_extension = "bin"
sources = [
"calc_subtraction_test.cpp"
]
include_dirs = []
deps = []
}
}
```
```
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.
```
#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).
```
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 each test case.
}
void CalculatorSubTest::TearDown(void)
{
// Set a teardown function, which will be called after each test case.
}
```
> **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.
// 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 following test case templates are provided for your reference.
| Template| 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.|
| 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.
**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. The test case description must be in the @tc.xxx format. The test case type @tc.type can be any of the following:
| Test Case Type|Function test|Performance test|Reliability test|Security test|Fuzz test|
5. Add the compilation target to the subsystem compilation configuration to ensure that the test case is compiled with the version distribution. The following is an example:
**JavaScript Test Case Example**
1. For devices that support connection to the Harmony device connector \(hdc\), the example compilation configuration directory is **test/developertest/examples/ohos.build**.
>The resource file is used to push the **test.txt** file in the **resource** directory to the **/data/test/resource** directory of the device to test. To do so, run the **hdc push** command.
7. Execute the test case after it is compiled \(the preceding steps are complete\).
>- For devices that support connection to the hdc, test cases can be compiled separately.
>- For devices that support serial ports only, to compile the test case, run the commands in the root directory for compiling the debug code.
> For details about how to execute a test case, see [How to Use the Test Platform](#section76401945124810).
## Development Example<a name="section7477121918136"></a>
The code repository of the testing subsystem provides complete demo cases, which are available in the **test/developertest/examples/** directory. The following is an example of compiling a test case for a subtraction function:
- The tested code is as follows:
-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:
```
```
static int Subtraction(int a, int b)
AppInfoTest.js
{
return a - b;
}
```
```
- The test case code is as follows:
- Test case example
```
```
/**
/*
* @tc.name: integer_sub_002
* Copyright (C) 2021 XXXX Device Co., Ltd.
* @tc.desc: Verify the Subtraction function.
* Licensed under the Apache License, Version 2.0 (the "License");
* @tc.type: FUNC
* you may not use this file except in compliance with the License.
* @tc.require: AR00000000 SR00000000
* 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
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 each test case.
console.info('beforeEach caled')
})
afterEach(function() {
// Set a teardown function, which will be called after each test case.
console.info('afterEach caled')
})
/*
* @tc.name:appInfoTest001
* @tc.desc:verify app info is not null
* @tc.type: FUNC
* @tc.require: Issue Number
*/
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) 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. Import the APIs and JSUnit test library to test.
```
import app from '@system.app'
import {describe, beforeAll, beforeEach, afterEach, afterAll, it, expect} from 'deccjsunit/index'
```
3. Define the test suite (test class).
```
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 each test case.
console.info('beforeEach caled')
})
afterEach(function() {
// Set a teardown function, which will be called after each test case.
console.info('afterEach caled')
})
```
4. Add implementation of the test cases.
```
/*
* @tc.name:appInfoTest001
* @tc.desc:verify app info is not null
* @tc.type: FUNC
* @tc.require: Issue Number
*/
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)
})
```
### Writing the Build File for Test Cases
When a test case is executed, the test framework searches for the build file of the test case in the test case directory and builds the test case located. The following describes how to write build files (GN files) in different programming languages.
#### Writing Build Files for Test Cases
The following provides templates for different languages for your reference.
>**example**: whether to build the test case example. The default value is **false**.
>**version**: whether to build the test version. The default value is **false**.
>**testcase**: whether to build the test case. The default value is **true**.
2. For devices that support connection to the hdc, modify the configuration file as follows:
Between the **device** tags with the **"usb-hdc"** attribute, modify the IP address of the device and the port number matching the HDC connection. For example:
```
<device type="usb-hdc">
<ip>192.168.1.1</ip>
<port>9111</port>
<sn></sn>
</device>
```
3. For devices that support serial ports only, modify the configuration file as follows:
\[board\_info\] \# Configure development board information.
>**board\_series**: development board series. The default value is **hispark**.
>**board\_type**: development board type. The default value is **taurus**.
>**board\_product**: target product. The default value is **ipcamera**.
>**build\_command**: command used for building the test version and test case. The default value is **hb build**.
Between the **device** tags with the **"ipcamera"** attribute, modify the serial port information, including the COM port and baud rate. For example:
```
<device type="com" label="ipcamera">
<serial>
<com>COM1</com>
<type>cmd</type>
<baud_rate>115200</baud_rate>
<data_bits>8</data_bits>
<stop_bits>1</stop_bits>
<timeout>1</timeout>
</serial>
</device>
```
3.\(Optional\) Modify the Developertest configuration. If a test case has been compiled, specify the compilation output path of the test case. In this case the test platform will not recompile the test case.
Modify the **config/user\_config.xml** file.
1. Specify the output path of the test case, that is, the compilation output directory between the **test\_cases** tags. Example:
```
<test_cases>
<dir>/home/opencode/out/release/tests</dir>
</test_cases>
```
2. For devices that support serial ports only, specify the NFS directory on the PC \(**host\_dir**\) and the corresponding directory on the board \(**board\_dir**\) between the **NFS** tags. For example:
```
<NFS>
<host_dir>D:\nfs</host_dir>
<board_dir>user</board_dir>
</NFS>
```
4.\(Optional\) Prepare the test environment. If devices to be tested support only serial ports, check whether the environment is ready:
- The system image and file system have been burnt into the development board and are running properly on it. For example, in system mode, if the device prompt **OHOS\#** when you log in with the shell, the system is running properly.
- The development host has been connected to the serial port of the development board and the network port.
- IP addresses of the development host and development board are in the same network segment and can ping each other.
- An empty directory has been created on the development host for mounting test cases through NFS, and the NFS service has been started properly.
5. Start the test platform and execute the test case.
- Start the test framework, go to the **test/developertest** directory, and execute the startup script.
1. Run the following command to start the test framework in Windows:
```
start.bat
```
2. Run the following command to start the test framework in Linux:
```
./start.sh
```
- Select a device type.
Configure the device type based on the development board in the configuration file, for example, **developertest/config/framework\_config.xml**.
1. Add comment information for the file header.
- Run test commands.
```
1. To query the subsystems, modules, product form, and test types supported by test cases, run the **show** commands.
# Copyright (C) 2021 XXXX Device Co., Ltd.
```
```
2. Import the build template.
Usage:
show productlist Query supported product forms
```
show typelist Query the supported test type
import("//build/test.gni")
show subsystemlist Query supported subsystems
```
show modulelist Query supported modules
3. Specify the file output path.
```
```
2. Run test commands. **-t** is mandatory, and **-ss** and **-tm** are optional. The following is an example:
> **Note**: The output path is ***Part name*/*Module name***.
run -t ut -ss subsystem_examples -tm calculator
```
4. Set the output build file for the test cases.
3. Specify the arguments to execute the test suite for a specific feature or module.
```
ohos_js_unittest("GetAppInfoJsTest") {
```
}
usage: run [-h] [-p PRODUCTFORM] [-t [TESTTYPE [TESTTYPE ...]]]
```
[-ss SUBSYSTEM] [-tm TESTMODULE] [-ts TESTSUIT]
> **Note:**
[-tc TESTCASE] [-tl TESTLEVEL]
>- 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**.
Optional arguments:
-h, --help Show this help message and exit.
5. Configure the **config.json** file and signature file, which are mandatory.
-p PRODUCTFORM, --productform PRODUCTFORM Specified product form
-tl TESTLEVEL, --testlevel TESTLEVEL Specify test level
}
```
```
**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:
- View the test framework help if needed.
```
Run the following command query test commands that are supported by the test platform:
{
"app": {
```
"bundleName": "com.example.myapplication",
help
"vendor": "example",
```
"version": {
"code": 1,
- Exit the test platform.
"name": "1.0"
},
Run the following command to exit the test platform:
"apiVersion": {
"compatible": 4,
```
"target": 5 // Set it based on the tested SDK version. In this example, SDK5 is used.
quit
}
```
},
"deviceConfig": {},
6. View the test result and logs. The test logs and reports are generated in the **developertest/reports** directory after you run the test commands.
"module": {
- The test result is displayed on the console. The root path of the test result is as follows:
"package": "com.example.myapplication",
"name": ".MyApplication",
```
"deviceType": [
reports/xxxx-xx-xx-xx-xx-xx
"phone"
```
],
"distro": {
- The test case formatting result is stored in the following directory:
"deliveryWithInstall": true,
"moduleName": "entry",
```
"moduleType": "entry"
result/
},
```
"abilities": [
{
- The test logs are stored in the following directory:
"skills": [
{
```
"entities": [
log/plan_log_xxxx-xx-xx-xx-xx-xx.log
"entity.system.home"
```
],
"actions": [
- The report summary file is as follows:
"action.system.home"
]
```
}
summary_report.html
],
```
"name": "com.example.myapplication.MainAbility",
"icon": "$media:icon",
- The report details file is as follows:
"description": "$string:mainability_description",
"label": "MyApplication",
```
"type": "page",
details_report.html
"launchType": "standard"
```
}
],
- The log directory of the test platform is as follows:
> **Note**: Grouping test cases by test type allows you to execute a specific type of test cases when required.
<tdclass="cellrowborder"valign="top"width="54.949999999999996%"headers="mcps1.2.3.1.2 "><pid="p05459441212"><aname="p05459441212"></a><aname="p05459441212"></a>Basic components of the test platform</p>
Configure the part build file to associate with specific test cases.
</td>
```
<tdclass="cellrowborder"valign="top"width="54.949999999999996%"headers="mcps1.2.3.1.2 "><pid="p105453448111"><aname="p105453448111"></a><aname="p105453448111"></a>Source code for the basic test framework</p>
<tdclass="cellrowborder"valign="top"width="54.949999999999996%"headers="mcps1.2.3.1.2 "><pid="p1575512093811"><aname="p1575512093811"></a><aname="p1575512093811"></a>Configuration file of the basic test framework</p>
<tdclass="cellrowborder"valign="top"width="54.949999999999996%"headers="mcps1.2.3.1.2 "><pid="p10650320204819"><aname="p10650320204819"></a><aname="p10650320204819"></a>Internal entrance to the basic test framework</p>
"test_list": [
</td>
"//system/subsystem/partA/calculator/test:unittest" // Configure test under calculator.
<tdclass="cellrowborder"valign="top"width="54.949999999999996%"headers="mcps1.2.3.1.2 "><pid="p1986519338482"><aname="p1986519338482"></a><aname="p1986519338482"></a>Package and plug-in dependencies</p>
> **Note**: **test_list** contains the test cases of the corresponding module.
2. In the **resource** directory, create the **ohos_test.xml** file in the following format:
</td>
```
<tdclass="cellrowborder"valign="top"width="54.949999999999996%"headers="mcps1.2.3.1.2 "><pid="p1937319561140"><aname="p1937319561140"></a><aname="p1937319561140"></a>Commands input by test cases</p>
<tdclass="cellrowborder"valign="top"width="54.949999999999996%"headers="mcps1.2.3.1.2 "><pid="p1986220312212"><aname="p1986220312212"></a><aname="p1986220312212"></a>Configuration management of the basic test framework</p>
<tdclass="cellrowborder"valign="top"width="54.949999999999996%"headers="mcps1.2.3.1.2 "><pid="p164783210154"><aname="p164783210154"></a><aname="p164783210154"></a>Environment management of the basic test framework, including device management</p>
3. In the build file of the test cases, configure **resource\_config\_file** to point to the resource file **ohos\_test.xml**.
<tdclass="cellrowborder"valign="top"width="54.949999999999996%"headers="mcps1.2.3.1.2 "><pid="p1316918254269"><aname="p1316918254269"></a><aname="p1316918254269"></a>Scheduling and distribution of test cases</p>
```
</td>
>**Note:**
</tr>
>- **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.
</td>
>- **src="res"** indicates that the test resources are in the **resource** directory under the **test** directory.
<tdclass="cellrowborder"valign="top"width="54.949999999999996%"headers="mcps1.2.3.1.2 "><pid="p10750101062710"><aname="p10750101062710"></a><aname="p10750101062710"></a>Test executor for the basic test framework</p>
>- **src="out"** indicates that the test resources are in the **out/release/$(component)** directory.
</td>
## Executing Test Cases
</tr>
Before executing test cases, you need to modify the configuration based on the device used.
<tdclass="cellrowborder"valign="top"width="54.949999999999996%"headers="mcps1.2.3.1.2 "><pid="p15651746155911"><aname="p15651746155911"></a><aname="p15651746155911"></a>Resource files and test report templates for the basic test framework</p>
<!-- Whether to build a demo case. The default value is false. If a demo case is required, change the value to true. -->
</td>
<example>false</example>
<tdclass="cellrowborder"valign="top"width="54.949999999999996%"headers="mcps1.2.3.1.2 "><pid="p784795762120"><aname="p784795762120"></a><aname="p784795762120"></a>Common operations for the basic test framework, including NFS mounting</p>
<!-- Whether to build the version. The default value is false. -->
</td>
<version>false</version>
</tr>
<!-- Whether to build the test cases. The default value is true. If the build is already complete, change the value to false before executing the test cases.-->
<tdclass="cellrowborder"valign="top"width="54.949999999999996%"headers="mcps1.2.3.1.2 "><pid="p92110017395"><aname="p92110017395"></a><aname="p92110017395"></a>Log management of the basic test framework</p>
<environment>
</td>
<!-- Configure the IP address and port number of the remote server to support connection to the device through the HarmonyOS Device Connector (HDC).-->
<tdclass="cellrowborder"valign="top"width="54.949999999999996%"headers="mcps1.2.3.1.2 "><pid="p1944991024013"><aname="p1944991024013"></a><aname="p1944991024013"></a>Plug-in management of the basic test framework</p>
<sn></sn>
</td>
</device>
</tr>
<!-- Configure the serial port information of the device to enable connection through the serial port.-->
<tdclass="cellrowborder"valign="top"width="54.949999999999996%"headers="mcps1.2.3.1.2 "><pid="p158571940184016"><aname="p158571940184016"></a><aname="p158571940184016"></a>Interfaces for plug-ins of the basic test framework</p>
<tdclass="cellrowborder"valign="top"width="54.949999999999996%"headers="mcps1.2.3.1.2 "><pid="p44193353819"><aname="p44193353819"></a><aname="p44193353819"></a>Installation script of the basic test framework</p>
<!-- Configure the test case path. If the test cases have not been built (<testcase> is true), leave this parameter blank. If the build is complete, enter the path of the test cases.-->
<tdclass="cellrowborder"valign="top"width="54.949999999999996%"headers="mcps1.2.3.1.2 "><pid="p4371153172812"><aname="p4371153172812"></a><aname="p4371153172812"></a>Startup script of the basic test framework (Windows)</p>
<tdclass="cellrowborder"valign="top"width="54.949999999999996%"headers="mcps1.2.3.1.2 "><pid="p165453953218"><aname="p165453953218"></a><aname="p165453953218"></a>Startup script of the basic test framework (Linux)</p>
<outpath></outpath>
</td>
</coverage>
</tr>
<!-- Configure the NFS mount information when the tested device supports only the serial port connection. Specify the NFS mapping path. host_dir indicates the NFS directory on the PC, and board_dir indicates the directory created on the board. -->
</tbody>
<NFS>
</table>
<host_dir></host_dir>
<mnt_cmd></mnt_cmd>
The source code of Developertest is stored in the **test/developertest** directory. The following table describes the **developertest** directory structure.
<board_dir></board_dir>
</NFS>
**Table 5** Developertest structure
</user_config>
```
<aname="table2977131081412"></a>
>**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.
<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>
>**Note:**
</td>
> - --**product-name**: specifies the name of the product to build, for example, **Hi3516DV300**.
</tr>
> - --**build-target**: specifies the target to build. It is optional. **make_test** indicates all test cases. You can set the build options based on requirements.
2. Copy **developertest** and **xdevice** from the Linux environment to the **Test** directory on Windows, and copy the test cases to the **testcase** directory.
<tdclass="cellrowborder"valign="top"width="66.12%"headers="mcps1.2.3.1.2 "><pid="p6793059171318"><aname="p6793059171318"></a><aname="p6793059171318"></a>Test case compilation</p>
<!-- Because the test cases have been built, change the value to false -->.
<!-- 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. -->
<tdclass="cellrowborder"valign="top"width="66.12%"headers="mcps1.2.3.1.2 "><pid="p1629020401941"><aname="p1629020401941"></a><aname="p1629020401941"></a>Processing of command lines entered by users</p>
run -t UT -ts CalculatorSubTest -tc interger_sub_00l
</td>
```
<tdclass="cellrowborder"valign="top"width="66.12%"headers="mcps1.2.3.1.2 "><pid="p129013219235"><aname="p129013219235"></a><aname="p129013219235"></a>Test case management</p>
In the command:
</td>
```
</tr>
-t [TESTTYPE]: specifies the test case type, which can be UT, MST, ST, or PERF. This parameter is mandatory.
-tp [TESTTYPE]: specifies a part, which can be used independently.
</td>
-tm [TESTTYPE]: specifies a module. This parameter must be specified together with -tp.
<tdclass="cellrowborder"valign="top"width="66.12%"headers="mcps1.2.3.1.2 "><pid="p84031423201110"><aname="p84031423201110"></a><aname="p84031423201110"></a>Common operations on the test framework</p>
-ts [TESTTYPE]: specifies a test suite, which can be used independently.
</td>
-tc [TESTTYPE]: specifies a test case. This parameter must be specified together with -ts.
<tdclass="cellrowborder"valign="top"width="66.12%"headers="mcps1.2.3.1.2 "><pid="p10886151811115"><aname="p10886151811115"></a><aname="p10886151811115"></a>Global constants of the test framework</p>
#### Mapping Remote Port
</td>
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 remove server or VM. Configure port mapping as follows:
<tdclass="cellrowborder"valign="top"width="66.12%"headers="mcps1.2.3.1.2 "><pid="p11475103641712"><aname="p11475103641712"></a><aname="p11475103641712"></a>Internal entrance of the test framework</p>
2. Select the product.
</td>
</tr>
After the test framework starts, you are asked to select a product. Select the development board to test, for example, **Hi3516DV300**.
-tp [TESTTYPE]: specifies a part, which can be used independently.
</td>
-tm [TESTTYPE]: specifies a module. This parameter must be specified together with -tp.
<tdclass="cellrowborder"valign="top"width="66.12%"headers="mcps1.2.3.1.2 "><pid="p19235143291715"><aname="p19235143291715"></a><aname="p19235143291715"></a>Compilation configuration of the subsystem</p>
-ts [TESTTYPE]: specifies a test suite, which can be used independently.
</td>
-tc [TESTTYPE]: specifies a test case. This parameter must be specified together with -ts.
<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>
## Viewing the Test Report
</td>
After the test cases are executed, the test result will be automatically generated. You can view the detailed test result in the related directory.
You can obtain the test result in the following directory:
<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>
test/developertest/reports/xxxx_xx_xx_xx_xx_xx
</tr>
```
</tbody>
>**Note**: The folder for test reports is automatically generated.
</table>
The folder contains the following files:
| Type| Description|
| ------------ | ------------ |
| result/ |Test cases in standard format|
| log/plan_log_xxxx_xx_xx_xx_xx_xx.log | Test case logs|
