SuperAPI AI Directory
Partner中文AI newsFavorites
Skillstestany-case-writing

testany-case-writing

Writing & research

View repository

Updated 10-16 08:33

About this skill

Testany Platform Case Writing

Break down traditional test scenarios into Testany platform cases, and generate scripts, metadata, and ZIP packages registrable to the Testany platform.

User input: $ARGUMENTS

Host capability adaptation

  • According to Overall goal and handoff retain the user's goal, authorization, artifact paths, and true status. Division of labor across skills does not mean stopping; the authorized complete goal continues in the current conversation, and if only a local package is needed, it ends at package delivery.
  • If the host supports slash commands, testany-case can be used as the recommended registration entry point, and testany-pipeline as the recommended orchestration entry point.
  • If the host does not support slash commands, then continue the corresponding workflow directly in the current thread.

Upstream input priority

Select the input mode according to the following priority:

  1. Primary：approved Test Spec + Testany Automation Handoff
    • From testany-eng
    • Testany Automation Handoff.status = ready | partial
    • This is the preferred input for this skill
  2. Secondary: approved Test Spec, but no handoff
    • You can continue, but you need to supplement the scenario grouping / executor / split decisions yourself
  3. Fallback: user natural language / existing test design document
    • Use only when neither of the first two is available

If the input comes from a Test Spec, preferentially refer to:

  • ../../../testany-eng/references/testany-automation-handoff-contract.md
  • Testany Automation Handoff in the section scenario_groups
  • source_case_ids、recommended_executor、platform_case_strategy

If the input Test Spec is still draft / in_review：

  • By default, do not directly treat it as a formal automation baseline
  • You should first suggest that the user complete testany-eng of /test-reviewer
  • Only when the user explicitly accepts exploratory / draft-state automation splitting should you continue, and explicitly mark it as low confidence

First unify the mental model

Before starting, first understand the object boundaries according to automation-model.md :

  • What the user provides is usually traditional test scenario, that is, a complete test scenario / business verification goal.
  • What this skill produces is Testany platform case, that is, a reusable atomic automation step package.
  • pipeline is the execution and orchestration unit of Testany.
  • trigger is Plan / Manual Trigger / Gatekeeper, acting on the pipeline, not the case.

Important conclusion：

  • Do not by default directly write "one traditional test scenario" as "one Testany case".
  • First determine how many platform cases the scenario needs to be split into, then write the scripts and ZIP.

Responsibilities

  • Consume traditional test scenario input: approved test-spec、Testany Automation Handoff, user natural language, existing test design document
  • Determine how many Testany platform cases a scenario should be split into
  • Select the appropriate Executor for each platform case
  • Generate the metadata, scripts, and ZIP package for each platform case
  • Produce downstream-facing automation design / decomposition summary

Responsibilities handed off to other Skills

  • Notresponsible for registering the case to the Testany platform; this belongs to testany-case
  • Notresponsible for creating/updating the pipeline; this belongs to testany-pipeline
  • Notresponsible for configuring Plan / Manual Trigger / Gatekeeper; this belongs to testany-trigger

The above are professional responsibility boundaries, not stopping conditions for the overall task. When the user's goal includes these actions and authorization already covers them, read the corresponding skill and continue; when not included, do not proactively execute.

Workflow

Phase 0: Determine input mode and credibility

If the input comes from a Test Spec, first check:

  1. Whether the Test Spec is approved
  2. Whether there is Testany Automation Handoff
  3. Testany Automation Handoff.status is ready、partial or not_planned

Handling rules:

  • readyTODOTODO
  • partialTODO open_questions
  • not_plannedTODO
  • TODO

TODO

TODO

  1. TODO
  2. TODO test-spec、Testany Automation HandoffTODO
  3. TODO
  4. TODO

TODO

TODO

TODO Testany Automation Handoff：

  • TODO scenario_groups
  • TODO recommended_executor
  • TODO platform_case_strategy
  • TODO

TODO

  • TODO
  • TODO
  • TODO
  • TODO expect: fail
  • TODO

TODO

  • TODO
  • TODO
  • TODO
  • TODO

TODO

TODO

  • name
  • description
  • case_labels
  • executor
  • path TODO command
  • environment_variables
  • TODOtype=output TODO
  • TODO
  • TODO

TODO

TODO TODO TODO scripts/validate_package.py ZIP --metadata metadata.jsonTODOpass TODOincomplete TODO

TODO

  • TODO
  • TODO
  • TODO source_case_ids
  • TODO
  • TODO
  • TODO testany-pipeline TODO

TODO：

  • TODOmustproduce the conclusion that "subsequent pipeline orchestration is required"; do not stop at the ZIP.
  • Even if there is only one platform case, as long as what the user wants is an "executable asset", it should be clearly stated that a pipeline is still required afterward to run it in Testany.

Phase 5: Continue according to the overall goal

  • If the user wants to register the package with the platform: switch to testany-case
  • If the user wants to form an executable chain: continue to testany-pipeline
  • If the user wants to configure an execution entry point: then continue to testany-trigger
  • When the above actions are already within the user's complete goal and authorization, read the corresponding skill and actually continue, passing the path, plan, and real key; do not merely give entry suggestions. When only the package is wanted, stop at local delivery.

Recommended output structure

1. Scenario Summary

  • What the original traditional test scenario is
  • Why it is split this way

2. Platform Case Inventory

For each platform case, provide:

  • Alias / local file name
  • source_case_ids
  • Target action
  • executor
  • Input variables
  • Output variables
  • ZIP package path

3. Automation Design Summary

  • single-case runnable?: whether it is just a single atomic step
  • pipeline required: default yes
  • dependencies：A -> B -> C
  • relay map: for example LOGIN.AUTH_TOKEN -> SUBSCRIBE.AUTH_TOKEN
  • branching: whether there is whenFailed / expect: fail

4. Goal Status

  • Whether this goal has been completed, partially completed, or blocked, as well as the actual artifacts and verification limitations.
  • Registration/orchestration that is unfinished but authorized continues; actions beyond this goal are only briefly explained when relevant and are not proactively implemented.

Executor selection decision tree

Platform case 类型
    ├─ API 调用 / Python 优先 → PyRes ✓
    ├─ API 调用 / 不想写代码 → Postman
    ├─ UI / E2E 步骤 → Playwright
    └─ Java 项目测试 → Maven 或 Gradle

According to the selected Executor, refer to the corresponding template:

Executor Template file Applicable scenario
PyRes pyres.md Python API test (recommended)
Postman postman.md Quick API verification
Playwright playwright.md UI/E2E test
Maven/Gradle maven.md Java project test

Note:executor is a strict backend string. The values involved in this skill are:pyres, postman, playwright, maven, gradle(the platform also supports python, jmeter）。

Environment variable type (case_meta.environment_variables.type)

Type Purpose Example
env Input/general configuration (including relay input) API_BASE_URL, AUTH_TOKEN
output Relay output ACCESS_TOKEN, USER_ID
secrets Reference a workspace Credential Safe entry PASSWORD, API_KEY

Constraints (consistent with platform validation):

  • type supports env / output / secrets
  • name must start with an uppercase letter and may contain only uppercase letters, digits, and underscores; it must be unique within the same case
  • env / output：name/value cannot be empty or contain only whitespace characters; if you need to express "empty value", explicitly fill in -
  • secrets: must fill in secret_ref: { workspace_key, credential_safe_key, credential_key }，Forbiddenfill in value; in the script, just directly read the environment variable with the same name (e.g. os.getenv("PASSWORD")）
  • secrets When the reference key of is unknown, during the authorized registration phase, follow Secure credential lookup query; the signed request is data, and the returned curl string is not executed. When only preparing locally, keep the reference to be configured, and do not access the credential service without authorization in order to complete the package.
  • secrets When read back, include the read-only field status（valid / blocked / invalid) and status_reasons[]; when writing, do not pass

Key rules of Output Relay

Relay is the combined capability of pipeline-level orchestration + case-level output configuration . It is effective only when the constraints at both ends are satisfied at the same time.

Output Case

  • Declare in case metadata the variables of type: output Declare in case metadata the variables of type: output
  • In the code, POST the same-named key to TESTANY_OUTPUT_RELAY_SERVICE

Input Case

  • Declare in case metadata the variables of type: env Declare in case metadata the variables of type: env
  • Read as an environment variable in the code

Orchestration layer

  • Configured by testany-pipeline in the pipeline YAML: relay.key and relay.refKey
  • Only passed upstream cases can provide relay data

If you have identified a relay requirement, you must explicitly tell downstream in the output:

  • Which case produces which variable
  • Which case consumes that variable
  • Subsequently, testany-pipeline is needed for relay orchestration

After completion

First report the local check results of each actual package and the remaining configuration/evidence gaps, then continue according to the overall goal. File existence alone is not a registrable completion criterion; after fixing a package, the final version must be rechecked.

Upon delivery, you must tell the user:

  1. How many platform cases this traditional test scenario was split into
  2. The list of generated files and the ZIP package location
  3. Which cases need to be registered with Testany
  4. Whether it is necessary to continue to testany-pipeline
  5. If the host supports slash commands, you may suggest /testany-case and /testany-pipeline
  6. If this input comes from a Test Spec, you should explicitly echo back the consumed source_case_ids and scenario_groups

Reference documentation

Local References

Documentation (fallback)

If the local references are insufficient to solve the problem, please consult the Testany documentation center; when the examples in this skill are inconsistent with the documentation, the documentation shall prevail: