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 |
testing
--- name: ohos-req-value-decision description: Use after review meeting to record decision and route to next step. Triggers: 评审决策纪要, 评审结论回流, value decision, 评审接纳, 评审不接纳, 评审退回, 下次重新上会. Do NOT use for feature baseline (ohos-req-feature-baseline), review gate checks (ohos-req-review-gate), or IR generation (ohos-req-feature-to-ir). metadata: author: openharmony scope: common stage: requirements capability: value-decision version: 0.3.0 status: draft tags: - sdd - requirements
development
Use when converting an OpenHarmony requirement document, spec, or design proposal into an OpenHarmony review slide deck (需求评审 / 需求变更评审 / 设计评审 PPTX) — produces the fixed OpenHarmony-branded review-deck structure (OH logo on every page) with architecture/flow diagrams and field tables. Triggers on "需求评审PPT", "需求变更评审", "把需求文档转成评审PPT", "spec转评审PPT", "requirement/spec to review deck". NOT for arbitrary or generic slide decks unrelated to OpenHarmony requirement/design review.
testing
Use when performing the Phase 0 Step 0.5 Review Ready Gate on a 04-feature.md, especially when the user says "evaluate gate", "review readiness", "feature ready?", "should we generate IR", or when the ohos-req-intake-orchestration main session needs a structured Ready / Conditional Ready / Not Ready judgment instead of doing the check inline. Reads 01-04, runs seven fixed checks plus a conditional-items check, and returns a machine-readable JSON summary plus a human-readable table that the main session can route on. Do NOT use for feature baseline generation (ohos-req-feature-baseline), value decision recording (ohos-req-value-decision), or IR generation (ohos-req-feature-to-ir).
testing
--- name: ohos-req-requirement-intake description: Use when importing an OHOS requirement into Phase 0.1, especially for 01-requirement.md, requirement intake, background, user value, scenarios, scope, FR/NFR, affected modules, or priority. Triggers: 需求导入, 01-requirement, 需求基线, RR单号. Do NOT use for feasibility analysis (ohos-req-feasibility-analysis), architecture decision (ohos-req-arch-decision), or feature baseline (ohos-req-feature-baseline). metadata: author: openharmony scope: common