测试用例命名与结构

术语对齐

中间件/库的"业务" = 框架外部可观察行为本身。"业务化"命名 = 领域语义化：以外部行为命名（"未 ready 的请求必须回 UNSUPPORTED"），不是产品业务语言、更不是实现细节语言。命名基准 = 项目术语表（ubiquitous language）。

用例名（底线，单元/集成一视同仁）

GWT 三段式（Given-When-Then），以领域行为表达。

内部命名（integration 行为验证类用例）

流程按"场景叙述"组织；helper/变量按术语表命名（owned_participant/late_reply/overloaded_server）。

三限定：

1. 适用范围 = 行为验证类；设施验证类（交付性/平台/工具判据）保持技术命名。
2. should 级不进门禁——风格规范非缺陷判据，审核按"建议"标注。
3. 增量应用不一次性大重命名——存量顺手改，不搞大规模 churn（git blame 污染）。

单元测试内部豁免

替身/注入（fake_clock/mock channel/畸形输入）本身是技术构造，强行业务化造作；豁免仅限内部命名，用例名仍须 GWT 行为语义。

流程 function 化（AA-FCP 边界）

附加规则：helper 无状态、输入全参数化（测试间不共享可变状态，隔离红线）；当前零重复不预先抽（YAGNI），用例上量后按需出现。

证明「已释放 / 已归零 / 可删除」的断言必须配正对照

断言资源已释放（句柄数归零、可删除标志、计数回 0）时，只有「删掉释放步骤后它变红」不算证据：红可能红在别的字段上——实测过一条 host_deletable 判据，变异后红在 teardown 标志而非 delete_rc，于是「未释放会被发现」仍只是推理。

正对照的写法：在资源还活着时跑同一条判据，确认它给出另一个值（红的或非零的），再跑释放后的那次。两次输出都进证据；缺正对照的判据按「不可判」处理，不签通过。