服务桩的关键是保持极简，而非追求逼真

企业系统常常依赖不受自己控制的第三方服务（信用评分、税率查询、价格引擎），这类服务行为不可预知、往往还是远程调用，会拖慢开发（干等结果）、拖累测试（服务不稳定时测试根本跑不起来，进而拖慢整个开发周期）。解法是在测试时用一个跑在本地、内存里、快得多的服务桩替代真实服务——先用分离接口给这个服务定义好访问点（是接口而不是具体类），这样才能同时存在”调用真实服务”和”服务桩”两种实现，用插件方式在测试和生产环境间切换。作者反复强调的核心原则是：编写服务桩的关键在于尽可能简单，复杂性只会毁掉你想达成的目的——书中以销售税服务为例，最简版的服务桩只需几行代码就能对所有请求返回统一税率；即便要模拟”某些州的某些产品免税”这种更贴近真实规则的行为，最简单的做法也不过是加一个条件判断，对固定的地址/产品组合判定免税，所有测试用例共用同一批数据即可；即便升级成更灵活的版本——维护一个”免税组合列表”、允许测试用例动态往里追加——全部代码量依然只有十来行。这里有一个值得记住的实现细节：动态服务桩通常需要一个setup方法，让测试用例往里追加原始接口没有的免税组合，这个方法必须挂在入口类上才能被插件机制正确加载；但这样一来就得留意，一旦入口切换成调用真实服务的实现，所有本该只在测试环境下才被调用的这类setup方法，都应该在被误调用时直接抛出断言失效，而不是悄悄什么都不做——避免生产环境里误用了本该只存在于测试路径的接口。可迁移启发：为被测系统搭建假实现（服务桩/Mock）时，最容易踩的坑是不自觉地把它做得越来越”像真的”，直到它自己也变成一套需要维护的复杂逻辑——服务桩存在的全部意义就是”够用就好、越简单越好”，一旦发现自己在给服务桩添加复杂特性，就该停下来想想这是否已经背离了它本该服务的目的。