Back to Details

prove-behavior

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Prove Behavior

验证测试行为有效性

Treat each test as evidence against a named defect.
将每个测试视为针对特定命名缺陷的证据。

Steps

步骤

Step 1 — Name the evidence

步骤1 — 命名测试证据

State:
  • the behavior to protect;
  • one plausible defect the evidence must detect;
  • the independent source of the expected behavior: a requirement, acceptance criterion, bug report, external contract, or recorded observation whose preservation is required.
Do not derive the expected result only from the implementation under test. If no independent expectation exists, identify the gap instead of encoding the current code as correct.
明确：
  • 需要防护的行为；
  • 该证据必须检测的一个合理缺陷；
  • 预期行为的独立来源：需求、验收标准、Bug报告、外部合同，或需要保留的记录观测结果。
不要仅从被测实现推导预期结果。如果不存在独立的预期，应明确差距，而非将当前代码认定为正确。

Step 2 — Decide admission

步骤2 — 确定测试准入

Check whether an existing test, type check, static check, contract check, or live verification already detects the named defect. Add or retain automated test evidence only when its unique protection is worth its execution, maintenance, and context cost.
Choose the smallest faithful observation point:
  • use a type or static check for structural guarantees;
  • use a narrow behavior test for pure logic or state transitions;
  • use an integration test with real local components when the defect crosses their boundary;
  • reserve live or end-to-end verification for behavior smaller tests cannot observe.
Require each new test to detect a distinct defect or observe a necessary boundary; a changed method or file alone does not justify one.
检查现有测试、类型检查、静态检查、契约检查或实时验证是否已能检测该命名缺陷。只有当自动化测试证据的独特防护价值超过其执行、维护和上下文成本时，才添加或保留该证据。
选择最精简的可信观测点：
  • 针对结构保障，使用类型检查或静态检查；
  • 针对纯逻辑或状态转换，使用窄范围行为测试；
  • 当缺陷跨组件边界时，使用包含真实本地组件的集成测试；
  • 仅当小型测试无法观测行为时，才使用实时或端到端验证。
要求每个新测试都能检测独特缺陷或观测必要边界；仅方法或文件变更不足以成为新增测试的理由。

Step 3 — Shape the test

步骤3 — 设计测试用例

  • Interface: Exercise the behavior through the narrowest stable interface.
  • Observation: Prefer outputs and resulting state over private helpers, call order, or mock interactions.
  • Collaborators: Use real local collaborators when they are deterministic and cheap; use fakes to control failures or interleavings, or to isolate uncontrollable, remote, destructive, or expensive boundaries.
  • Scope: Make each test describe one behavior.
  • Cases: Combine cases when they exercise the same rule and would fail for the same reason.
  • Races: Force the intended interleaving and prove readiness with an event, barrier, or queue rather than sleeps or scheduler timing.
  • 接口： 通过最窄的稳定接口验证行为。
  • 观测： 优先验证输出和最终状态，而非私有辅助方法、调用顺序或Mock交互。
  • 协作组件： 若本地协作组件具有确定性且成本低，则使用真实组件；若需控制故障或执行顺序，或隔离不可控、远程、破坏性或高成本边界，则使用模拟组件（fakes）。
  • 范围： 每个测试仅描述一种行为。
  • 用例： 当多个用例验证同一规则且会因同一原因失败时，可合并用例。
  • 竞争场景： 通过事件、屏障或队列强制预期执行顺序并验证就绪状态，而非使用休眠或调度器计时。

Step 4 — Prove sensitivity

步骤4 — 验证测试敏感性

Use the cheapest proof that the test detects its named defect:
  • Bug or test-first change: observe the test fail against the bug or missing behavior before the implementation makes it pass.
  • Completed non-obvious logic: introduce one small, plausible defect in the guarded branch, operator, state transition, fence, or ordering rule and observe the focused test fail.
  • Existing guard: when relying on an existing test whose sensitivity is unclear, introduce the named defect and observe it fail.
  • Literal round-trip: treat an explicit input and expected output, literal value, or rendered-string assertion as self-proving when a mutation would add no information.
  • Test deletion or merge: introduce the defect guarded by the removed test and confirm the retained evidence fails.
Count a failure only when the intended test runs and the named defect causes the failure; syntax, collection, setup, harness, or unrelated failures do not prove sensitivity.
Treat an intermittent result as unresolved, not as proof.
For a temporary mutation:
  1. Run the narrowest relevant test on the original implementation and confirm the selected test is collected and passes.
  2. Change only the guarded production behavior; leave unrelated user changes untouched.
  3. Confirm the mutation was applied and the mutated code still parses or compiles.
  4. Rerun the same test and require the expected assertion failure.
  5. Restore only the temporary mutation, confirm no unrelated diff changed, and rerun the same test to prove it passes again.
使用成本最低的方式证明测试能够检测其对应的命名缺陷：
  • Bug或测试先行变更： 在修复Bug或补充缺失行为前，观察测试是否失败。
  • 已完成的非显式逻辑： 在受防护的分支、操作符、状态转换、屏障或排序规则中引入一个小型合理缺陷，观察目标测试是否失败。
  • 现有防护测试： 若依赖敏感性不明确的现有测试，需引入命名缺陷并观察测试是否失败。
  • 字面往返验证： 当突变无法增加信息时，将显式输入与预期输出、字面量或渲染字符串断言视为自验证。
  • 测试删除或合并： 引入被移除测试所防护的缺陷，确认保留的证据会失败。
只有当目标测试运行且命名缺陷直接导致失败时，才算验证通过；语法错误、收集问题、环境设置、测试框架或无关失败均不能证明敏感性。
将间歇性结果视为未解决状态，而非验证通过。
临时突变验证步骤：
  1. 在原始实现上运行最相关的窄范围测试，确认目标测试被收集且通过。
  2. 仅修改受防护的生产行为；保留无关的用户变更。
  3. 确认突变已应用且变异后的代码仍可解析或编译。
  4. 重新运行同一测试，确认预期断言失败。
  5. 仅恢复临时突变，确认无无关差异变更，重新运行同一测试以证明其再次通过。

Step 5 — Report the proof

步骤5 — 提交验证报告

Return:
**Test evidence:**
- Decision: add | change | retain | reuse existing | no automated test
- Behavior: <protected behavior>
- Defect: <plausible failure>
- Source: <requirement, acceptance criterion, bug report, contract, or recorded observation>
- Proof: natural red | targeted mutation | self-proving assertion | existing evidence | live verification
- Verification: <command and result>
- Durable note: <path and reason | none>
Keep ordinary proof evidence in the report. Add a durable test comment only when it preserves a non-obvious constraint, historical escape, race mechanism, or replacement relationship that future readers cannot reconstruct from the test.
返回：
**Test evidence:**
- Decision: add | change | retain | reuse existing | no automated test
- Behavior: <protected behavior>
- Defect: <plausible failure>
- Source: <requirement, acceptance criterion, bug report, contract, or recorded observation>
- Proof: natural red | targeted mutation | self-proving assertion | existing evidence | live verification
- Verification: <command and result>
- Durable note: <path and reason | none>
将常规验证证据纳入报告。仅当需要保留未来读者无法从测试中重构的非显式约束、历史例外、竞争机制或替代关系时，才添加持久化测试注释。