一次面试候选人我问了一道自己一直很偏爱的问题单元测试里的Simulator、Test driver、Stub到底分别解决什么问题大部分人聊到Stub都能说几句再往下问一句“那为什么还需要Test driver”十个里有八个会卡住。这事不怪候选人平时开发里大家习惯用Mock一个词把替身全部盖过去了等真正落到代码评审上才露馅——有的桩写得太厚直接长成了一个小模拟器有的测试驱动代码写得比业务代码还绕跑一次能浪费半天。所以这篇就当是我复盘之后给团队讲的一套口径三个名字各自的责任边界是什么、最常见的写错姿势有哪些最后用一套真实业务系统的测试代码把它们串起来。适用对象很明确刚搭过几个单测、看过Mockito和pytest文档但对“替身如何组织”还没有系统认知的同学以及想给团队梳理测试替身策略的工程师。1. 先摆清楚三者坐标谁驱动、谁响应、谁模仿这三个词之所以经常被并列提起是因为它们在一次单元测试执行里处于三个完全不同的位置。把一次单元测试拆开看会得到这样一条调用链测试执行环境 - 测试驱动器Test Driver - 被测单元SUT - 外部依赖数据库、支付、缓存等关键区别在箭头两端Test Driver是被测单元的“上游”主动发起调用负责把被测单元跑起来。Stub和Simulator是被测单元的“下游”它们挡住真实外部依赖负责在被测单元调用时给出某种响应。Stub和Simulator的差别在于响应方式Stub给固定答案Simulator按规则模拟真实系统的状态变化。换句话说三角形里两个角色是“替身”一个角色是“驾驶员”。很多人把概念搞混是因为只看“替身”不看“谁在开车”。1.1 为什么单元测试需要替身出场先明确替身存在的根本原因单测要验证的对象是“被测单元自身的逻辑”不是验证整个分布式系统能不能转起来。如果被测服务里真实地连了MySQL、真实地调了第三方支付接口测试结果就会被网络抖动、数据库库存、上游接口升级影响这已经变成集成测试了。更令人头疼的是异常分支没法稳定复现想测支付超时得专门让网关超时想测库存不足还得先把数据库库存改成不足。替身出现就是为了把环境不确定性挡在测试之外让被测单元在完全可控的沙箱里运行。很多人把这个过程笼统叫“Mock”但工程实践里替身内部有明确分化。最经典的划分来自《xUnit Test Patterns》作者Gerard MeszarosDummy、Fake、Stub、Spy、Mock。今天要细讲的Simulator本质上更接近Fake与Spy的混合物但它有自己的工程价值逻辑甚至可以说它是替身体系里投入产出比最高的一种形态。1.2 一张表看清三角色差异角色英文职责方向核心特征生活类比测试驱动器Test Driver主动驱动被测单元构造被测对象、触发方法、断言结果开车的人桩Stub被动响应用户操作返回预设固定结果不验证交互次数只会说“好的”的接线员开发模拟器Simulator按规则复制外部世界的状态与行为有状态、有规则、能复现异常场景整个仿真训练场这张表建议直接截图存下来。平时评审测试的时候我判断一个替身该叫Stub还是叫Simulator就看它是否拥有“状态和行为规则”。一个只会返回True的类不管名字里带不带“Mock”本质就是Stub一个能随余额减少、能模拟超时异常的类才是Simulator。1.3 三个高频误解误解一Stub就是Mock。它俩根本不在一层。Stub是“回答者”Mock是“考官”——Mock要校验被测单元有没有按预期参数调用它Stub只负责给个回答让流程走通。很多Mock框架能创建Stub风格的替身那是因为框架同时提供了两种能力不代表两个词是一回事。误解二单元测试里不该出现Simulator。这个偏见很常见事实上当被测单元对外部依赖的状态变化敏感时一个带状态的轻量模拟器往往是性价比最高的选择远比用Mock去编排一堆thenReturn要清晰。误解三Test Driver就是测试框架本身。JUnit、pytest只是跑腿的基础设施真正驱动被测单元的是测试用例函数里那段“构造对象、调方法、写断言”的代码。框架只是把测试方法调起来driver是那个真正按下业务动作按钮的人。2. Stub不是全部替身只是特定语境下的“预设应答机”桩是测试替身里最朴素、最基础的一种。它的全部职责只有一个被测单元调用依赖的时候给出一个预设好的回答。注意是“回答”不是“验证”。桩不关心被测单元调了它几次、传了什么参数、有没有漏掉某个调用它只负责用固定结果把被测单元的逻辑支起来。打个比方你去电话亭打内部专线对面接线员全程只说一句“在”你打多少次都是这个答复。被测单元只要听到“在”就继续往下走自己的流程。2.1 桩的核心逻辑返回值由谁说了算一个最小桩示例比如被测订单服务依赖库存系统class InventoryStub: def withdraw(self, items): # 不管items是什么都回答“库存充足” return True这个类的精髓在于把真实库存系统里的数量判断、锁库存、写流水全部砍掉只保留一个调用入口和固定返回。被测单元不需要知道库存系统内部怎么实现它只关心“withdraw()返回的布尔值够不够”。如果想让同一根桩同时覆盖成功和失败路径稍微带一个构造参数就行class InventoryStub: def __init__(self, available: bool True): self.available available def withdraw(self, items) - bool: return self.available测试里写InventoryStub(availableFalse)就能触发“库存不足”分支不需要为每个分支单独建类这也是最常用的Stub写法。2.2 桩与Mock的边界一个应答一个考核桩和Mock是测试替身里最容易混淆的一对我特意放在一个代码块里对比# Stub只负责回答 class PaymentStub: def charge(self, token, amount): return PaymentResult(SUCCESS) # Mock先回答再验证被测单元是否按预期调用 from unittest.mock import Mock pay_mock Mock() pay_mock.charge.return_value PaymentResult(SUCCESS) # ...被测代码执行后... pay_mock.charge.assert_called_once_with(token_abc, 100)看出差别了吗Stub写完就完了它不问你到底有没有调用Mock还要检查调用次数、调用参数本质是给依赖上“纪律”。选型时不需要过度纠结记住一个简单标准这个替身是只让流程跑通还是要校验交互过程前者Stub后者Mock。2.3 什么时候选桩最合适我个人的经验是当被测单元对依赖的需求仅仅是“返回一个值来决定分支走向”时Stub是最优解。典型场景有读配置开关true走A逻辑、false走B逻辑桩给一个布尔值。依赖返回固定数据对象比如查询用户信息桩直接返回写死的用户结构。被测单元不关心依赖内部状态只关心结果能否用于下一步运算。还有一个容易被忽视的点Stub不需要Mock框架。手写一个十来行的类就是很好的桩用了Mockito/pytest-mock反而增加阅读负担。过度使用Mock框架去做桩该做的事是团队测试代码变难读的头号原因之一。3. Test Driver单元测试的正面发动机比想象中更容易忽略如果说Stub是“下游替身”那Test Driver就是唯一站在被测单元上游的角色。它的任务特别直白把被测单元构造出来、给它塞好替身、触发业务方法、最后断言结果。没有这一步前面所有替身都是摆设。但正因为太直白很多人反而不把它当成一个值得讨论的角色。我见过不少团队的测试代码事情全做对了却因为driver职责不清而维护困难。3.1 测试驱动器与测试框架的分工必须分清测试框架JUnit、pytest、TestNG负责发现测试方法、执行测试方法、收集结果。它是跑腿的。Test Driver负责在你写的每个测试方法里主动“驱动”被测对象干活。框架说“这个测试方法现在开始执行了”driver说“我现在就调用订单服务的下单方法把结果拿回来断言”。很多人理解不了这一层是因为框架把driver从你的眼前抹掉了——你以为自己在写测试用例实际上你写的就是driver本身。3.2 驱动器的两种形态框架内用例与独立驱动程序形态一框架内的测试用例。这是最常见的driver形态。def test_place_order_success(): inv InventoryStub(availableTrue) pay PaymentStub(statusSUCCESS) service OrderService(inventoryinv, paymentpay) result service.place_order(user_id1, items[...], tokentok_a) assert result ORDER_PLACED这个测试函数体就是driver构造被测对象、注入两个替身、调place_order、断言返回值。节奏非常清楚准备、动作、断言。形态二独立驱动程序。常见于开发期调试我会留一个非常薄的main入口# dev_driver.py def main(): service OrderService(InventoryStub(), PaymentSimulator()) result service.place_order(user_id1, itemsITEMS, tokentok_a) print(RESULT:, result) if __name__ __main__: main()这个思路很好用不想每次开测试框架、不想跑整个pytest套件只想快速复现某个调用路径时直接跑这个脚本。等问题定位完了这个脚本可以留着当调试入口也可以删掉它不是测试资产只是开发期的临时驾驶员。3.3 怎么判断driver写得好不好我做测试评审时只看三条driver是不是足够薄。driver的代码量应该远小于被测单元本身。如果driver里开始出现大段数据处理、条件分支、循环那大概率是把集成逻辑写进了测试代码或者被测对象的API设计有问题。driver的关键步骤顺序是否正确。构造被测单元、注入替身、调用业务方法、断言结果四步顺序乱掉往往意味着driver里混进了不该有的业务准备逻辑。driver断言是否对准被测单元的输出。如果一大半断言在检查替身内部状态说明测试重心跑偏了——替身是辅助不是被测对象本身。一条我踩过坑换来的经验不要在一个driver方法里跑完整个业务链条再统一断言。改成每触发一个关键动作就立刻断言中间结果虽然每个测试方法会长一点但失败定位快得多我后面会专门写这个。4. Simulator当桩无法表达状态与行为时值得认真对待的局部“替身世界”桩有个天生短板它只能给固定回答。可真实外部依赖几乎总是有状态的。举个例子支付网关的返回值不是简单一个“SUCCESS”或“FAILED”就能描述清楚的。它可能是第一次请求超时、重试后成功也可能账户余额不足、连续三次都会被拒还可能因为同一笔订单重复提交触发幂等冲突。这些行为里既有状态变化也有业务规则一个无状态的Stub根本复制不了。这时候要请出Simulator也就是标题里的“开发模拟器”。4.1 模拟器与桩的本质差异状态、规则与异常注入桩的世界观是一张静态卡片你问我答答完结束。模拟器的世界观是一套迷你运行环境你有余额的初始值有调用后的扣减规则有特定标记时触发超时还能记录所有调用历史。我还想解释一下“开发模拟器”里的“开发”两个字这类Simulator不仅在单元测试时用在开发期本地调试、联调前的自测、甚至演示环境里都会用到。它是为了“开发”而造的模拟系统测试只是它服务的场景之一。一个支付网关模拟器核心骨架大概长这样import time from dataclasses import dataclass dataclass class PaymentResult: status: str reason: str class PaymentTimeoutError(Exception): pass class PaymentSimulator: def __init__(self, initial_balance: float 1000, timeout_tokens: set None): self.balance initial_balance self.timeout_tokens timeout_tokens or set() self.call_history [] def charge(self, token: str, amount: float) - PaymentResult: self.call_history.append({token: token, amount: amount}) if token in self.timeout_tokens: raise PaymentTimeoutError() if self.balance amount: return PaymentResult(INSUFFICIENT_FUNDS, balance_not_enough) self.balance - amount return PaymentResult(SUCCESS)这个模拟器已经有三个关键能力状态余额会随成功扣减而变化不同用例先后执行同一个模拟器实例行为会受影响。规则余额不足时稳定返回INSUFFICIENT_FUNDS不用人为去抢异常时机。故障注入传入timeout_tokens就能指定某些token必然触发超时稳定复现网络故障分支。如果再加一个delay_seconds参数、加一个“第N次调用成功”的规则就能模拟更复杂的重试场景相比Mock去一层层thenReturn这种直觉好得多。4.2 模拟器与桩的边界其实是一条连续谱写到这里需要摊开说工程里Stub和Simulator没有泾渭分明的分界线更像一条连续谱。依赖只有“返回值”语义时桩就够了依赖开始有状态、有规则、需要复现多个异常分支时桩自动长成模拟器。你今天写的一个带available开关的库存桩明天为了复现“先超时后成功”就会给它加一个fail_times计数器——恭喜它已经从桩向模拟器迁移了。不必纠结命名对错只要团队都理解“这根替身现在掌握了多少行为规则”。评审时我往往这样问这个替身是只给固定返回值还是已经从早前的静态回答长成了带状态的行为模拟如果已经开始模拟真实业务规则就把它当Simulator来管理和维护成本核算。4.3 模拟器的维护边界什么时候别上模拟器模拟器不是免费的。它是一段需要持续维护的代码要跟上真实依赖的契约变化否则测试全绿、生产爆炸就是模拟器内容过期。我建议用一个成本决策表来选型想测的场景外部依赖复杂度替身选择维护成本只决定代码分支走向低Stub极低有状态、有重试、有多分支异常中Simulator中外部依赖行为细节未知高真实依赖 契约测试高但可控所以什么时候别上模拟器当依赖的逻辑复杂到你几乎需要重写一套业务系统时停下来。物极必反那个模拟器很快就变成“第二个被测系统”维护它比写被测代码还累后面你不光要修业务bug还要修模拟器的bug。这种时候应该考虑刀具更高层的手段把被测依赖的消费面抽窄、对真实服务做契约测试、或者用录制的真实流量做回放测试。模拟器只是手段不是目的。5. 一个订单服务案例三者混用的完整拆解前面分开讲概念这一节完整构建一个真实业务场景把三个角色全部放进同一个舞台。需求背景很简单一个订单服务用户下单时先扣库存再调支付网关收款。库存扣减失败直接返回缺货扣减成功但支付失败需要回滚库存并返回支付失败原因全链路成功才返回下单成功。5.1 被测对象与外部依赖梳理被测对象是OrderService它有两个外部依赖InventoryService扣库存和PaymentGateway收款。为了让替身能替换两个依赖必须通过构造函数注入而不是在OrderService内部直接new出来这是整个测试能成立的前提。class InventoryService: def withdraw(self, items) - bool: ... def refund(self, items) - None: ... class PaymentGateway: def charge(self, token: str, amount: float) - PaymentResult: ...被测单元实现class OrderService: def __init__(self, inventory: InventoryService, payment: PaymentGateway): self.inventory inventory self.payment payment def place_order(self, user_id: int, items: list, payment_token: str) - str: total sum(item[price] * item[count] for item in items) if not self.inventory.withdraw(items): return OUT_OF_STOCK result self.payment.charge(payment_token, total) if result.status ! SUCCESS: self.inventory.refund(items) return fPAYMENT_FAILED:{result.reason} return ORDER_PLACED这里故意把价格换算逻辑放在被测单元内部因为它是“被测试的业务规则”不属于driver也不属于替身。5.2 依赖注入与替身装配库存依赖只回答“够不够”状态极简用桩class InventoryStub: def __init__(self, available: bool True): self.available available self.called_items None def withdraw(self, items) - bool: self.called_items items return self.available def refund(self, items) - None: pass支付依赖有余额、有超时开关、有调用记录用轻量模拟器class PaymentSimulator: def __init__(self, balance: float 1000, timeout_tokens: set None): self.balance balance self.timeout_tokens timeout_tokens or set() self.calls [] def charge(self, token: str, amount: float) - PaymentResult: self.calls.append({token: token, amount: amount}) if token in self.timeout_tokens: raise PaymentTimeoutError() if self.balance amount: return PaymentResult(INSUFFICIENT_FUNDS, balance_not_enough) self.balance - amount return PaymentResult(SUCCESS)注意一个细节InventoryStub里多了一个called_items字段把最近一次调用参数记录下来。虽然它名义上还是桩但为了验证“支付失败后有没有原样回滚库存”测试需要检查这个记录的参数是否等于传入的items。这个需求让我们的桩兼职做了Spy的活。工程里一个替身混用多种形态很常见不必因为名字洁癖去建一堆类。5.3 测试运行结果与分析完整的Test Driver写在测试文件里每个测试函数就是一个driverdef test_place_order_success_deducts_balance(): inv InventoryStub(availableTrue) pay PaymentSimulator(balance500) service OrderService(inventoryinv, paymentpay) items [{sku: BOOK-01, price: 100, count: 1}] result service.place_order(user_id1, itemsitems, payment_tokentok_ok) assert result ORDER_PLACED assert pay.balance 400 assert pay.calls [{token: tok_ok, amount: 100}] def test_place_order_payment_failed_then_refund_inventory(): inv InventoryStub(availableTrue) pay PaymentSimulator(balance50) service OrderService(inventoryinv, paymentpay) items [{sku: BOOK-01, price: 100, count: 1}] result service.place_order(user_id1, itemsitems, payment_tokentok_ok) assert result PAYMENT_FAILED:balance_not_enough assert inv.called_items items两个用例的driver结构完全一致构造SUT、注入替身、调用被测方法、分步断言。所有内容组合在一起是一次完整的三者协作演示Test Driver负责开车InventoryStub负责给库存答案PaymentSimulator负责模拟支付状态和失败分支。你可能会问这两个测试里用了同一个PaymentSimulator实例它的余额状态变了会不会影响后续测试这取决于你每个测试是新建实例还是复用。在pytest里每个测试函数里的局部变量每次执行都重新创建所以互相不影响。如果放在类级别的共享实例里就必须设计好reset机制否则状态会在用例之间“串味”这也是模拟器最容易翻车的地方之一。6. 容易踩的坑过度桩替身、模拟器维护成本与测试退化最后一节聊我在实际项目里亲眼见过的几类翻车现场。每个坑踩进去都挺疼而且症状往往不是“测试红”而是“测试看起来很绿”。6.1 桩替身过度测试到底在验证谁有一种测试写多了以后非常危险因为被测单元依赖很多测试代码为了省事给所有依赖全部塞上桩。结果是什么被测单元的每个分支都被桩的返回值“指定”好了测试跑完你都无法判断被测单元有没有真的执行到关键逻辑。识别办法很简单故意把被测单元里的一行关键逻辑改错然后跑测试。如果测试仍然全绿说明那些用例根本没有让被测逻辑真正发挥作用纯属自嗨。我以前接手过一个老服务核心的折扣计算逻辑被改坏十几个测试全绿就是因为大部分断言都在验证桩的返回值而不是被测方法的输出。那次之后我的评审标准里多了一条写测试时必须至少测到一个“由被测单元自己算出来的值”而不只是透传替身的回答。桩替身适度做法可以记成一句话桩负责把环境稳定住但要确保被测单元的每一行代码都有机会被真实执行并断言。6.2 Test driver职责蔓延别让驱动代码变成待测代码driver的本分是“薄”。但总有人潜意识里想写成“全自动测试机器人”一个driver里做一堆前置数据准备、状态编排、结果后处理。写的时候挺爽后续维护苦不堪言因为driver自身开始包含复杂逻辑driver本身的bug又成了测试失败的新来源而且极难定位。我见过一个极端的例子一个测试driver为了构造请求体内部写了循环、字典合并、时间戳格式化占了两百行。后来请求体格式变更测试driver先崩了。这就是“驱动代码”长成了“待测代码”的典型信号。正确的姿势是让driver保持单薄只做“构造被测对象、调方法、断言”三件事。复杂的数据准备放到独立的fixture或工厂里要和driver本身的逻辑彻底分开。6.3 模拟器维护成本失控从“绿色测试”到“虚假绿灯”Simulator最大的隐性风险是契约漂移模拟器内部的行为规则和真实依赖的线上行为不一致了但测试仍然全绿。举个例子真实支付网关在余额不足时会返回一个错误码而支付模拟器因为版本没跟上返回的却是另一个错误码。被测单元对错误码的解析逻辑其实已经过时可模拟器还在按新契约返回测试就是能跑通上线就炸。我的应对方式分两层。第一层是在模拟器代码里写清“契约版本”在类注释里标注它对标的外部服务版本号依赖契约变更时升级模拟器的人必须同步更新测试。第二层是定期用真实服务的契约测试或者冒烟测试来校对模拟器行为哪怕一个月跑一次也比完全相信模拟器强。模拟器是给测试提供确定性的工具但它不该成为团队与真实系统之间的信息断层。6.4 这几年的落地经验写了这么多年测试代码我最终把替身策略稳定成一套很朴素的原则第一默认从最小替身开始。能用一个无状态的手写桩解决的绝不引入Mock框架桩明显撑不住、需要状态和规则时再让替身向Simulator演化。第二Stub、Simulator、Mock三种角色在代码里命名保持一致。一个类如果同时有状态和规则就别叫它XxxStub叫XxxSimulator。名字统一之后评审时读测试的成本会肉眼可见地下降。第三driver保持“一动作一断言”。不要跑到最后才断言把一次调用的多个关键结果拆开到对应步骤之后失败定位从“全局排查”直接降级成“只看这一行上下文”。这套做法最大的价值不是让单测覆盖率数字变好看而是让每个人拿到一组失败的测试时能在三分钟内看懂谁在开车、谁在应答、谁在模仿真实世界。搞清这三个角色比多背几个Mock API值钱得多。
一次面试候选人我问了一道自己一直很偏爱的问题单元测试里的Simulator、Test driver、Stub到底分别解决什么问题大部分人聊到Stub都能说几句再往下问一句“那为什么还需要Test driver”十个里有八个会卡住。这事不怪候选人平时开发里大家习惯用Mock一个词把替身全部盖过去了等真正落到代码评审上才露馅——有的桩写得太厚直接长成了一个小模拟器有的测试驱动代码写得比业务代码还绕跑一次能浪费半天。所以这篇就当是我复盘之后给团队讲的一套口径三个名字各自的责任边界是什么、最常见的写错姿势有哪些最后用一套真实业务系统的测试代码把它们串起来。适用对象很明确刚搭过几个单测、看过Mockito和pytest文档但对“替身如何组织”还没有系统认知的同学以及想给团队梳理测试替身策略的工程师。1. 先摆清楚三者坐标谁驱动、谁响应、谁模仿这三个词之所以经常被并列提起是因为它们在一次单元测试执行里处于三个完全不同的位置。把一次单元测试拆开看会得到这样一条调用链测试执行环境 - 测试驱动器Test Driver - 被测单元SUT - 外部依赖数据库、支付、缓存等关键区别在箭头两端Test Driver是被测单元的“上游”主动发起调用负责把被测单元跑起来。Stub和Simulator是被测单元的“下游”它们挡住真实外部依赖负责在被测单元调用时给出某种响应。Stub和Simulator的差别在于响应方式Stub给固定答案Simulator按规则模拟真实系统的状态变化。换句话说三角形里两个角色是“替身”一个角色是“驾驶员”。很多人把概念搞混是因为只看“替身”不看“谁在开车”。1.1 为什么单元测试需要替身出场先明确替身存在的根本原因单测要验证的对象是“被测单元自身的逻辑”不是验证整个分布式系统能不能转起来。如果被测服务里真实地连了MySQL、真实地调了第三方支付接口测试结果就会被网络抖动、数据库库存、上游接口升级影响这已经变成集成测试了。更令人头疼的是异常分支没法稳定复现想测支付超时得专门让网关超时想测库存不足还得先把数据库库存改成不足。替身出现就是为了把环境不确定性挡在测试之外让被测单元在完全可控的沙箱里运行。很多人把这个过程笼统叫“Mock”但工程实践里替身内部有明确分化。最经典的划分来自《xUnit Test Patterns》作者Gerard MeszarosDummy、Fake、Stub、Spy、Mock。今天要细讲的Simulator本质上更接近Fake与Spy的混合物但它有自己的工程价值逻辑甚至可以说它是替身体系里投入产出比最高的一种形态。1.2 一张表看清三角色差异角色英文职责方向核心特征生活类比测试驱动器Test Driver主动驱动被测单元构造被测对象、触发方法、断言结果开车的人桩Stub被动响应用户操作返回预设固定结果不验证交互次数只会说“好的”的接线员开发模拟器Simulator按规则复制外部世界的状态与行为有状态、有规则、能复现异常场景整个仿真训练场这张表建议直接截图存下来。平时评审测试的时候我判断一个替身该叫Stub还是叫Simulator就看它是否拥有“状态和行为规则”。一个只会返回True的类不管名字里带不带“Mock”本质就是Stub一个能随余额减少、能模拟超时异常的类才是Simulator。1.3 三个高频误解误解一Stub就是Mock。它俩根本不在一层。Stub是“回答者”Mock是“考官”——Mock要校验被测单元有没有按预期参数调用它Stub只负责给个回答让流程走通。很多Mock框架能创建Stub风格的替身那是因为框架同时提供了两种能力不代表两个词是一回事。误解二单元测试里不该出现Simulator。这个偏见很常见事实上当被测单元对外部依赖的状态变化敏感时一个带状态的轻量模拟器往往是性价比最高的选择远比用Mock去编排一堆thenReturn要清晰。误解三Test Driver就是测试框架本身。JUnit、pytest只是跑腿的基础设施真正驱动被测单元的是测试用例函数里那段“构造对象、调方法、写断言”的代码。框架只是把测试方法调起来driver是那个真正按下业务动作按钮的人。2. Stub不是全部替身只是特定语境下的“预设应答机”桩是测试替身里最朴素、最基础的一种。它的全部职责只有一个被测单元调用依赖的时候给出一个预设好的回答。注意是“回答”不是“验证”。桩不关心被测单元调了它几次、传了什么参数、有没有漏掉某个调用它只负责用固定结果把被测单元的逻辑支起来。打个比方你去电话亭打内部专线对面接线员全程只说一句“在”你打多少次都是这个答复。被测单元只要听到“在”就继续往下走自己的流程。2.1 桩的核心逻辑返回值由谁说了算一个最小桩示例比如被测订单服务依赖库存系统class InventoryStub: def withdraw(self, items): # 不管items是什么都回答“库存充足” return True这个类的精髓在于把真实库存系统里的数量判断、锁库存、写流水全部砍掉只保留一个调用入口和固定返回。被测单元不需要知道库存系统内部怎么实现它只关心“withdraw()返回的布尔值够不够”。如果想让同一根桩同时覆盖成功和失败路径稍微带一个构造参数就行class InventoryStub: def __init__(self, available: bool True): self.available available def withdraw(self, items) - bool: return self.available测试里写InventoryStub(availableFalse)就能触发“库存不足”分支不需要为每个分支单独建类这也是最常用的Stub写法。2.2 桩与Mock的边界一个应答一个考核桩和Mock是测试替身里最容易混淆的一对我特意放在一个代码块里对比# Stub只负责回答 class PaymentStub: def charge(self, token, amount): return PaymentResult(SUCCESS) # Mock先回答再验证被测单元是否按预期调用 from unittest.mock import Mock pay_mock Mock() pay_mock.charge.return_value PaymentResult(SUCCESS) # ...被测代码执行后... pay_mock.charge.assert_called_once_with(token_abc, 100)看出差别了吗Stub写完就完了它不问你到底有没有调用Mock还要检查调用次数、调用参数本质是给依赖上“纪律”。选型时不需要过度纠结记住一个简单标准这个替身是只让流程跑通还是要校验交互过程前者Stub后者Mock。2.3 什么时候选桩最合适我个人的经验是当被测单元对依赖的需求仅仅是“返回一个值来决定分支走向”时Stub是最优解。典型场景有读配置开关true走A逻辑、false走B逻辑桩给一个布尔值。依赖返回固定数据对象比如查询用户信息桩直接返回写死的用户结构。被测单元不关心依赖内部状态只关心结果能否用于下一步运算。还有一个容易被忽视的点Stub不需要Mock框架。手写一个十来行的类就是很好的桩用了Mockito/pytest-mock反而增加阅读负担。过度使用Mock框架去做桩该做的事是团队测试代码变难读的头号原因之一。3. Test Driver单元测试的正面发动机比想象中更容易忽略如果说Stub是“下游替身”那Test Driver就是唯一站在被测单元上游的角色。它的任务特别直白把被测单元构造出来、给它塞好替身、触发业务方法、最后断言结果。没有这一步前面所有替身都是摆设。但正因为太直白很多人反而不把它当成一个值得讨论的角色。我见过不少团队的测试代码事情全做对了却因为driver职责不清而维护困难。3.1 测试驱动器与测试框架的分工必须分清测试框架JUnit、pytest、TestNG负责发现测试方法、执行测试方法、收集结果。它是跑腿的。Test Driver负责在你写的每个测试方法里主动“驱动”被测对象干活。框架说“这个测试方法现在开始执行了”driver说“我现在就调用订单服务的下单方法把结果拿回来断言”。很多人理解不了这一层是因为框架把driver从你的眼前抹掉了——你以为自己在写测试用例实际上你写的就是driver本身。3.2 驱动器的两种形态框架内用例与独立驱动程序形态一框架内的测试用例。这是最常见的driver形态。def test_place_order_success(): inv InventoryStub(availableTrue) pay PaymentStub(statusSUCCESS) service OrderService(inventoryinv, paymentpay) result service.place_order(user_id1, items[...], tokentok_a) assert result ORDER_PLACED这个测试函数体就是driver构造被测对象、注入两个替身、调place_order、断言返回值。节奏非常清楚准备、动作、断言。形态二独立驱动程序。常见于开发期调试我会留一个非常薄的main入口# dev_driver.py def main(): service OrderService(InventoryStub(), PaymentSimulator()) result service.place_order(user_id1, itemsITEMS, tokentok_a) print(RESULT:, result) if __name__ __main__: main()这个思路很好用不想每次开测试框架、不想跑整个pytest套件只想快速复现某个调用路径时直接跑这个脚本。等问题定位完了这个脚本可以留着当调试入口也可以删掉它不是测试资产只是开发期的临时驾驶员。3.3 怎么判断driver写得好不好我做测试评审时只看三条driver是不是足够薄。driver的代码量应该远小于被测单元本身。如果driver里开始出现大段数据处理、条件分支、循环那大概率是把集成逻辑写进了测试代码或者被测对象的API设计有问题。driver的关键步骤顺序是否正确。构造被测单元、注入替身、调用业务方法、断言结果四步顺序乱掉往往意味着driver里混进了不该有的业务准备逻辑。driver断言是否对准被测单元的输出。如果一大半断言在检查替身内部状态说明测试重心跑偏了——替身是辅助不是被测对象本身。一条我踩过坑换来的经验不要在一个driver方法里跑完整个业务链条再统一断言。改成每触发一个关键动作就立刻断言中间结果虽然每个测试方法会长一点但失败定位快得多我后面会专门写这个。4. Simulator当桩无法表达状态与行为时值得认真对待的局部“替身世界”桩有个天生短板它只能给固定回答。可真实外部依赖几乎总是有状态的。举个例子支付网关的返回值不是简单一个“SUCCESS”或“FAILED”就能描述清楚的。它可能是第一次请求超时、重试后成功也可能账户余额不足、连续三次都会被拒还可能因为同一笔订单重复提交触发幂等冲突。这些行为里既有状态变化也有业务规则一个无状态的Stub根本复制不了。这时候要请出Simulator也就是标题里的“开发模拟器”。4.1 模拟器与桩的本质差异状态、规则与异常注入桩的世界观是一张静态卡片你问我答答完结束。模拟器的世界观是一套迷你运行环境你有余额的初始值有调用后的扣减规则有特定标记时触发超时还能记录所有调用历史。我还想解释一下“开发模拟器”里的“开发”两个字这类Simulator不仅在单元测试时用在开发期本地调试、联调前的自测、甚至演示环境里都会用到。它是为了“开发”而造的模拟系统测试只是它服务的场景之一。一个支付网关模拟器核心骨架大概长这样import time from dataclasses import dataclass dataclass class PaymentResult: status: str reason: str class PaymentTimeoutError(Exception): pass class PaymentSimulator: def __init__(self, initial_balance: float 1000, timeout_tokens: set None): self.balance initial_balance self.timeout_tokens timeout_tokens or set() self.call_history [] def charge(self, token: str, amount: float) - PaymentResult: self.call_history.append({token: token, amount: amount}) if token in self.timeout_tokens: raise PaymentTimeoutError() if self.balance amount: return PaymentResult(INSUFFICIENT_FUNDS, balance_not_enough) self.balance - amount return PaymentResult(SUCCESS)这个模拟器已经有三个关键能力状态余额会随成功扣减而变化不同用例先后执行同一个模拟器实例行为会受影响。规则余额不足时稳定返回INSUFFICIENT_FUNDS不用人为去抢异常时机。故障注入传入timeout_tokens就能指定某些token必然触发超时稳定复现网络故障分支。如果再加一个delay_seconds参数、加一个“第N次调用成功”的规则就能模拟更复杂的重试场景相比Mock去一层层thenReturn这种直觉好得多。4.2 模拟器与桩的边界其实是一条连续谱写到这里需要摊开说工程里Stub和Simulator没有泾渭分明的分界线更像一条连续谱。依赖只有“返回值”语义时桩就够了依赖开始有状态、有规则、需要复现多个异常分支时桩自动长成模拟器。你今天写的一个带available开关的库存桩明天为了复现“先超时后成功”就会给它加一个fail_times计数器——恭喜它已经从桩向模拟器迁移了。不必纠结命名对错只要团队都理解“这根替身现在掌握了多少行为规则”。评审时我往往这样问这个替身是只给固定返回值还是已经从早前的静态回答长成了带状态的行为模拟如果已经开始模拟真实业务规则就把它当Simulator来管理和维护成本核算。4.3 模拟器的维护边界什么时候别上模拟器模拟器不是免费的。它是一段需要持续维护的代码要跟上真实依赖的契约变化否则测试全绿、生产爆炸就是模拟器内容过期。我建议用一个成本决策表来选型想测的场景外部依赖复杂度替身选择维护成本只决定代码分支走向低Stub极低有状态、有重试、有多分支异常中Simulator中外部依赖行为细节未知高真实依赖 契约测试高但可控所以什么时候别上模拟器当依赖的逻辑复杂到你几乎需要重写一套业务系统时停下来。物极必反那个模拟器很快就变成“第二个被测系统”维护它比写被测代码还累后面你不光要修业务bug还要修模拟器的bug。这种时候应该考虑刀具更高层的手段把被测依赖的消费面抽窄、对真实服务做契约测试、或者用录制的真实流量做回放测试。模拟器只是手段不是目的。5. 一个订单服务案例三者混用的完整拆解前面分开讲概念这一节完整构建一个真实业务场景把三个角色全部放进同一个舞台。需求背景很简单一个订单服务用户下单时先扣库存再调支付网关收款。库存扣减失败直接返回缺货扣减成功但支付失败需要回滚库存并返回支付失败原因全链路成功才返回下单成功。5.1 被测对象与外部依赖梳理被测对象是OrderService它有两个外部依赖InventoryService扣库存和PaymentGateway收款。为了让替身能替换两个依赖必须通过构造函数注入而不是在OrderService内部直接new出来这是整个测试能成立的前提。class InventoryService: def withdraw(self, items) - bool: ... def refund(self, items) - None: ... class PaymentGateway: def charge(self, token: str, amount: float) - PaymentResult: ...被测单元实现class OrderService: def __init__(self, inventory: InventoryService, payment: PaymentGateway): self.inventory inventory self.payment payment def place_order(self, user_id: int, items: list, payment_token: str) - str: total sum(item[price] * item[count] for item in items) if not self.inventory.withdraw(items): return OUT_OF_STOCK result self.payment.charge(payment_token, total) if result.status ! SUCCESS: self.inventory.refund(items) return fPAYMENT_FAILED:{result.reason} return ORDER_PLACED这里故意把价格换算逻辑放在被测单元内部因为它是“被测试的业务规则”不属于driver也不属于替身。5.2 依赖注入与替身装配库存依赖只回答“够不够”状态极简用桩class InventoryStub: def __init__(self, available: bool True): self.available available self.called_items None def withdraw(self, items) - bool: self.called_items items return self.available def refund(self, items) - None: pass支付依赖有余额、有超时开关、有调用记录用轻量模拟器class PaymentSimulator: def __init__(self, balance: float 1000, timeout_tokens: set None): self.balance balance self.timeout_tokens timeout_tokens or set() self.calls [] def charge(self, token: str, amount: float) - PaymentResult: self.calls.append({token: token, amount: amount}) if token in self.timeout_tokens: raise PaymentTimeoutError() if self.balance amount: return PaymentResult(INSUFFICIENT_FUNDS, balance_not_enough) self.balance - amount return PaymentResult(SUCCESS)注意一个细节InventoryStub里多了一个called_items字段把最近一次调用参数记录下来。虽然它名义上还是桩但为了验证“支付失败后有没有原样回滚库存”测试需要检查这个记录的参数是否等于传入的items。这个需求让我们的桩兼职做了Spy的活。工程里一个替身混用多种形态很常见不必因为名字洁癖去建一堆类。5.3 测试运行结果与分析完整的Test Driver写在测试文件里每个测试函数就是一个driverdef test_place_order_success_deducts_balance(): inv InventoryStub(availableTrue) pay PaymentSimulator(balance500) service OrderService(inventoryinv, paymentpay) items [{sku: BOOK-01, price: 100, count: 1}] result service.place_order(user_id1, itemsitems, payment_tokentok_ok) assert result ORDER_PLACED assert pay.balance 400 assert pay.calls [{token: tok_ok, amount: 100}] def test_place_order_payment_failed_then_refund_inventory(): inv InventoryStub(availableTrue) pay PaymentSimulator(balance50) service OrderService(inventoryinv, paymentpay) items [{sku: BOOK-01, price: 100, count: 1}] result service.place_order(user_id1, itemsitems, payment_tokentok_ok) assert result PAYMENT_FAILED:balance_not_enough assert inv.called_items items两个用例的driver结构完全一致构造SUT、注入替身、调用被测方法、分步断言。所有内容组合在一起是一次完整的三者协作演示Test Driver负责开车InventoryStub负责给库存答案PaymentSimulator负责模拟支付状态和失败分支。你可能会问这两个测试里用了同一个PaymentSimulator实例它的余额状态变了会不会影响后续测试这取决于你每个测试是新建实例还是复用。在pytest里每个测试函数里的局部变量每次执行都重新创建所以互相不影响。如果放在类级别的共享实例里就必须设计好reset机制否则状态会在用例之间“串味”这也是模拟器最容易翻车的地方之一。6. 容易踩的坑过度桩替身、模拟器维护成本与测试退化最后一节聊我在实际项目里亲眼见过的几类翻车现场。每个坑踩进去都挺疼而且症状往往不是“测试红”而是“测试看起来很绿”。6.1 桩替身过度测试到底在验证谁有一种测试写多了以后非常危险因为被测单元依赖很多测试代码为了省事给所有依赖全部塞上桩。结果是什么被测单元的每个分支都被桩的返回值“指定”好了测试跑完你都无法判断被测单元有没有真的执行到关键逻辑。识别办法很简单故意把被测单元里的一行关键逻辑改错然后跑测试。如果测试仍然全绿说明那些用例根本没有让被测逻辑真正发挥作用纯属自嗨。我以前接手过一个老服务核心的折扣计算逻辑被改坏十几个测试全绿就是因为大部分断言都在验证桩的返回值而不是被测方法的输出。那次之后我的评审标准里多了一条写测试时必须至少测到一个“由被测单元自己算出来的值”而不只是透传替身的回答。桩替身适度做法可以记成一句话桩负责把环境稳定住但要确保被测单元的每一行代码都有机会被真实执行并断言。6.2 Test driver职责蔓延别让驱动代码变成待测代码driver的本分是“薄”。但总有人潜意识里想写成“全自动测试机器人”一个driver里做一堆前置数据准备、状态编排、结果后处理。写的时候挺爽后续维护苦不堪言因为driver自身开始包含复杂逻辑driver本身的bug又成了测试失败的新来源而且极难定位。我见过一个极端的例子一个测试driver为了构造请求体内部写了循环、字典合并、时间戳格式化占了两百行。后来请求体格式变更测试driver先崩了。这就是“驱动代码”长成了“待测代码”的典型信号。正确的姿势是让driver保持单薄只做“构造被测对象、调方法、断言”三件事。复杂的数据准备放到独立的fixture或工厂里要和driver本身的逻辑彻底分开。6.3 模拟器维护成本失控从“绿色测试”到“虚假绿灯”Simulator最大的隐性风险是契约漂移模拟器内部的行为规则和真实依赖的线上行为不一致了但测试仍然全绿。举个例子真实支付网关在余额不足时会返回一个错误码而支付模拟器因为版本没跟上返回的却是另一个错误码。被测单元对错误码的解析逻辑其实已经过时可模拟器还在按新契约返回测试就是能跑通上线就炸。我的应对方式分两层。第一层是在模拟器代码里写清“契约版本”在类注释里标注它对标的外部服务版本号依赖契约变更时升级模拟器的人必须同步更新测试。第二层是定期用真实服务的契约测试或者冒烟测试来校对模拟器行为哪怕一个月跑一次也比完全相信模拟器强。模拟器是给测试提供确定性的工具但它不该成为团队与真实系统之间的信息断层。6.4 这几年的落地经验写了这么多年测试代码我最终把替身策略稳定成一套很朴素的原则第一默认从最小替身开始。能用一个无状态的手写桩解决的绝不引入Mock框架桩明显撑不住、需要状态和规则时再让替身向Simulator演化。第二Stub、Simulator、Mock三种角色在代码里命名保持一致。一个类如果同时有状态和规则就别叫它XxxStub叫XxxSimulator。名字统一之后评审时读测试的成本会肉眼可见地下降。第三driver保持“一动作一断言”。不要跑到最后才断言把一次调用的多个关键结果拆开到对应步骤之后失败定位从“全局排查”直接降级成“只看这一行上下文”。这套做法最大的价值不是让单测覆盖率数字变好看而是让每个人拿到一组失败的测试时能在三分钟内看懂谁在开车、谁在应答、谁在模仿真实世界。搞清这三个角色比多背几个Mock API值钱得多。
