cpp/pl/flux 现在已经有 scanner/parser、runtime evaluator、标准库、table pipeline、connector、optimizer、physical executor、CLI 和 LSP。它不是一个单点库，而是一条从源码到编辑器、从 AST 到查询执行、从语义到性能的链路。测试体系要守住的不是某个函数，而是这条链路的边界。

这一篇讲的不是“多写测试”这种泛泛建议，而是 Flux 项目当前如何分层：哪些 bug 应该落在 parser test，哪些应该落在 runtime eval，哪些必须进入 conformance，哪些只能靠 benchmark 观察趋势。

测试不是一类

当前测试大致分成这些层：

• scanner / strconv unit test。
• parser unit test 和 AST dump。
• runtime value/env/eval/page/exec unit test。
• connector runtime/source unit test。
• optimizer RBO/CBO unit test。
• CLI unit/smoke test。
• stdlib conformance test。
• cross-source 和 feature examples。
• LSP unit test。
• benchmark runner。
• 静态检查。

每一层守不同边界。parser test 不应该承担 runtime 正确性；runtime eval test 不应该依赖真实 MySQL；LSP test 不应该通过人工打开编辑器来证明 JSON-RPC 正确；benchmark 更不应该伪装成 correctness test。