图解 · 运行过程 · 工程取舍
测试是找反例，不是给代码盖绿章
为什么“测试都通过”仍可能交付错东西？
配套正文：F34基础课
动态图解 · F34
测试是找反例，不是给代码盖绿章
为什么“测试都通过”仍可能交付错东西？
测试只能验证它实际检查的行为和版本。一条只断言“不报错”的测试无法证明排除规则正确。好的测试围绕需求构造能击中错误的输入；代码修改以后，旧绿色结果也不再自动属于新版本。
反例能让错误实现暴露问题的具体输入。
回归修改破坏了本来成立的行为。
交付证据当前版本对应的检查命令、结果与范围。
输入与适用条件：构造的文件筛选任务；通配符语义须由需求明确，不在动画里偷偷改变“匹配文件名”与“匹配完整路径”的规则。
1 / 6 · 明确需求
第1步，共6步
窄屏可左右滑动图形，或点击“放大图形”。文字解释紧随图后。
不先说匹配对象与目录语义，无法判断哪个输出才正确。
本步状态由图形与说明共同给出。默认静止。用“下一步”看完解释再继续；播放到最后一步自动停止。键盘聚焦播放器后，可用左右键逐步查看、空格播放/暂停。图中颜色辅助区分，含义同时用文字注明。
逐步说明与计算记录
以下解释全部展开，与播放器使用同一份数据；不是另换输入的第二个算例。
1．明确需求
不先说匹配对象与目录语义，无法判断哪个输出才正确。
2．构造小反例
每个样本都针对一种可能的边界。
3．先看原始失败
能复现旧缺陷，才能确认后续修复没有仅仅改掉测试本身。
4．实施最小修改
问题明确时直接修补与验证，不必反复设计完整架构。
5．测试针对行为
测试要能区分正确实现和有意破坏的实现。
6．绑定版本交付
提交前确认测试对应当前文件与环境，报告尚未检查的范围。
为什么需要
减少返工和虚假完成，而非让审查循环无限增长。
怎样实现
围绕可观察行为、反例和当前版本组织验证。
可能的代价与误解
测试与实现共用同一错误假设、只测顺利路径、频繁审查无实际修复。
如何判断是否做对
故意引入一处已知错误，测试应失败；恢复后再通过。