企业官网建设流程全解析

基于Markdown的测试套件：受AI启发的新尝试

本文虽与AI无关且并非AI撰写，但接下来要介绍的工作受AI启发。作者喜欢讲故事，先讲背景。若仅因第一段提到AI就离开，那就太可惜，接下来的技术解释有趣且与AI无关。

去年12月，作者开始尝试使用编码代理，让AI代理参考EndBASIC公开文档编写游戏，虽初次尝试结果不完美，但稍作调整就能运行。结合手写的 `AGENTS.md` 规则，代理轻松生成EndBASIC演示。这个实验令人印象深刻，激发了作者继续推进EndBASIC开发的兴趣，作者想到三点：增强EndBASIC的“自文档化”特性；提升其速度；为其添加原语。这些想法促使作者从1月开始重写EndBASIC核心，并将在即将发布的版本中推出。在此之前，作者想谈谈新核心的测试方法——改用Markdown编写。

为何选择Markdown？

为让AI代理编写正确的EndBASIC代码，作者手工编写 `AGENTS.md` 规则，但手工编写易出错且难全面。所以作者想让大语言模型（LLMs）直接从EndBASIC中提取信息。用AI通用的Markdown编写新核心的集成测试，这些测试可作为展示语言行为的规范且正确的文档。LLMs擅长总结信息，处理大量实际“示例”后可能理解其中规则。事实证明可行，作者向GPT 5.4提出提示，生成了全面且规则准确的文件。

什么是Markdown测试套件？

它是一组Markdown文件，每个文件是一个或多个测试用例的容器。

测试用例是什么样的？

每个测试用例有标题描述测试内容，还有多个子部分定义测试场景：源代码是编译器的输入代码块；若编译失败，有“编译错误”部分包含错误信息；若编译成功，有反汇编包含编译后的字节码，退出代码（可选）显示程序的退出代码，输出包含程序执行时打印到控制台的消息，运行时错误包含程序执行过程中出现的错误。作者还给出了验证 `END` 命令的简单示例。目前没有用于验证词法分析器和解析器内部的部分，作者正在考虑进一步扩展该格式，同时输出抽象语法树（AST）以简化测试。

测试如何运行？

测试套件的驱动程序会枚举测试目录中的所有Markdown文件并逐个处理。对于每个文件，驱动程序提取所有测试用例的标题和源代码子部分，确定要执行的测试用例。将测试用例提供给编译器，编译成功后再提供给虚拟机，捕获所有副作用，生成包含测试结果的新Markdown文件。驱动程序将生成的文件与预先记录并提交的版本进行比较，若不同测试就会失败，会用 `diff` 工具打印差异。这种方式使驱动程序简单，生成的差异对人类容易理解。

这种方式可维护吗？

目前测试套件有448个测试用例和13000行Markdown代码，手动维护不可行。但因前面描述的设计，在核心更改后重新生成预期结果文件很容易，只需设置 `REGEN=true` 环境变量，驱动程序重写预期结果文件，然后作者可用Git验证更改并与实际代码更改一起提交。

目前的感受如何？

基于Markdown的测试套件框架有优点：比以前的方法更容易使用，调整测试容易且易与之前状态比较；几乎任何像样的文本编辑器都支持Markdown，便于浏览和修改；LLMs可以轻松“学习”。当然也有缺点：重新生成测试输出或所有测试太容易，易忽略小错误；反汇编的差异嘈杂，难以审查，但保留指令地址有用；Rust不能动态生成一流的测试用例，无法进行常规的测试过滤；这个想法不太容易推广，只适用于端到端测试有利且成本较低的组件。

作者建议查看驱动程序、辅助代码以及测试套件目录。最后作者提问：现在了解了这个新技巧，大家有什么想法呢？

关于这篇文章的讨论

Danielle认为“重新生成测试输出或所有测试太容易”是个大问题，自动重新生成预期结果文件会使测试失效，这里的更改需要用户更加自律。Wilfred Hughes认为对于编程语言项目，黄金测试通常是个好主意，Markdown可读性强，但手动运行程序稍困难，LLVM的lit允许使用带有注释的源文件，也是不错的方法。