skills/ohos-test-graphics3d-static-api-unit-test/SKILL.md
Use when generating unit tests for ETS/ArkTS static API classes in OpenHarmony graphic_3d module, when adding new test cases for MaterialETS, CameraETS, SceneETS or similar wrapper classes, or when setting up test environment for GTest-based ETS unit tests
npx skillsauth add openharmonyinsight/openharmony-skills ohos-test-graphics3d-static-api-unit-testInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Guide for generating ETS/ArkTS static API unit tests based on OpenHarmony GTest framework. Provides test generation workflow, naming conventions, and core patterns.
CameraETS, MaterialETS)Do NOT use when:
| Element | Convention | Example |
|---------|------------|---------|
| Test class name | <Module>ETSUnitTest | MaterialETSUnitTest |
| Test case name | <Class>_<Method>_<Number> | MaterialETS_Create_001 |
| Test file name | <module>_ets_unit_test.cpp | material_ets_unit_test.cpp |
| Macro | Purpose |
|-------|---------|
| HWTEST_F | Fixed test fixture (required for all ETS unit tests) |
Test Levels: Use appropriate TestSize.Level0-Level4 based on test complexity.
TestSize.Level1 for most API method testsSee UNITTEST_GUIDE.md "Test Case Macros" section for complete Level0-Level4 definitions.
/**
* @tc.name: <TestCaseName>
* @tc.desc: <Description>
* @tc.type: FUNC / PERF
*/
Use Arrange-Act-Assert pattern:
/**
* @tc.name: MaterialETS_Create_001
* @tc.desc: Test MaterialETS creation and initialization
* @tc.type: FUNC
*/
HWTEST_F(MaterialETSUnitTest, MaterialETS_Create_001, TestSize.Level1)
{
auto material = std::make_shared<MaterialETS>();
EXPECT_TRUE(material->IsValid()); // EtsTest provides engine context automatically
}
api_unit_test/<module>_ets_unit_test.cppsources listComplete implementation details: UNITTEST_GUIDE.md provides:
For loading guidance, see "When to Load References" section below.
Rule: Start with SKILL.md. Load UNITTEST_GUIDE.md only when blocked or setting up new environment.
Link: UNITTEST_GUIDE.md (load only when above conditions apply)
| Issue | Solution |
|-------|----------|
| Header not found | Check BUILD.gn include_dirs |
| Library not found | Ensure libAGPDLL.z.so deployed |
| Tests interfere | Use SetUp/TearDown for isolation |
| ❌ Wrong | ✅ Right | Reason |
|----------|----------|--------|
| MaterialETS_Test | MaterialETSUnitTest | OpenHarmony requires UnitTest suffix |
| MaterialETS_Create | MaterialETS_Create_001 | Test naming MUST include _Number suffix |
| Skip @tc.name | Always add annotation | Required for test report generation |
| Use GTest macro directly | Use HWTEST_F macro | OpenHarmony test framework requires it |
| Write test without annotations | Include complete annotation block | Missing annotations break test discovery |
Tests generated following this skill:
| Document | Description | |----------|-------------| | UNITTEST_GUIDE.md | Complete BUILD.gn template, EtsTest base class, environment setup |
development
Run local code quality checks covering a subset of OpenHarmony gate CI (copyright, CodeArts C/C++) plus additional local checks (pylint/flake8, shellcheck/bashate, gn format). Use before committing to reduce gate failures. Triggers on: /oh-precommit-codecheck, "门禁检查", "门禁预检", "检查代码", "run codecheck", "check code quality", "lint my code", "代码检查", or after completing code implementation. WHEN to use: before git commit, before creating PR, after modifying C/C++/Python/Shell/GN files, when gate CI fails with codecheck defects, or when you want to preview what gate will flag.
development
OpenHarmony PR full lifecycle workflow. Five modes: - Commit: standardized commit with DCO sign-off and Issue linking - Create PR: commit + push to fork + create Issue + create PR on upstream - Fix Codecheck: fetch gate CI codecheck defects from a PR and auto-fix them - Review PR: fetch a PR's changes to local for code review - Fix Review: fetch unresolved review comments from a PR and auto-fix them Triggers on: /oh-pr-workflow, "提交代码", "创建PR", "提个PR", "commit", "修复告警", "修复门禁", "修复codecheck", "fix codecheck", "review pr", "review这个pr", "看下这个pr", "检视pr", "修复review", "修复检视意见", "fix review", or a GitCode PR URL with fix/review intent.
testing
分析 HM Desktop PRD 文档,提取需求信息、验证完整性、检查章节顺序(需求来源→需求背景→需求价值分析→竞品分析→需求描述)、检查 KEP 定义、检测需求冲突并生成结构化分析报告。适用于用户请求:(1) 分析或审查 PRD 文档, (2) 从需求中提取 KEP 列表, (3) 检查 PRD 完整性或一致性, (4) 将需求映射到模块架构, (5) 验证 PRD 格式合规性, (6) 验证竞品分析章节完整性。关键词:PRD分析, requirement extraction, KEP验证, completeness check, chapter order validation, 竞品分析检查, analyze PRD, 需求提取, 完整性检查, 章节顺序验证
development
基于 PRD 文档自动生成鸿蒙系统设计文档,包括架构设计文档和功能设计文档。生成前会分析 OpenHarmony 存量代码结构,确保与现有架构兼容。架构设计文档第2章必须为竞品方案分析,位于需求背景之后。适用于用户请求:(1) 生成架构设计文档, (2) 生成功能设计文档, (3) 从 PRD 生成设计文档, (4) 创建系统架构设计, (5) 编写功能规格说明, (6) 分析 OH 代码结构。关键词:architecture design, functional design, design doc, 竞品方案分析, OpenHarmony code analysis, 架构设计, 功能设计, 设计文档生成, OH代码分析, analyze codebase, competitor analysis