在TESSY里做C++单元测试，很多人会直接问“怎么做Mock”，但按Razorcat官方手册的说法，TESSY更常用的术语其实是stub function和advanced stub function。它的思路不是先引入一套独立的Mock框架，而是在接口分析阶段把外部函数、本地函数、类方法和相关依赖识别出来，再由你决定哪些保持真实调用，哪些改成替身调用。公开手册还明确提到，TESSY已经支持C++类的完整接口分析，类的接口和构造函数都可以纳入测试。也就是说，在TESSY里做C++Mock，核心不是先找“Mock按钮”，而是先把要替换的依赖对象和调用边界划清。
一、TESSY C++单元测试怎么Mock
在TESSY里做Mock，更准确地说是用stub或advanced stub去替代真实依赖。官方旧版手册对这条机制讲得很直接，TIE会把测试对象用到的函数分成External Functions和Local Functions，并提供接口去定义stub；其中普通stub可以直接写C代码，advanced stub则可以为参数、返回值以及调用行为提供更细的控制。放到C++场景里，这套思路仍然成立，只是替代对象从普通函数扩展到了类方法、命名空间成员和类成员相关调用。
1、先把测试对象的外部依赖找全
不要一上来就给每个函数做替身。更稳的做法，是先让TESSY完成接口分析，看当前测试对象到底调用了哪些外部函数、类方法和局部依赖。只有把依赖边界看清，后面才知道哪些要保真，哪些该替换。官方手册已经明确说明，TIE会列出测试对象用到的External Functions和Local Functions。
2、普通依赖先用stub function
如果你的目标只是阻断真实调用、返回固定值，或者模拟一次简单错误路径，普通stub通常就够了。官方手册对stub function的定义很清楚，它会在执行时替代原始函数，所以这类场景没必要一开始就上更复杂的高级替身。
3、需要控制参数和返回行为时再用advanced stub
如果你要模拟的是“第一次调用返回成功，第二次返回失败”，或者要根据输入参数给出不同输出，这类场景更适合用advanced stub。公开手册已经把它和普通stub区分开了，强调advanced stub允许你对参数、返回值以及调用过程做更细的控制。对很多人说的“Mock行为验证”，真正贴近的往往就是这一层。
4、C++场景里先从方法级替换开始
TESSY的C++支持已经能够识别类接口和构造函数，这意味着你在做类测试时，不必把整个对象系统一次全替掉。更稳的做法通常是先盯住真正有外部副作用的那几个方法，比如访问硬件、文件、通信或全局服务的方法，再逐步把这些边缘依赖换成stub。这样做出来的测试对象边界更清楚，也更容易维护。
二、TESSY C++类与接口怎么隔离
类与接口隔离，说到底是在做一件事，就是让被测对象只保留自身逻辑，把外部依赖换成可控输入。TESSY在这方面不是靠“自动Mock整个类”来解决，而是靠接口分析、构造处理和TDE里的自定义定义来把依赖拆开。Razorcat的TEE应用说明里专门提到，如果某个类没有默认构造、或者成员里带有引用、常量成员、虚类等复杂情况，TESSY默认自动生成的构造代码可能不够，这时就可以把类设成只声明不自动定义，再由用户在TDE中自行补定义。这个机制本身就是一种隔离手段。
1、先把真正的接口边界定出来
不是所有类成员都需要替身。更合理的做法，是先把纯计算逻辑和外部交互逻辑分开。前者尽量保留真实实现，后者再考虑stub。这样隔离以后，测试对象会更小，替身数量也不会失控。这种做法虽然不是文档里的固定步骤，但和TESSY以接口分析为起点的工作方式是吻合的。
2、构造复杂类时先处理默认构造问题
如果某个依赖类没有默认构造函数，或者内部又带虚类、引用成员、常量成员，直接让TESSY自动生成构造代码时可能在编译或链接阶段出错。TEE应用说明已经明确给出做法，这类类名可以配置成“只声明不自动定义”，后面由你在TDE里手动补。对C++接口隔离来说，这一步很关键，因为很多隔离失败其实不是stub不会配，而是依赖对象根本没法先构造出来。
3、接口替换时优先保留被测类自己的构造链
如果一上来把整个对象树都替成空壳，测试虽然能跑，但很容易把被测类本身的初始化逻辑也一起切掉。更稳的办法，是先保证被测类自己的构造路径尽量真实，只把外围依赖对象声明出来或做受控替身。TEE文档中关于“declare only”与“define on your own”的说明，本质上就是在给这类处理留口子。
4、类方法替身和接口复用要一起看
Razorcat的更新记录里多次提到C++advanced stub variables、类成员、方法重名、基类参数等问题的修复，这说明在C++场景里，类方法隔离不是边角需求，而是TESSY持续增强的一块能力。实际配置时，更建议你把方法级替换和接口数据库复用一起考虑，不要每个测试对象都从零重配一遍。
三、TESSY替身配置先看什么
很多C++单元测试后面变复杂，不是因为TESSY不能做，而是前面没有把替身边界收清。更稳的顺序通常是这样，先确认测试对象接口是否已经被正确识别，再确认哪些依赖必须替换，接着确认构造链是否会因默认构造问题中断，最后才决定用普通stub还是advanced stub。Razorcat的资料虽然分散在用户手册、TEE说明和更新记录里，但拼起来以后，最实用的就是这条顺序。
1、先看接口识别是否完整
如果类接口、构造函数、外部方法本身都没被正确识别，后面谈Mock和隔离没有意义。Razorcat已明确把“完整分析和编辑C++类接口”列成能力，所以这一步应该先确认。
2、再看依赖是函数级还是对象级
如果只是一个外部函数依赖，普通stub就够。要是依赖已经通过类方法、基类方法、成员对象一路传进来，就要按对象边界重看隔离方式。这个区分本身会直接影响你后面选普通stub还是advanced stub。
3、然后看构造链会不会先出错
很多C++测试对象一分析就报错，问题根本不在测试逻辑，而在依赖类没有默认构造或者成员初始化条件太复杂。TEE应用说明已经把这类情况单独点出来了，所以排查时这一层不要跳过。
4、最后再决定替身精细度
只要能用固定返回值解决，就先别把stub做复杂；只有当参数传递、返回行为、调用次数或调用顺序会影响测试目标时，再升级到advanced stub。这样配出来的测试更轻，也更容易复用。这个顺序和TESSY把stub与advanced stub分层处理的机制是一致的。
总结
TESSY C++单元测试怎么Mock，按官方口径看，更实际的理解是通过stub function和advanced stub function去替代真实依赖，而不是另外找一套独立的Mock入口。TESSY C++类与接口怎么隔离，重点也不是一上来把整个对象系统都空掉，而是先把接口边界、构造链和类方法依赖理顺，再决定哪些保持真实、哪些改成替身。把这几层先收清，TESSY里的C++单元测试通常会比单纯堆stub稳很多。
