oh-ut-generator について
oh-ut-generator は、HWTEST_F の規約に沿って OpenHarmony の C++ 単体テストを生成するスキルです。関数や依存関係、ビルド設定のテストを必要とする開発者向けで、NDK/NAPI と CJSON のケースにも対応します。
主な機能
- 01正常系・例外系・境界値テストの生成
- 02モック作成と EXPECT_CALL/ON_CALL の設定
- 03BUILD.gn の依存関係と設定の照合
- 04NDK・NAPI・CJSON のテストパターンへの対応
- 05既存プロジェクトのスタイルとの整合
活用シーン
- 01ソースファイル内の全関数のテスト生成
- 02指定した関数のテスト生成
- 03既存テストファイルへのケース追加
- 04ソースコードの依存関係に対するモック作成
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ openharmonyinsight/ openharmony-skills --skill oh-ut-generatorインストール後、Claude Code で/oh-ut-generatorを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
examples/basic-test-example.cppmock-test-example.cppndk-test-example.cppreferences/assertion-standards.mdbuild-gn-rules.mdcjson-testing.mdcode-style-consistency.mdcoverage-requirements.mdframework-specs.mdmock-strategies.mdndk-napi-testing.mdsecurity-coding.mdsmart-pointer-usage.md詳細
OpenHarmony 単体テスト生成ツール
概要
HWTEST_F フレームワークの規約に従って、OpenHarmony のコード向けに包括的な C++ 単体テストを生成します。
主な機能
- テストの自動生成:通常、例外、境界のシナリオ向けのテストケースを作成します
- モックオブジェクトのサポート:モッククラスの作成と EXPECT_CALL/ON_CALL の設定
- BUILD.gn の設定:ソースファイルに対応する依存関係を自動的に照合します
- カバレッジの最適化:最低 75%のカバレッジを確保し、85%以上を目指します
- コードスタイルの一貫性:既存のテストパターンとの一貫性を維持します(しきい値:70%以上)
- NDK/NAPI のサポート:NDK インターフェース(7088+ OH_xxx)および NAPI 関数(302+ napi_xxx)を特別に処理します
- CJSON テスト:CJSON ライブラリのテストパターンを完全にサポートします
使い方
OpenHarmony の C++ ソースファイル向けに単体テストを生成する場合に、このスキルを呼び出してください。
対応するシナリオ
- 単一ファイルのテスト:ソースファイル内のすべての関数のテストを生成します
- 特定の関数のテスト:指定した関数のみのテストを生成します
- テストファイルの拡張:既存のテストファイルに新しいテストケースを追加します
- モックの生成:依存関係に対するモッククラスを自動的に作成します
重要な要件
テスト実装の完全性
- 実装の完全性:すべてのテストケースに完全な実装が必要です
- コメントのみのテストは禁止:コメントのみ、または本体が空のテストを生成することは禁止されています
- モックの使用:モックオブジェクトを作成した場合は、EXPECT_CALL/ON_CALL とともに使用する必要があります
- 分岐とアサーションの対応:分岐に対するアサーションは、分岐ロジックと正確に一致させる必要があります
カバレッジ要件
- 最低要件:分岐および行カバレッジ 75%(必須)
- 目標:分岐および行カバレッジ 85%(目標)
- 対象範囲:境界条件、例外経路、通常経路、すべての条件分岐
コードスタイルの一貫性
既存のテストファイルがある場合:
- スマートポインターの型:既存のコード(sptr/wptr と std::shared_ptr のどちらを使用しているか)に合わせる必要があります
- モックの使用方法:既存のモックパターンに合わせる必要があります
- アサーションのスタイル:既存のアサーションの選択(EXPECT_ と ASSERT_ のどちらを使用しているか)に合わせる必要があります
- テスト構造:既存のテストフィクスチャと命名パターンに合わせる必要があります
一貫性のしきい値:重要なシナリオで 70%以上
セキュリティコーディング
- メモリ管理:元の関数で使用されているスマートポインターのパターンに合わせます
- 変数の初期化:すべての変数を初期化する必要があります
- 境界チェック:配列やコンテナーにアクセスする前に必ず実施します
- ヌルポインターチェック:ポインターをデリファレンスする前に必ず実施します
- 戻り値のチェック:重要な関数に対して必ず実施します
フレームワークの仕様
HWTEST_F フレームワーク
// 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)
テストケースの命名
_001:通常のシナリオ_002:例外のシナリオ_003:境界のシナリオ_004+:その他の特殊なシナリオ
オブジェクト管理
// 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;
モックの使用
auto mock = std::make_shared<MockClass>();
EXPECT_CALL(*mock, Method()).WillOnce(Return(value));
アサーション
ASSERT_NE(instance_, nullptr); // Must check
EXPECT_EQ(result, expected);
EXPECT_TRUE(condition);
NDK インターフェースのテスト
NDK インターフェース(OH_xxx)では、次の要件に従ってください。
- リソースのライフサイクル:Create と Destroy の組み合わせが必須です
- テスト構造:通常経路(001)、例外経路(002)、境界(003)
- 戻り値の検証:すべてのエラーコードをテストします
- パラメーターの検証:ヌルポインター、無効な値、境界をテストします
CJSON のテスト
CJSON ライブラリの操作では、次の点に従ってください。
- 解析テスト:通常、ヌルポインター、不正な JSON
- 項目取得テスト:通常の取得、存在しない項目、型チェック
- 作成テスト:オブジェクト、配列、値の作成
- メモリ管理:すべての cJSON オブジェクトを削除する必要があります
BUILD.gn の要件
ohos_unittest ターゲット
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"]
}
設定の照合
システムはソースファイルの BUILD.gn 設定を自動的に抽出します。
- deps:すべてのソースターゲットの依存関係を含める必要があります
- external_deps:すべての外部依存関係を含める必要があります
- include_dirs:すべてのインクルードディレクトリを含める必要があります
- defines:ソースの defines に合わせます(必要に応じて private=public を追加します)
参考ファイル
詳細な仕様については、references/ ディレクトリをご覧ください。
- framework-specs.md:HWTEST_F フレームワークの規約とテストパターン
- mock-strategies.md:モックオブジェクトの作成と使用方法
- coverage-requirements.md:カバレッジ指標と最適化方法
- build-gn-rules.md:BUILD.gn の設定と依存関係の適合
- assertion-standards.md:アサーションメソッドと分岐の対応
- code-style-consistency.md:既存のテストとの一貫性に関する要件
- smart-pointer-usage.md:sptr/wptr と標準スマートポインターの使用方法
- ndk-napi-testing.md:NDK/NAPI インターフェースのテスト仕様
- cjson-testing.md:CJSON ライブラリのテストパターン
- security-coding.md:メモリー管理とセキュアコーディングの要件
例
examples/ ディレクトリにある例をご覧ください。
- basic-test-example.cpp:基本的なテスト構造とパターン
- mock-test-example.cpp:モックオブジェクトの使用例
- ndk-test-example.cpp:NDK インターフェースのテスト例
コメント
Markdown 対応