oh-xts-generator-template

Generate OpenHarmony XTS test cases and design documents from .d.ts API declarations.

31|6|Updated Jan 29, 2026
One-click install
npx skills add https://github.com/openharmonyinsight/openharmony-skills --skill oh-xts-generator-template
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: oh-xts-generator-template
Source: https://github.com/openharmonyinsight/openharmony-skills/tree/main/skills/oh-xts-generator-template
Command: npx skills add https://github.com/openharmonyinsight/openharmony-skills --skill oh-xts-generator-template

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve?

It helps you automatically generate OpenHarmony XTS test cases from API declaration files, keep test design documents synchronized, and ensure the generated ArkTS code passes required syntax validation and compilation workflows.

Core Features & Use Cases

  • API definition parsing: parses .d.ts to extract classes, methods, parameters, return types, and @throws-declared error codes.
  • Test case generation with coverage support: generates PARAM/ERROR/RETURN/BOUNDARY tests either from API structure + coverage analysis or directly from user-provided coverage reports.
  • Quality gate enforcement: performs mandatory formatting/validation checks (including assertion methods, @tc block completeness, naming rules) and supports ArkTS static-vs-dynamic API filtering and compilation guidance.

Use case example: You need to add missing tests for a subsystem’s APIs and want the AI to generate both the .test.ets files and the matching {test_file}.design.md documentation, then validate that the result can be compiled in Linux/Windows workflows.

Quick Start

Use the skill to generate XTS tests for your target subsystem by providing the API name and subsystem configuration, then run the generated test through the required format/validation and compilation steps.

Frequently Asked Questions about oh-xts-generator-template

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I generate OpenHarmony XTS test cases from API declaration files?

OpenHarmony XTS test case generation requires parsing `.d.ts` API declarations to extract method signatures and `@throws` error codes. The generator outputs `.test.ets` files and synchronized design documents, applying PARAM, ERROR, RETURN, and BOUNDARY test coverage.

Can I generate missing XTS tests using an existing coverage report?

Yes, you can generate missing XTS tests directly from user-provided coverage reports. The generator analyzes the coverage gaps in your subsystem APIs and outputs the corresponding ArkTS test cases to supplement the missing test coverage.

How do I create XTS test design documents that stay synchronized with my test code?

Creating synchronized XTS test design documents happens automatically during test case generation. The process outputs both the `.test.ets` files and the matching `{test_file}.design.md` documentation, ensuring your test design documents align with the generated ArkTS code.

Does the XTS test generator support filtering ArkTS static and dynamic syntax APIs?

Yes, the XTS test generator supports ArkTS static and dynamic syntax API filtering. When requested, it filters APIs by syntax type during parsing and enforces corresponding `@tc` block completeness and assertion method correctness for the generated tests.

What compilation workflow guidance is provided for generated OpenHarmony XTS tests?

Compilation workflow guidance for generated OpenHarmony XTS tests includes mandatory formatting and validation checks for both Linux and Windows environments. It ensures the generated ArkTS code passes required syntax validation and compilation workflows before integration.

What are the limitations of automated XTS test case generation from .d.ts files?

Automated XTS test case generation from `.d.ts` files relies entirely on the accuracy of API declarations and `@throws` annotations. It cannot infer runtime behaviors or undocumented errors, requiring manual verification to ensure complete `@tc` block correctness and boundary condition coverage.