R011: testsuite重复

Detect duplicate XTS testsuite identifiers in describe() calls across XTS project files.

31|6|Updated Jan 29, 2026
One-click install
npx skills add https://github.com/openharmonyinsight/openharmony-skills --skill r011-testsuite
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: R011: testsuite重复
Source: https://github.com/openharmonyinsight/openharmony-skills/tree/main/skills/check-test-code-quality/rules/R011
Command: npx skills add https://github.com/openharmonyinsight/openharmony-skills --skill r011-testsuite

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill finds duplicate XTS testsuite identifiers caused by repeated top-level describe() names within the same independent XTS project, which can break test clarity and tooling expectations.

Core Features & Use Cases

  • Independent XTS project boundary detection: Automatically treats an independent XTS project as the non-group BUILD.gn directory that contains BUILD.gn and test files, then avoids cross-project false positives.
  • Duplicate describe() detection per project: Scans all direct test files in the project root and extracts the first describe() string argument to detect duplicates.
  • Actionable fix suggestions with deterministic naming: Reports the first occurrence location and suggests renaming later duplicates by appending Adapt + a zero-padded 3-digit number (e.g., Adapt001, Adapt002).
  • Targeted output strategy: Emits one issue per duplicated name group, referencing the first occurrence and listing other duplicate locations.

Quick Start

Ask the AI to run the R011 testsuite-duplication scan for your XTS project directory and return a list of duplicate describe() names with exact file:line locations and rename suggestions.

Frequently Asked Questions about R011: testsuite重复

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

FAQPage Schema
How do I detect duplicate describe() names in OpenHarmony XTS test code?

To detect duplicate describe() names in XTS test code, scan all .test.ets, .test.ts, and .test.js files within an independent XTS project boundary and extract the first string argument from each describe() call to find duplicates.

What is the scope boundary for scanning duplicate XTS testsuite identifiers?

The scope for scanning duplicate XTS testsuite identifiers is a non-recursive, independent XTS project directory containing BUILD.gn and test files. This per-project boundary prevents cross-project false positives during static analysis.

How do I fix duplicate testsuite identifiers found during XTS code quality checks?

To fix duplicate testsuite identifiers, keep the first occurrence and rename later duplicates by appending a deterministic Adapt + zero-padded 3-digit suffix, such as Adapt001 or Adapt002, to the describe() string argument.

Can I use this duplicate detection on .test.ets and .test.ts files?

Yes, you can use this duplicate detection on .test.ets, .test.ts, and .test.js files. It scans all direct test files in the project root to extract and evaluate the first describe() string argument.

How are duplicate describe() groups reported in XTS static analysis?

Duplicate describe() groups are reported by emitting one issue per duplicated name group. The report references the first occurrence location and lists all other duplicate file and line locations for clarity.

Why do duplicate top-level describe() names break XTS test tooling?

Duplicate top-level describe() names break XTS test tooling because repeated testsuite identifiers within the same independent XTS project reduce test clarity and disrupt automated tooling expectations for test execution.