测试中的stdout是在真实环境下运行Perforce命令行所采集的标准输出（stdout）样本，通过Mock Perforce 对象，我们可以轻易地控制changes 方法的返回值，让验证解析逻辑的正确性变得非常容易，采用Mock技术使开发者无需顾忌Perforce服务器存在与否，而且可以采用不同的 stdout 来覆盖不同的情况。

      然而危机就在这看似完美的测试过程中被埋下了。事实上 Perforce stdout 中的时间格式会依用户环境的设定而变化，从而进一步导致 parseChanges方法中的解析逻辑出现异常。由于协助车辆直线运行软件开发测试中的 stdout 全由假设得来，并不会依照环境变化，即使我们将测试在多种不同的环境中运行也没能发现问题，最终在产品环境才由客户发现并报告了这个缺陷。

      真实 Perforce 对象的行为与测试所使用的 Mock 对象行为不一致是出现上述问题的根本原因。被模拟对象的行为与真实对象的行为必须完全一致称之为Mock对象的行为依赖风险。致远服软认为：http://www.soft8.com.cn/开发者对API的了解不够、被模拟对象的行为发生变化（重构、添加新功能等修改等都可能引起被模拟对象的行为变化）都可能导致错误假设（与真实对象行为不一致），错误假设会悄无声息地引入缺陷并留下非法测试。非法测试在这里所代表的含义是，它看起来很像测试，运行起来很像测试，几乎没有价值，几乎不会失败。在开发中，规避行为依赖风险最常见的方法是编写功能测试。

      由于在进行大连微信在线支付开发测试时，开发者在层与层之间不断做出假设，而端到端的功能测试由于贯穿了所有层，可以验证开发者是否做出了正确的假设。然而功能测试编写复杂、运行速度慢、维护难度高，因此大部分产品的功能测试都非常有限。那些通过Mock测试的逻辑，便如同埋下的一颗颗定时炸弹，如何能叫人安心地发布产品呢？

      《UNIX 编程艺术》中有一句话“先求运行，再求正确，最后求快”，正确运行的测试是高质量、可以快速进行协助车辆直线运行软件开发测试的基础，离开了正确性，速度和隔离性都是无根之木，无源之水。那么采用真实环境就意味着必须承受脆弱而缓慢的测试吗？

      经历了一段时间的摸索，这个问题的答案渐渐清晰起来了，真实环境的协助车辆直线运行软件开发测试之所以痛苦，很大程度上是由于我们在多进程、多线程的环境下对编写测试没有经验，不了解如何合理地使用资源（所谓的资源可能是文件、数据库中的记录，也可能是一个新的进程等），对于我们，Mock测试作为“银弹”的作用更多地体现在通过屏蔽运行在单独进程或者线程中的资源，将测试简化为对大脑友好的单线程运行环境。在修复过足够多的脆弱测试后，我们发现了编写健壮测试的秘密，接下来详细说明。