让AI参与CODESYS单元测试闭环

让 AI 给 CODESYS 写单元测试，难点不只是生成断言，还要把测试编译、下载到 PLC，执行后取回结果。作者选择的路径是：测试跟业务逻辑一起运行，宿主机负责启动和收集，最终目标是用一句话触发测试并拿到红绿报告。

这套设计值得看的地方，是它把 AI 生成代码与验证结果接了起来。不过，原文主要交代了执行架构和操作约束，没有展示完整实现、实际报告或效果数据，距离证明全流程可靠还有一段距离。

为什么断言要跟业务逻辑一起跑

作者使用的环境是 CODESYS V3.5 SP17、SoftMotion Win 64，以及 Windows + PowerShell 5.1。上一篇已经完成向软 PLC 下载程序，并支持启停和变量读写；这一篇继续补测试能力。

他们的选择是：断言靠近逻辑，PLC 侧不引入额外依赖，宿主机接收统一结果流，组织方式参考 xunit。

测试代码使用普通 ST（Structured Text，结构化文本语言），随应用一起编译和下载。断言与被测逻辑在同一个 PLC 周期内运行，访问同一组变量。宿主机只负责启动一轮测试，再读取结果。

这个安排减少了把内部状态搬到外部再判断的环节。但「PLC 侧无额外依赖」不等于测试没有运行成本：测试仍然进入应用，并占用周期任务的执行时间。原文没有提供这部分开销。

一轮测试怎样变成可读取的报告

作者把测试组织成几层，熟悉 xunit 的读者比较容易对应：

• suite 对应 FB_<Unit>_Test 功能块。
• test 对应套件里的 Test_* 方法。
• assert 使用 ass.AssertEquals_*、AssertTrue 等调用。
• fixture 由 Setup、TearDown 和套件的 VAR 共同组成，用于准备、保存和清理测试状态。

测试通过 PRG_Tests 接入周期任务。每个用例按照 Setup → assertions → TearDown 执行，断言把结果写入 GVL_Test 中的用例表。所有套件结束后设置 done 标志，宿主机轮询这个标志，再读取计数与用例，生成报告。

这里的一次 Assert 会记录一条 case，不能直接把结果条数当作测试方法数。

例如，一个 Test_* 方法包含多次断言，报告就可能产生多条记录。对于多轮运行，作者建议采用增量断言，但没有解释具体的去重、重置或累计规则，实现时需要补齐。

跑通之前，先检查这些约束

原文给出的几个操作细节，直接关系到测试是否执行了新逻辑。

项目、CODESYS 和运行目标的版本必须匹配。SoftMotion Win V3 x64 的设备类型是 4102/0000 0004，不能只凭设备名称判断配置正确。

run 只负责登录，要加载新逻辑还需要调用 download。如果自动化流程遗漏下载，测试结果就可能对应旧程序。

此外，PRG_Tests 必须挂在周期任务上，g_uiSuitesTotal 必须与实际套件数一致。这些都是执行与完成判断所依赖的条件。

凭据也不能写进仓库。作者建议使用 -UserFile 或环境变量，但没有展开凭据文件的管理方式。

我的判断

我认可这套设计对职责的划分：PLC 内执行断言，宿主机读取结果，AI 负责生成和串联流程。与在外部读取变量再做判断相比，同周期、同变量的执行方式，更适合验证依赖 PLC 运行状态的逻辑。

但作者没有给出与其他 CODESYS 测试方案的对照数据，也没有展示 AI 生成测试的正确率、测试耗时或回归案例。因此，参考 xunit 是设计选择，不能据此认定它比现有方案更成熟。

红绿报告能证明断言执行后的结果，不能单独证明 AI 写对了断言。

错误的预期值、不充分的状态清理，都可能让报告失去判断价值。原文也没说明宿主机轮询超时、运行中断、结果残留等情况如何处理。一般团队采用前，需要把这些边界补进协议。

能拿来做什么

• 如果你维护 CODESYS 项目，可以先选一个边界明确的功能块，手写最小测试套件，验证从 download 到结果读取的完整链路，再让 AI 扩展测试。
• 编排自动化流程时，把版本匹配、周期任务挂载和套件数量检查作为执行前置条件，避免只看最终报告。
• 让 AI 生成测试时，同时审查 Setup、预期值和 TearDown，并主动制造一次断言失败，确认失败能够被宿主机正确报告。
• 做回归测试前，明确多轮运行的计数、结果清理和增量断言规则，区分历史结果与本轮结果。