manual-cases-to-autotest

name: manual-cases-to-autotest description: Convert manual QA test cases into project-standard automated tests from a required Jira ID and manual-case link, using local workspace code and local automation repositories first. Use when the user asks "根据手工用例编写自动化用例", "针对需求生成自动化用例", "根据手工用例生成自动化测试用例", or provides Jira, code branch, and manual-case link. Supports CCTV, Workforce, Asset, and other codebases; apply business-specific automation repo mapping when the business can be identified.

Manual Cases To Autotest

Required User Inputs

The user must provide:

• Jira ID, for example SPWFM-4674.
• Manual test-case link, such as Google Sheets, Jira, Confluence, or another test-case document.

The user may provide:

• Code branch. If present, treat it as the preferred target branch for business/source code discovery.

If Jira or manual-case link is missing, ask one concise question for the missing value before implementation. Do not start remote reads or broad code changes without both.

Business Automation Repositories

Use this fixed mapping when selecting the automation project:

Automation project code is also local-first. Search the current workspace and sibling directories for the local repo name. If the automation repo is not present locally, use available MCP/remote code tools only as a fallback, or ask the user to provide a local checkout when remote tools are unavailable or disallowed.

Operating Defaults

• Prefer local workspace sources: current repo, sibling repos, checked-out branches, local docs, exported sheets, knowledge-base files, git diffs/logs, and existing tests.
• Use MCP/app/remote connectors only after local sources are insufficient, or when the user explicitly asks to read/write remote Jira, Sheet, Confluence, or Git repositories.
• Treat the manual-case link as required input but not automatically as permission to fetch remotely. First search for local exports or matching code/docs by Jira, sheet title, business keywords, endpoints, UI text, and scenario names.
• Keep the skill generic. Detect business and stack from the Jira prefix, manual-case wording, repo names, package paths, routes, and existing tests. Apply Workforce-specific Go conventions only when the local automation repo is xfm_autotest_go or clearly follows that style.
• Minimize token use: use rg, inspect targeted files with small ranges, and avoid bulk-loading generated code or huge docs.
• Preserve unrelated worktree changes. Before switching branches or editing, check git status --short --branch. Do not discard changes.

Workflow

1. Validate Inputs And Identify Business

Confirm Jira ID and manual-case link are present. Capture code branch if provided.

Infer the business in this order:

1. Existing automation repo in current working directory.
2. Manual-case link/title/content if available locally.
3. Jira prefix or project naming.
4. Local code paths and nearby repo names.

Then select the automation repository using the fixed mapping above. If the business cannot be identified and multiple automation repos are plausible, ask one concise question.

2. Locate And Prepare Local Code

For business/source code:

• If code branch is provided, find the relevant local code repo and switch to that branch before reading target code.
• Prefer git switch <branch> for local branches and git switch --track origin/<branch> or detached origin/<branch> only when appropriate.
• If the branch is not available locally, use git branch --all --list '*<branch>*' and local refs first. Fetch only if the user allows network or the environment already has the needed ref.
• If local checkout is absent or insufficient, use MCP/remote code tools as fallback, prioritizing the provided code branch.

If no code branch is provided:

• Use the manual cases and Jira to determine the business/module.
• Search workspace and sibling repos for related business code by Jira ID, feature keywords, route paths, handlers, models, DB tables, validation text, and UI labels.
• If a repo is not on a requirement branch and local branches include a clear Jira-matching branch, switch to that branch before deeper inspection.
• If multiple Jira-matching branches exist, choose the most specific/recent branch only when obvious; otherwise ask one concise question.
• If no target branch can be found, continue from the best local code that matches the manual cases and record the assumption.

For automation code:

• Locate the mapped automation repo locally first.
• If it is missing, use the mapped remote repository with MCP/remote code tools if available and allowed.
• Read local project rules, nearby tests, helpers, and fixtures before adding new code.

3. Read Manual Cases

Local-first manual-case extraction:

• Search local files for the Jira ID, sheet title, exported .md/.csv/.xlsx, PRD/TRD names, and scenario keywords.
• If no local manual-case content exists, read the provided manual-case link with MCP/app tools only if remote access is allowed. Otherwise ask the user to provide a local export or paste.

Capture at least:

• business/module and subsection
• case title
• preconditions, steps, expected results
• priority and target CID/environment if present
• Jira ID
• existing automation status/function-name column if present

If the user asks for a subset such as "先实现 xxx" or "继续下一批", implement only that batch.

4. Discover Existing Automation Patterns

Use local automation code to find:

• test package and naming conventions
• model/request/response structs
• service/API helpers
• fixtures and data builders
• DB, cache, cron/task, file upload/export helpers
• assertion/reporting/cleanup style

Reuse existing helpers before adding wrappers. Add model/service wrappers only when the tests need them and no suitable abstraction exists.

For xfm_autotest_go, also check these knowledge files when present:

• .cursor/knowledge_base/autotest_case_guideliness/project_structure.mdc
• .cursor/knowledge_base/autotest_case_guideliness/autocase_rule.mdc
• .cursor/knowledge_base/autotest_case_guideliness/autocase_generate_prompt.mdc

Follow nearby Workforce Go patterns such as executor.ReportCaseInfoALLCid, runtime.Caller(0), executor.TestParams.Params(t), t.Run(p.Info(runtime.FuncForPC(self).Name()), ...), p.CheckRunCid, and assert_util when the existing package uses them.

For CCTV, Asset, or other projects, follow the nearest package conventions instead of importing Workforce-only helpers.

5. Map Manual Steps To Automation

Prefer behavior-level automation through stable public APIs, service helpers, UI flows, or task entrypoints. Use DB writes mainly for setup and cleanup, not as a substitute for the behavior under test, unless the case is specifically about a background job, migration, or scheduled process.

For each scenario decide:

• setup data and cleanup strategy
• API/UI/service/task entrypoint
• assertions on response, DB state, downstream records, logs, notifications, exports, or visible state
• whether one test covers multiple manual rows via subcases/table cases

When real code behavior differs from manual wording, follow the actual contract and mention the difference in the final summary.

6. Implement Tests

Make scoped changes in the selected automation repo:

• Reuse local helpers, constants, fixtures, and request/response models first.
• Keep new helpers local to the test file unless reuse is clearly needed.
• Create unique test data and clean it up with defer, t.Cleanup, fixtures, transactions, or the local equivalent.
• Use adaptive polling for asynchronous behavior; avoid long fixed sleeps.
• Do not modify unrelated files or revert user changes.

7. Validate

Run formatting and the narrowest useful verification for the stack:

gofmt -w <changed-go-files>
go test ./<target-package> -run TestName -count=0
go test -v ./<target-package> -run 'TestA|TestB' -count=1

Adapt commands to the project (npm test, pytest, mvn test, etc.). If environment execution requires credentials, PFB, network, or unavailable data, run compile/static checks where possible and report the blocker clearly.

8. Optional Source Write-Back

Only write automation function names or statuses back to Google Sheets/Jira/Confluence when the user explicitly asks and remote tools are allowed. Verify the destination column/field before writing. For one automated test covering multiple manual rows, write the same parent test function name to each covered row.

9. Report

End with a concise Chinese summary:

• selected business and automation repo
• code branch used or branch inference assumption
• files changed
• test functions added or updated
• manual scenarios/rows covered
• verification commands and pass/fail status
• remote reads/write-backs skipped or performed
• blockers or assumptions