测试数据应通过工厂函数封装构造逻辑，避免硬编码和裸指针；优先使用初始化列表构建嵌套结构；用命名明确的桩对象替代外部依赖；单元测试数据重在覆盖分支而非规模，可读性是第一指标。
直接用硬编码构造测试数据，90% 的 C++ 练习项目会卡在第二步——不是逻辑写不对，是 std::vector 嵌套三层后连自己都读不懂初始化语句，或者一个 struct 里带指针、带 std::unique_ptr、带自定义构造函数，一写测试就崩溃。
测试数据别手写：用工厂函数封装构造逻辑
练习项目里最常出现的“测试数据难造”，本质是把数据结构和测试逻辑混在一起。比如测一个解析 JSON 数组的函数，你不会真去拼一串字符串再调解析器；同理，测一个处理 Order 链表的算法，也不该在每个 TEST 里手动 new 十个节点。
- 把重复的数据构造逻辑抽成
MakeTestOrder()、MakeEmptyCart()这类工厂函数，返回值类型明确（Order、std::vector<Item>），不暴露内部构造细节 - 工厂函数内部用聚合初始化或统一构造函数，避免裸
new和裸指针——例如用std::make_unique<Node>()而非new Node - 对边界场景单独命名：如
MakeOrderWithNullItems()比注释 “// 测试空 items” 更可靠，也方便复用
嵌套结构体/容器数据：优先用初始化列表，慎用循环填充
练习项目中大量出现 std::map<std::string, std::vector<int>> 这类嵌套结构，新手容易写成多层 for 循环加 push_back，结果测试失败时根本看不出哪一层出错。
- 能用大括号初始化就不用运行时构造：例如
std::vector<int>{1, 2, 3}、std::map<int, std::string>{{1,"a"}, {2,"b"}} - 嵌套太深时拆成局部变量分步构造，而不是塞进一行：先建
auto items = std::vector<Item>{...}，再塞进Order构造函数 - 避免在测试里用
rand()或时间戳生成数据——练习项目要的是可重现性，不是随机性
涉及资源或外部依赖时：用桩对象替代真实构造
哪怕只是练习项目，一旦出现 FileReader、NetworkClient 这类类，硬造实例就会让测试变成集成测试，编译慢、执行慢、失败原因模糊。
立即学习“C++免费学习笔记（深入）”；
- 定义接口（如
class IDataSource），让被测类依赖接口而非具体实现 - 测试中传入轻量桩对象，例如
MockDataSource内部只存一个std::string或std::vector<byte>，read()直接返回它 - 不要为桩对象写完整生命周期管理——练习阶段，用栈对象或
std::shared_ptr就够了，别提前卷 RAII
测试数据规模失控时：检查是否误把性能测试当单元测试
看到有人在练习项目里写“生成 10 万条订单测排序”，基本可以判定混淆了单元测试和性能测试边界。单元测试的数据规模应以“覆盖逻辑分支”为准，不是越大越好。
- 排序算法测 3 种情况就够了：空容器、单元素、已排序/逆序/随机（各 5–10 个元素）
- 状态机类测所有转移路径，而不是模拟 1000 次状态跳转
- 如果发现必须塞大量数据才能触发 bug，说明问题不在测试数据本身，而在被测逻辑没做输入校验或早该拆函数
真正容易被忽略的点是：练习项目里的测试数据，最终要能一眼看出“这个输入对应哪个分支”。与其花十分钟写个泛型生成器，不如花两分钟给数据变量起个像 input_with_duplicate_keys 这样直白的名字——可读性，才是练习阶段的第一测试指标。
