OpenHarmony Unit Test Generator

Overview

Generate comprehensive C++ unit tests for OpenHarmony code following HWTEST_F framework conventions.

Key Features

Automatic Test Generation

Create test cases for normal/exception/boundary scenarios

Mock Object Support

Mock class creation and EXPECT_CALL/ON_CALL setup

BUILD.gn Configuration

Automatic dependency matching with source files

Coverage Optimization

75% minimum coverage, targeting 85%+

Code Style Consistency

Maintains consistency with existing test patterns (>=70% threshold)

NDK/NAPI Support

Special handling for NDK interfaces (7088+ OH_xxx) and NAPI functions (302+ napi_xxx)

CJSON Testing

Complete support for CJSON library testing patterns

Usage

Invoke this skill when you need to generate unit tests for OpenHarmony C++ source files.

Supported Scenarios

Single File Testing

Generate tests for all functions in a source file

Specific Function Testing

Generate tests for a specific function only

Test File Extension

Append new test cases to existing test files

Mock Generation

Automatically create mock classes for dependencies

Critical Requirements

Test Implementation Completeness

Complete Implementation Only

Every test case must have complete implementation

No Comments-Only Tests

Forbidden to generate tests with only comments or empty bodies

Mock Usage

If Mock objects are created, they must be used with EXPECT_CALL/ON_CALL

Branch-Assertion Correspondence

Branch assertions must match branch logic exactly

Coverage Requirements

Minimum

75% branch and line coverage (mandatory)

Target

85% branch and line coverage (goal)

Scope

Boundary conditions, exception paths, normal paths, all conditional branches

Code Style Consistency

When existing test files exist:

Smart Pointer Type

Must match existing code (sptr/wptr vs std::shared_ptr)

Mock Usage

Must match existing Mock patterns

Assertion Style

Must match existing assertion preferences (EXPECT_ vs ASSERT_)

Test Structure

Must match existing test fixtures and naming patterns

Consistency Threshold

>=70% for important scenarios

Security Coding

Memory Management

Match original function's smart pointer usage pattern

Variable Initialization

All variables must be initialized

Boundary Checks

Required before array/container access

Null Pointer Checks

Required before pointer dereference

Return Value Checks

Required for critical functions

Framework Specifications

HWTEST_F Framework

// Test fixture structure

class

YourServiceTest

:

public

testing

::

Test

{

public

:

static

void

SetUpTestCase

(

void

)

;

static

void

TearDownTestCase

(

void

)

;

void

SetUp

(

)

;

void

TearDown

(

)

;

std

::

shared_ptr

<

YourService

>

instance_

;

}

;

// Test case format

HWTEST_F

(

TestClassName

,

TestCaseName_001

,

TestSize

.

Level1

)

Test Case Naming

_001

Normal scenario

_002

Exception scenario

_003

Boundary scenario

_004+

Other special scenarios

Object Management

// Standard smart pointers

SetUp

(

)

:

instance_

=

std

::

make_shared

<

YourService

>

(

)

;

TearDown

(

)

:

instance_

=

nullptr

;

// OpenHarmony sptr/wptr

SetUp

(

)

:

instance_

=

MakeSptr

<

YourService

>

(

)

;

// or instance_ = new YourService();

TearDown

(

)

:

instance_

=

nullptr

;

Mock Usage

auto

mock

=

std

::

make_shared

<

MockClass

>

(

)

;

EXPECT_CALL

(

*

mock

,

Method

(

)

)

.

WillOnce

(

Return

(

value

)

)

;

Assertions

ASSERT_NE

(

instance_

,

nullptr

)

;

// Must check

EXPECT_EQ

(

result

,

expected

)

;

EXPECT_TRUE

(

condition

)

;

NDK Interface Testing

For NDK interfaces (OH_xxx), follow these requirements:

Resource Lifecycle

Create/Destroy pairing is mandatory

Test Structure

Normal path (001), Exception path (002), Boundary (003)

Return Value Verification

Test all error codes

Parameter Validation

Test null pointers, invalid values, boundaries

CJSON Testing

For CJSON library operations:

Parse Tests

Normal, null pointer, invalid JSON

Get Item Tests

Normal get, non-existent item, type checks

Create Tests

Object, array, value creation

Memory Management

All cJSON objects must be deleted BUILD.gn Requirements ohos_unittest Target ohos_unittest ( "{CamelCase}Test" ) { module_out_path = "subsystem/module" branch_protector_ret = "pac_ret" sanitize = { integer_overflow = true cfi = true cfi_cross_dso = true debug = false } sources = [ "test_file.cpp" ]

Alphabetically sorted

include_dirs

[

"//include/path"

]

deps

=

[

":source_target"

]

external_deps

=

[

"hilog:libhilog"

,

"c_utils:utils"

,

"googletest:gtest_main"

]

defines

=

[

"private=public"

]

}

Configuration Matching

The system automatically extracts source file's BUILD.gn configuration:

deps

Must include all source target dependencies

external_deps

Must include all external dependencies

include_dirs

Must include all include directories

defines

Must match source defines (add private=public if needed)

Reference Files

Detailed specifications are available in the

references/

directory:

framework-specs.md

HWTEST_F framework conventions and test patterns

mock-strategies.md

Mock object creation and usage strategies

coverage-requirements.md

Coverage metrics and optimization strategies

build-gn-rules.md

BUILD.gn configuration and dependency matching

assertion-standards.md

Assertion methods and branch correspondence

code-style-consistency.md

Consistency requirements with existing tests

smart-pointer-usage.md

sptr/wptr vs standard smart pointer usage

ndk-napi-testing.md

NDK/NAPI interface testing specifications

cjson-testing.md

CJSON library testing patterns

security-coding.md

Memory management and secure coding requirements

Examples

See the

examples/

directory for:

basic-test-example.cpp

Basic test structure and patterns

mock-test-example.cpp

Mock object usage examples

ndk-test-example.cpp

NDK interface testing examples