Back to Details

add-acceptance-test

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Add Acceptance Test

添加Acceptance Test

Always use the skill 
load-plain-reference
to retrieve the ***plain syntax rules — but only if you haven't done so yet.
请始终使用技能
load-plain-reference
来获取***plain语法规则——但仅在你尚未执行过此操作时使用。

Workflow

工作流程

  1. Identify the target 
    .plain
    file and the functional spec     to attach the acceptance test to. If ambiguous, ask the user.
  2. Read the file to understand the functional spec, existing acceptance tests (if any), and the 
    ***test reqs***
    section (acceptance tests are implemented according to test reqs).
  3. Draft the acceptance test(s) following the rules below.
  4. Nest them under the target functional spec using a 
    ***acceptance tests***
    subsection.
  5. Read the file again to confirm correct placement, indentation, and syntax.
  1. 确定目标
    .plain
    文件和要附加Acceptance Test的functional spec    。如果存在歧义，请询问用户。
  2. 读取文件，以理解functional spec、现有Acceptance Test（如有）以及
    ***test reqs***
    章节（Acceptance Test需根据测试要求实现）。
  3. 按照以下规则起草Acceptance Test。
  4. 将其嵌套在目标functional spec下的
    ***acceptance tests***
    子章节中。
  5. 再次读取文件，确认放置位置、缩进和语法均正确。

When to Add Acceptance Tests

何时添加Acceptance Test

  • The functional spec's correct behavior is non-obvious or easily misinterpreted.
  • The spec involves edge cases, boundary conditions, or specific numeric outcomes.
  • The user explicitly requests verification criteria.
  • The spec was added via the 
    add-functional-spec
    skill and warrants testable success criteria.
  • functional spec的正确行为不明确或容易被误解。
  • 规范涉及边缘情况、边界条件或特定数值结果。
  • 用户明确要求验证标准。
  • 规范是通过
    add-functional-spec
    技能添加的，且需要可测试的成功标准。

Format

格式

Acceptance tests are nested under the functional spec they verify, using a 
***acceptance tests***
subsection:
plain
***functional specs***
- The system should process :Task: items in batches of 100.

  ***acceptance tests***
  - Processing 250 :Task: items should result in 3 batches.
  - Each batch should contain at most 100 items.
Key formatting rules:
  • The 
    ***acceptance tests***
    header is indented under the functional spec it belongs to.
  • Each test bullet is indented under the 
    ***acceptance tests***
    header.
  • Multiple acceptance tests can be listed under a single functional spec.
Acceptance Test需嵌套在其验证的functional spec下，使用
***acceptance tests***
子章节：
plain
***functional specs***
- The system should process :Task: items in batches of 100.

  ***acceptance tests***
  - Processing 250 :Task: items should result in 3 batches.
  - Each batch should contain at most 100 items.
关键格式规则：
  • ***acceptance tests***
    标题需缩进至其所属的functional spec下方。
  • 每个测试项目符号需缩进至
    ***acceptance tests***
    标题下方。
  • 单个functional spec下可列出多个Acceptance Test。

Rules

规则

Conformance with the Functional Spec

与Functional Spec的一致性

An acceptance test is essentially an example that illustrates the functional spec — it clarifies intent by showing a concrete scenario. It may imply minor code changes, but those should not be substantial. The acceptance test must be consistent with the functional spec it is nested under. If the acceptance test asserts behavior that contradicts, narrows, or extends the functional spec in ways not implied by it, the system will reject it as a conflicting acceptance test. Before writing, re-read the parent functional spec and ensure every assertion in the acceptance test is a direct, logical consequence of what the spec states.
Functional spec:
- The system should return :Resource: items sorted by creation date in descending order.

Good (consistent):
- The first :Resource: in the response should have the most recent creation date.

Bad (contradicts the spec — the spec says descending, not ascending):
- The first :Resource: in the response should have the oldest creation date.

Bad (extends beyond the spec — the spec says nothing about limiting results):
- The response should contain at most 50 :Resource: items.
Acceptance Test本质上是阐释functional spec的示例——它通过展示具体场景来明确意图。它可能暗示微小的代码变更，但不应涉及重大变更。Acceptance Test必须与其嵌套的functional spec保持一致。如果Acceptance Test断言的行为与functional spec相矛盾、缩小或扩展了未被暗示的范围，系统会将其视为冲突的Acceptance Test并拒绝。在编写前，请重新阅读父级functional spec，确保Acceptance Test中的所有断言都是该规范所述内容的直接、逻辑推导结果。
Functional spec:
- The system should return :Resource: items sorted by creation date in descending order.

Good (consistent):
- The first :Resource: in the response should have the most recent creation date.

Bad (contradicts the spec — the spec says descending, not ascending):
- The first :Resource: in the response should have the oldest creation date.

Bad (extends beyond the spec — the spec says nothing about limiting results):
- The response should contain at most 50 :Resource: items.

Scope

范围

Each acceptance test verifies a specific, observable aspect of the functional spec it's nested under. Do not test behavior from other functional specs.
每个Acceptance Test仅验证其嵌套的functional spec的特定可观察方面。请勿测试其他functional spec的行为。

Testability

可测试性

Every acceptance test must describe a concrete, verifiable outcome — not a vague quality. The test should be implementable as an automated conformance test.
Good: - The response should contain exactly 3 items.
Bad:  - The response should be correct.
每个Acceptance Test必须描述具体、可验证的结果——而非模糊的质量要求。该测试应可实现为自动化一致性测试。
Good: - The response should contain exactly 3 items.
Bad:  - The response should be correct.

Language Agnosticism

语言无关性

Like functional specs, acceptance tests must be written in terms of behavior and outcomes — not language-specific constructs.
与functional spec一样，Acceptance Test必须以行为和结果为表述依据——而非特定语言的构造。

Relationship to Test Reqs

与测试要求的关系

Acceptance tests extend conformance tests and are implemented according to the 
***test reqs***
specification. They do not replace test reqs — they add spec-specific verification on top of the general testing framework defined there.
Acceptance Test是对一致性测试的扩展，需根据
***test reqs***
规范实现。它们不会替代测试要求——而是在通用测试框架之上添加针对特定规范的验证。

Validation Checklist

验证检查清单

  • Every assertion is a direct logical consequence of the parent functional spec
  • No assertion contradicts, narrows, or extends beyond the parent spec
  • Acceptance test illustrates the spec via example, not introducing substantial new behavior
  • Nested under the correct functional spec
  • Indentation is correct (
    ***acceptance tests***
    indented under the spec)
  • Each test describes a concrete, verifiable outcome
  • Tests are scoped to the parent functional spec only
  • Written in language-agnostic terms
  • No duplication with existing acceptance tests on the same spec
  • 所有断言均为父级functional spec的直接逻辑推导结果
  • 无断言与父级规范相矛盾、缩小或扩展其范围
  • Acceptance Test通过示例阐释规范，未引入重大新行为
  • 嵌套在正确的functional spec下
  • 缩进正确（
    ***acceptance tests***
    缩进至规范下方）
  • 每个测试描述了具体、可验证的结果
  • 测试范围仅局限于父级functional spec
  • 以语言无关的术语编写
  • 与同一规范下的现有Acceptance Test无重复