先确认测试因缺少目标行为而失败

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

使用场景

表单接受空邮箱，目标是拒绝并显示 required 错误，合法地址仍可保存。教学函数 submitEmail 的目标返回空输入 saved=false、error=required，正常地址 saved=true。测试需要先证明能抓到缺失行为，不是先修代码再围绕它写一个会过的断言。

具体做法

按真实输入和可观察结果写行为断言，在旧实现运行并检查失败原因。错误必须来自未满足的行为或所需实现，非无关导入、语法或环境错误。最小实现使同一断言通过，再运行项目相关/规定检查，绿色时才整理结构。必要的编译期失败也要确实指向目标契约。

反例

先修改 submitEmail，再只断言当前函数能被调用。把测试文件导入失败当作 RED，并据此称回归测试有效。

改进写法

为教学 submitEmail 写空邮箱拒绝断言：saved=false 且 error=required；正常 a@example.test 仍 saved=true。先运行在旧实现，确认失败因为空输入被保存，而非测试准备错误。再实现所需规则，重跑同一断言与约定项目检查。记录旧/新版本及 RED/GREEN 输出；无真实运行不称已证明回归。

为什么这样改

预期行为失败证明测试对原问题敏感。随后同一断言转绿，才有依据说明修改满足了这项要求；一个泛泛不崩溃测试或导入错误都不能建立这种联系。

如何验证

教学失败信息应指出空输入实际 saved=true 与期望 false 的差异；GREEN 时空/正常契约都满足。语法或依赖错误需先解决测试环境，不能计为症状失败。

检查结果对应实际运行的代码版本，项目其他规定失败仍需报告，不把单个绿色断言叫所有要求通过。

适用边界

是否加测试取决于实际行为风险，避免为纯措辞建立机械匹配测试。不要删除无关用户工作来制造 RED；本篇仅设计教学断言，未运行真实表单。