在嵌入式C中用测试驱动开发构建状态机

状态机是许多嵌入式系统基石，却开发复杂。本文概述用测试驱动开发(TDD)构建状态机(SM)软件的验证策略，聚焦适合资源受限环境的C实现。

核心上，SM模型包含状态、迁移、动作。状态代表条件，迁移定义从一状态到另一状态路径——通常由事件触发，动作捕获进入、退出、迁移期间执行的行为。

UML状态机中，动作可附着于状态进入/退出、迁移本身、内部反应。所有状态机形式假设运行至完成(RTC)执行模型：每个事件完全处理——含退出动作、迁移动作、进入动作——后才处理下一事件。

深入TDD策略前，须理解TDD为何重要。TDD是增量开发法，强制在任何生产代码前写失败单元测试。测试小、自动化、作为期望行为规格。TDD循环——源自James Grenning《嵌入式C测试驱动开发》——含：

• 编写小规模失败测试。
• 运行所有测试；新测试应失败。
• 编写通过测试的最小代码。
• 再次运行所有测试确认新测试通过。
• 重构消除重复、改善清晰度。

考虑图1 SM图。始于StateA，收Alpha事件迁移至StateB，按序执行xStateA()、effect()、nStateB()。如何验证此行为正确？

图1. 基础状态机（来源：VortexMakes）

最直接测试法涉及验证SM迁移表。这为每状态创建一个测试用例，用相关事件刺激SM，断言结果状态和执行动作。复杂动作值得专用测试。（见"使用单元测试测试状态机"文章深度讨论。）

每测试遵循四阶段xUnit模式：

• 建立 — 建立前置条件（如当前状态、事件、预期目标状态、动作序列）。
• 执行 — 触发SM以事件。
• 验证 — 断言结果匹配预期。
• 清理 — 重置SM至初始状态（可选）。

此策略适合简单SM，但更复杂行为——如效果仅在数步后可观测的迁移链——需功能场景测试。而非孤立状态检查，测试完整序列以行使必要状态、事件、动作。

图2说明此法，用DoWhile SM模拟传统do-while循环。机器用x = 0和output = 0初始化默认值，用x++或x = (x > 0) ? x-: x设置循环计数器，用i++迭代直到守卫i == x失败，随后输出output = i。

图2. DoWhile状态机（来源：VortexMakes）

编码前，我们从规格派生测试清单。DoWhile初始清单含：

• 初始化时所有数据设为默认值。
• 增量X属性。
• 减量X属性。
• 执行单次迭代循环。
• 执行多次迭代。
• 处理非迭代场景。
• 检查越界条件。

我们用Ceedling作构建系统、Unity作C代码轻量测试框架。SM定义于DoWhile.h和DoWhile.c，测试套件驻test_DoWhile.c。下文简略摘录演示"单次迭代"测试用例。

代码清单1：单次迭代测试（来源：VortexMakes）

测试初始化SM，设迭代计数零，分发Up事件增量它，触发Start事件，最后发Alpha执行单次循环迭代。断言验证out属性等于迭代次数且SM保持在StateC。

同测试扩展演示多次迭代（见代码清单2）。单独测试(清单3)确认无先前Up事件直接收Alpha时SM执行零迭代。

代码清单2：多次迭代测试（来源：VortexMakes）

代码清单3：非迭代测试（来源：VortexMakes）

实现细节非本文重点，但DoWhile.c和DoWhile.h摘录展示整洁switch-case状态处理法。

代码清单4：DoWhile实现片段（来源：VortexMakes）

代码清单5：DoWhile规格片段（来源：VortexMakes）

总之，TDD为状态机开发提供两互补策略：(1)逐状态迁移测试，(2)覆盖多状态动作的功能场景测试。这些方法语言无关、工具无关，特别适合状态逻辑主导的嵌入式系统。

因C仍是嵌入式软件通用语，搭配Ceedling和Unity产出强健TDD工作流。采用这些实践导出比常规方法更灵活、可维护、可复用的软件。

所有代码和模型可在GitHub仓库https://github.com/leanfrancucci/sm-tdd.git获取。