状态机测试需显式枚举所有合法转移并验证非法事件不引发状态变更或副作用，推荐用 table-driven 方式结合 mock 依赖和同步回调规避竞态。
状态机测试必须显式枚举所有状态转移
Go 没有内置状态机测试框架，go test 本身也不感知状态。想覆盖逻辑，就得把「状态 + 事件 → 下一状态 + 副作用」这一映射关系手动拆成可断言的单元。常见错误是只测“当前状态能响应事件”，却漏掉「不该发生的转移」——比如 Idle 状态收到 Stop 事件本应无反应，但测试没验证它是否真的没改变状态或触发副作用。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用 map[State]map[Event]Transition 显式定义所有合法转移，测试前先遍历该表，对每条路径跑一次
Apply(event)并断言currentState和关键副作用（如 channel 是否写入、error 是否为 nil） - 对每个状态，额外构造一个非法
Event，调用后断言状态未变、无 panic、无非预期 error（比如返回ErrInvalidTransition而不是nil） - 避免在状态结构体里藏“隐式转移逻辑”，比如
func (s *Order) Cancel() { if s.Status == Paid { s.Status = Canceled } }—— 这种写法让转移逻辑散落在方法里，难以统一覆盖
用 table-driven 测试驱动状态转移组合
状态机的输入是二元组（当前状态，触发事件），输出是（新状态，error，side effects）。直接写 if/else 测试易漏边角，table-driven 是最稳的写法。注意 Go 的 testing.T.Run 名称必须唯一，否则并发运行时会覆盖结果。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 测试用例表每一行包含：
name（建议含状态和事件名，如"Paid_ReceiveRefund"）、startState、event、expectedState、expectedError、expectSideEffect（布尔或具体值） - 在
Run内部重建干净的状态实例（不要复用指针），否则上一轮测试可能污染下一轮 - 副作用难断言？把依赖（如日志、通知 channel）抽成接口，测试时传入 mock，检查 mock 的调用次数或参数是否匹配预期
goroutine 和 channel 引发的竞态会让状态覆盖失效
真实状态机常涉及异步事件（比如订单超时自动关单走 time.AfterFunc 或从 chan Event 读取）。这时单纯跑同步测试会漏掉「状态正在转移中被另一个事件打断」的场景，而 go test -race 又很难捕获逻辑级竞态——它只报内存读写冲突，不报业务状态错乱。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 禁用所有后台 goroutine：测试时把定时器、event loop 替换为同步回调，例如把
time.After换成func() 并手动 send - 若必须测并发行为，用
sync.WaitGroup+ 显式等待 + 最终状态断言，而非依赖 sleep；sleep 在 CI 上极易飘移，导致 flaky test - 避免在状态转移函数里直接启动 goroutine（如
go s.notify()），这会让副作用脱离测试控制流；改用返回需执行的动作列表，由测试决定是否执行
覆盖率工具无法识别“状态路径”覆盖度
go tool cover 只统计行是否执行过，不关心「Idle → Processing 这条边有没有走过」。你可能看到 95% 行覆盖，但实际只测了 3 条转移路径中的 1 条——尤其当状态多、事件多时，组合爆炸会让漏覆盖变得隐蔽。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 在状态转移函数入口加一行日志（仅测试环境启用）：
log.Printf("transition: %s + %s -> %s", s.State, event, nextState)，跑完测试后 grep 日志，人工核对所有预期转移是否出现 - 用 map[[2]string]bool 记录已覆盖的（状态，事件）对，测试结束时遍历预设的全集，打印缺失项——比靠眼睛盯 cover 报告可靠得多
- 别迷信覆盖率数字。真正关键的是「每个非法转移是否被拒绝」和「每个合法转移是否产生正确副作用」，这两点必须显式断言，不能靠行覆盖来背书
状态机测试最难的不是写断言，而是穷举所有（状态 × 事件）组合并明确每种组合的预期行为。一旦定义模糊，测试就变成自我安慰。所以动手前，先用纸或表格把转移图画出来，再转成代码——跳过这步，后面全是坑。
