把缺少模块边界也作为问题

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

共享计数器在两个调用方同时更新时丢失一次更新，但现有测试每次为单个调用方创建独立计数器。测试始终通过，却无法锁定实际竞争。

具体做法

保留可复现的输入、调度与共享状态身份，检查现有测试边界能否覆盖真实两调用方链。若不行，明确记录缺少共享协调边界及为何当前测试无关；提出最小双调用方harness，用可控调度比较最终计数。继续使用有意义的现有检查，但覆盖未补前报告不完整。结构调整需在授权范围内实施。

反例

增加一个独立计数器单元测试并说竞争已永久覆盖，不说明共享状态差异。

改进写法

指出当前每调用方独立计数器无法复现共享竞争。为同一计数器的两个更新建立最小可控调度测试，旧行为应得到1而期望2；保留复现和缺失边界记录。未建立双调用方检查前，标回归覆盖不足。

为什么这样改

验证边界若排除了触发条件，更多绿色测试也不会提高该缺陷的覆盖。把缺失边界作为发现，能说明阻碍修复持久验证的结构原因。

如何验证

教学调度让两个调用方都先读0再写1，最终1；正确原子更新应为2。检查harness确实使用同一计数器且覆盖冲突交错，不让mock直接返回期望数。这里是测试设计，非真实执行记录。

适用边界

缺理想边界不等于停止所有验证；可先保留最小复现和已有有效检查。并发问题可能依赖进程、存储或网络条件，内存harness只证明所模拟的交错。不要仅为测试暴露过多内部接口。