XTS Test Case Generator
Generate OpenHarmony XTS test cases following strict coding standards and test patterns.
Quick Reference
When generating XTS test cases, consult these references:
- Test Patterns & Templates - File structure, test scenarios, code templates
- Constraints & Standards - Type safety rules, error handling, forbidden patterns
Test File Generation Process
1. Parse API Documentation
From Markdown API documentation (js-apis-{module}.md), extract:
- Module name and import statement
- Method signatures with parameters
- Return types and error codes
- Enum definitions
- Permissions required
- Example code patterns
2. Generate Test Cases
For each API method, generate test cases following these scenarios:
| Scenario | Number | Description |
|----------|--------|-------------|
| Normal | 0100 | Required - Normal/expected call |
| Null | 0200 | Exception - null parameter |
| Undefined | 0201 | Exception - undefined parameter |
| Optional combos | 0500+ | For N optional params, generate 2^N tests |
| Enum | 0900+ | One test per enum type |
| File path | 2000+ | For file APIs with path parameter |
| File URI | 2100+ | For file APIs with URI parameter |
3. Test Case Number Format
SUB_{子系统缩写}_{模块名}_{方法名}_{场景}_{序号}
Examples:
SUB_MM_MechanicManager_on_0100- Normal callSUB_MM_MechanicManager_on_Null_0200- Null parameterSUB_MM_MechanicManager_EnumType_0900- Enum test
Critical Constraints
Type Safety (Strict)
// CORRECT - Explicit types
let result: string = methodName(param);
let callback: Callback = (data: DataType) => { };
// FORBIDDEN
let result = methodName(param); // No type
let data: any = result; // any type
let value: unknown = param; // unknown type
let x = result as any; // as any
Error Handling (Single Error Code)
// CORRECT - One error code only
catch (error) {
expect(error.code == 401).assertTrue();
}
// FORBIDDEN - Multiple error codes
expect(error.code == 401 || error.code == 402).assertTrue();
expect(error.code == 401 && error.code == 402).assertTrue();
English Only
All comments, logs, and JSDoc must be in English.
Common Test Template
/**
* @tc.number SUB_MM_ModuleName_methodName_0100
* @tc.name SUB_MM_ModuleName_methodName_0100
* @tc.desc Test normal call scenario for methodName
* @tc.size MediumTest
* @tc.type Function
* @tc.level Level 0
*/
it('SUB_MM_ModuleName_methodName_0100', TestType.FUNCTION | Size.MEDIUMTEST | Level.LEVEL0, async () => {
console.info("-----------------SUB_MM_ModuleName_methodName_0100 begin-----------------");
try {
let result: ReturnType = moduleName.methodName(param1, param2);
expect(result != null).assertTrue();
} catch (error) {
console.error('failed, code is ' + error.code + ', message is ' + error.message);
expect(error.code == errorCode).assertTrue();
}
console.info("-----------------SUB_MM_ModuleName_methodName_0100 end-----------------");
});
When to Use References
Read xts-patterns.md for:
- Complete file structure templates
- Lifecycle hook implementations
- File operation utilities (nextFileName, prepareFile)
- Specific test scenario patterns (0100, 0200, 0900, 2000, 2100)
- Event method patterns (on/off)
- Async/callback patterns
Read xts-constraints.md for:
- Type safety rules and forbidden patterns
- Error handling standards
- Code style requirements
- Test framework requirements (Hypium)
- Common error codes
- File naming conventions
Input Types
From API Documentation
- Method definitions with signatures
- Parameter types and names
- Return type descriptions
- Error code lists
- Enum definitions
- Example code blocks
Test Requirements
- Subsystem abbreviation (MM, DF, NET, etc.)
- Module name
- Test scenarios to cover
- File paths for file-related APIs
Output
Generated .ets test file with:
- Proper copyright header
- Hypium framework imports
- Complete lifecycle hooks
- Numbered test cases for each scenario
- Type-safe code with no
any/unknown - Proper error handling with single error codes
- English-only comments and logs