mcpField
O
oh-ut-generator

oh-ut-generator

github.com/openharmonyinsightテスト・品質35120 回インストール11 週間前に更新
リポジトリ

oh-ut-generator について

oh-ut-generator は、HWTEST_F の規約に沿って OpenHarmony の C++ 単体テストを生成するスキルです。関数や依存関係、ビルド設定のテストを必要とする開発者向けで、NDK/NAPI と CJSON のケースにも対応します。

主な機能

  1. 01正常系・例外系・境界値テストの生成
  2. 02モック作成と EXPECT_CALL/ON_CALL の設定
  3. 03BUILD.gn の依存関係と設定の照合
  4. 04NDK・NAPI・CJSON のテストパターンへの対応
  5. 05既存プロジェクトのスタイルとの整合

活用シーン

  1. 01ソースファイル内の全関数のテスト生成
  2. 02指定した関数のテスト生成
  3. 03既存テストファイルへのケース追加
  4. 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.cpp
mock-test-example.cpp
ndk-test-example.cpp
references/
assertion-standards.md
build-gn-rules.md
cjson-testing.md
code-style-consistency.md
coverage-requirements.md
framework-specs.md
mock-strategies.md
ndk-napi-testing.md
security-coding.md
smart-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++ ソースファイル向けに単体テストを生成する場合に、このスキルを呼び出してください。

対応するシナリオ
  1. 単一ファイルのテスト:ソースファイル内のすべての関数のテストを生成します
  2. 特定の関数のテスト:指定した関数のみのテストを生成します
  3. テストファイルの拡張:既存のテストファイルに新しいテストケースを追加します
  4. モックの生成:依存関係に対するモッククラスを自動的に作成します

重要な要件

テスト実装の完全性
  • 実装の完全性:すべてのテストケースに完全な実装が必要です
  • コメントのみのテストは禁止:コメントのみ、または本体が空のテストを生成することは禁止されています
  • モックの使用:モックオブジェクトを作成した場合は、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)では、次の要件に従ってください。

  1. リソースのライフサイクル:Create と Destroy の組み合わせが必須です
  2. テスト構造:通常経路(001)、例外経路(002)、境界(003)
  3. 戻り値の検証:すべてのエラーコードをテストします
  4. パラメーターの検証:ヌルポインター、無効な値、境界をテストします

CJSON のテスト

CJSON ライブラリの操作では、次の点に従ってください。

  1. 解析テスト:通常、ヌルポインター、不正な JSON
  2. 項目取得テスト:通常の取得、存在しない項目、型チェック
  3. 作成テスト:オブジェクト、配列、値の作成
  4. メモリ管理:すべての 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 インターフェースのテスト例

コメント