改进 OpenCC 测试结构：使用单一输入一次测试多个 config，以降低测试编写与 review 成本

[frankslin]

提案：改进 OpenCC 测试结构——单一输入一次测试多个 config

各位维护者好， 我想提出一个关于 OpenCC 测试结构的改进提案，目标是降低测试编写与 review 成本，并更直观地展示不同 config 之间的差异。

现有问题

当前测试以「每个 config 一组 input / output 文件」为单位，这在验证单个 config 时有效，但在实际维护中存在问题：

• 同一段输入在不同 config 下的差异被分散在多个文件中
• review 时需要同时打开多个文件对比
• 新贡献者不清楚应该改哪些文件，测试编写门槛较高

很多实际问题并不是某个 config 是否能跑，而是不同 config 之间的输出差异是否合理。

核心想法

引入一种新的测试定义方式：

• 以「输入文本」作为测试的基本单元
• 在一个文件中一次性定义该输入在多个 config 下的预期输出
• 使用 JSON 作为测试定义格式 即从「一个 config → 一个 input → 一个 output」变为「一个 input → 多个 config → 各自的 expected output」

{
  "cases": [...,
    {
      "id": "case_014",
      "input": "高剂量的苦瓜素还会抑制胚胎发育",
      "expected": {
        "s2hk": "高劑量的苦瓜素還會抑制胚胎發育",
        "s2t": "高劑量的苦瓜素還會抑制胚胎發育",
        "s2tw": "高劑量的苦瓜素還會抑制胚胎發育",
        "s2twp": "高劑量的苦瓜素還會抑制胚胎發育"
      }
    },...
  ]
}
...

这样做的好处是：

• 一个文件即可看清所有 config 的差异
• review 更直观，可直接讨论差异是否符合设计预期
• 贡献者每次只需要改一个文件，明显降低测试编写成本，鼓励贡献者多写测试

关于测试切换方式

我个人更倾向于一次性采用这种「单文件、多 config」的测试模型，因为「只有一个地方需要改」能显著降低心智负担。

如果维护者认为一次性切换风险较高，也可以作为折中方案，让新结构与现有测试结构并存，仅用于需要横向对比的用例。

额外收益：可直接运行的 Bazel 测试

该方案中还新增了一个基于 Bazel 的测试入口：

• 测试可直接以 bazel test //data/config:config_dict_validation_test 作为命令运行。
• 贡献者可以在本地快速验证修改是否正确，而无需等待 binary 编译全部完成。

PoC

我已经做了一个 proof-of-concept 的实现，仅涉及测试结构与 runner，不修改转换逻辑本身： frankslin#9

如果这个方向被认为是可接受的，我可以再整理一个更符合 upstream 风格的完整版本提交。

感谢你们的时间和反馈。