应放弃穷举全排列测试，转而用状态机建模驱动迁移路径测试，并通过参数化聚焦关键状态组合，仅验证公开接口触发的动作与行为一致性。
状态爆炸时别硬写全排列测试用例
当一个 C++ 类有 5 个布尔成员、3 个枚举（各 4 种取值）、2 个可空指针，理论状态数就超过 2⁵ × 4³ × 3² = 9216 种——实际不可能穷尽。硬写全量测试只会让 TEST_F 套件臃肿、难维护、失败定位困难。
真正有效的做法是放弃“覆盖所有状态”，转而聚焦“状态如何被触发”和“状态变更是否符合契约”。重点验证：构造路径、状态迁移边界、非法跃迁拦截、关键组合下的行为一致性。
用状态机建模 + 迁移路径驱动测试设计
把对象生命周期抽象成有限状态机（FSM），不是为了画图交差，而是为了找出必须覆盖的迁移边。比如 Connection 类典型状态：Idle → Connecting → Connected → Disconnected，其中 Connecting → Idle 可能只在超时或 DNS 失败时发生，这就是必须测的异常路径。
- 列出所有合法迁移（如
start()只能在Idle调用） - 对每条迁移边，写一个最小测试：前置状态 + 触发动作 + 验证后置状态 + 验证副作用（如是否调用了
socket::connect()） - 用
enum class State { Idle, Connecting, Connected, Disconnected };显式表达状态，避免靠字段组合推断 - 禁止在测试里手动设置私有状态字段（如
obj.state_ = Connecting;），必须走公开接口驱动
用参数化测试聚焦关键状态组合
对影响行为的核心状态子集做正交表或成对测试（Pairwise），而非全排列。例如某 CachePolicy 类含 ttl_enabled、stale_while_revalidate、max_age 三个字段，真正影响缓存命中逻辑的是前两者布尔值的 4 种组合，max_age 只需覆盖 0 / 正数 / 负数三类边界值——总共只要 4 × 3 = 12 个用例，不是 2 × 2 × ∞。
在 Google Test 中用 INSTANTIATE_TEST_SUITE_P + ValuesIn 实现：
INSTANTIATE_TEST_SUITE_P(
CachePolicyBehavior,
CacheTest,
ValuesIn({
std::make_tuple(true, true),
std::make_tuple(true, false),
std::make_tuple(false, true),
std::make_tuple(false, false)
})
);
测试体里解包元组，构造对应策略对象，再执行 get() 并断言响应头或过期时间。
避免伪造内部状态导致测试脆弱
常见错误是给测试开后门：加 friend class CacheTest; 或暴露 set_state_for_test() 方法。这会让测试与实现细节强耦合——一旦重构状态存储方式（比如从字段改为位域或外部状态映射表），所有测试立刻崩坏。
- 测试只能通过公开接口观察行为，不能“设置状态”再“验证行为”，而要“触发动作”再“验证状态+行为”
- 若某些状态极难到达（如网络分区下的
Connected → Disconnecting），宁可引入可控依赖（如注入std::shared_ptr<networksimulator></networksimulator>）也不动类接口 - 对只读状态访问器（如
is_connected()），确保其不改变对象状态（加const限定），否则测试可能因调用顺序产生隐式依赖
状态多不可怕，可怕的是把测试写成状态快照比对器。真正该测的永远是“它做什么”，而不是“它此刻是什么”。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
